Re: rusage breakdown and cpu limits.
- From: John Baldwin <jhb@xxxxxxxxxxx>
- Date: Tue, 29 May 2007 14:56:38 -0400
On Tuesday 29 May 2007 02:01:36 pm Jeff Roberson wrote:
I'm working with Attilio to break down rusage further to be per-thread in
places where it is protected by the global scheduler lock. To support
this, I am interested in moving the rlimit cpulimit check into userret(),
or perhaps ast(). Is there any reason why we need to check this on every
context switch? Any objections to moving it? Eventually it will require
a different lock from the one we obtain to call mi_switch().
I think using a per-process spin lock (or a pool of spin locks) would be a
good first step. I wouldn't do anything more complicated unless the simple
approach doesn't work. The only reason to not move the check into userret()
would be if one is worried about threads chewing up CPU time while they are
in the kernel w/o bouncing out to userland. Also, it matters which one
happens more often (userret() vs mi_switch()). If on average threads perform
multiple system calls during a single time slice (no idea if this is true or
not), then moving the check to userret() would actually hurt performance.
--
John Baldwin
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: rusage breakdown and cpu limits.
- From: Jeff Roberson
- Re: rusage breakdown and cpu limits.
- From: Kip Macy
- Re: rusage breakdown and cpu limits.
- References:
- rusage breakdown and cpu limits.
- From: Jeff Roberson
- rusage breakdown and cpu limits.
- Prev by Date: Re: rusage breakdown and cpu limits.
- Next by Date: Re: rusage breakdown and cpu limits.
- Previous by thread: Re: rusage breakdown and cpu limits.
- Next by thread: Re: rusage breakdown and cpu limits.
- Index(es):
Relevant Pages
|
|
