rusage breakdown and cpu limits.

[Jeff Roberson]

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.

Jeff

>
> -- 
> John Baldwin
>