Updated rusage patch

[Jeff Roberson]

On Fri, 1 Jun 2007, Bruce Evans wrote:

> On Fri, 1 Jun 2007, Jeff Roberson wrote:
>
>> On Fri, 1 Jun 2007, Bruce Evans wrote:
>
>> Well, I think the whole exit/wait path could probably use some attention. 
>> There is an incredible amount of locking and unlocking to deal with various 
>> races and lock order issues.  And there are many subtle effects which 
>> aren't immediately obvious.  I'm nervous about how many bugs might be 
>> caused if we start going down this path so close to 7.0.
>
> I'm afraid to look too closely :-).
>
>>> Related bugs:
>>> - td_[usip]ticks are still under (j) (sched_lock) in proc.h.
>>> - td_(uu,us}ticks have always (?) been under (k) (thread-local).  That
>>>  is more correct than (j), but they are updated by an interrupt handler
>>>  and seem to be accessed without disabling interrupts elsewhere.
> [See other replies for large modifications to this]
>
>> Well td_[uisp]ticks are set and cleared while the sched_lock is held.  In 
>> threadlock.diff the thread lock is responsible for this.  That reminds me 
>> that I didn't add the per-thread locking to rufetch() in the patch I posted 
>> earlier.
>
> But the ticks fields aren't aren't under sched_lock in the patches or
> committed version.  The could easily be under time_lock, but were
> carefully pushed out of that too in the time_lock changes.  Per-thread
> locking in statclock() and rufetch() could fix this but would give more
> locking overhead in statclock().

Please grep for statclock in threadlock.diff.  This removes time_lock from 
statclock all together and protects the whole thing with thread_lock(). 
With this change all cpus can execute statclock() concurrently with 
sched_smp.c.  This patch also has fixes for locking ruxagg() as well as 
asserts.  It does not yet protect the ru copying in exit().  I want to 
figure out the synchronization issues with wait first.

Jeff

>
> Bruce
>