Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 1 Jun 2007 02:27:56 -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:  <20070601021132.J799@10.0.0.1>
In-Reply-To: <20070601184224.A4207@besplex.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> <20070601184224.A4207@besplex.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, Bruce Evans wrote:
>
>> Hmm, this is confusing.  Normal locking is not used for thread-local
>> fields.  Instead, a side effect of spinlocking is used:
>> mtx_lock_spin(&any) in non-interrupt code has the side effect of
>> masking interrupts on the current CPU, so statclock() can access
>> anything on the current CPU without acquiring any locks, just like
>> an interrupt handler on a UP system.  This is used for td_*ticks.
>> It doesn't work for ru_*rss since since exit1() doesn't hold a
>> spinlock when copying td_ru.  The sched_locking of ru_*rss in
>> statclock() doesn't help -- I think it now does nothing except
>> waste time, since these fields are now thread-local so they need
>> the same locking as td_*ticks, which is null in statclock() but
>> non-null elsewhere.
>> 
>> 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.
>
> Oops, it's more confusing than that.  It is not a bug for td_[usip]ticks
> to be under sched_lock, since they must be under a more specific lock
> than `any' for when they are reset in ruxagg().  That lock has the dual
> purpose of locking out interrupts as a side effect and locking out other
> threads explicitly.
>
> Please add a lock assertion in ruxagg() and friends that the relevant
> lock is held.

I have such an assert in a threadlock.diff that I will post tomorrow.  I 
could add it in before as well, but I suspect threadlock is going in next 
week and there are different locks involved there anyway.

Jeff

>
> Bruce
>



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