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>