Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 1 Jun 2007 12:37:51 -0700 (PDT)
From:      Jeff Roberson <jroberson@chesapeake.net>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        freebsd-arch@FreeBSD.org
Subject:   Re: Updated rusage patch
Message-ID:  <20070601123530.B606@10.0.0.1>
In-Reply-To: <20070601200348.G6201@delplex.bde.org>
References:  <20070529105856.L661@10.0.0.1> <200705291456.38515.jhb@freebsd.org> <20070529121653.P661@10.0.0.1> <20070530065423.H93410@delplex.bde.org> <20070529141342.D661@10.0.0.1> <20070530125553.G12128@besplex.bde.org> <20070529201255.X661@10.0.0.1> <20070529220936.W661@10.0.0.1> <20070530201618.T13220@besplex.bde.org> <20070530115752.F661@10.0.0.1> <20070531091419.S826@besplex.bde.org> <20070531010631.N661@10.0.0.1> <20070601154833.O4207@besplex.bde.org> <20070601014601.I799@10.0.0.1> <20070601200348.G6201@delplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070601123530.B606>