rusage breakdown and cpu limits.
Julian Elischer
julian at elischer.org
Tue May 29 20:45:44 UTC 2007
Jeff Roberson wrote:
>
> On Tue, 29 May 2007, John Baldwin wrote:
>
>> 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.
>
> The problem with using a pool or per-process spinlock is that it keeps
> the contention in the process domain, rather than thread domain. For
> multithreaded processes this will give the same contention as a global
> scheduler lock, only slightly reduced in scope. I'd like to solve this
> in such a way that we don't have to revisit it again.
>
> I think I'm going to make the rusage struct per-thread and aggregate it
> on demand. There will be a lot of code churn, but it will be simple.
> There are a few cases where which will be complicated, and cpulimit is
> one of them.
So, there should be somewhere to store the aggregated stats from
threads that have already exited.
>
> Jeff
>
>>
>> --
>> John Baldwin
>>
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
More information about the freebsd-arch
mailing list