Date: Fri, 1 Jun 2007 02:57:19 -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: <20070601025432.N799@10.0.0.1> In-Reply-To: <20070601192834.S4657@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> <20070531181228.W799@10.0.0.1> <20070601192834.S4657@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 1 Jun 2007, Bruce Evans wrote: > On Thu, 31 May 2007, Jeff Roberson wrote: > >> Now that I've said all of that and committed the patch, I just realized >> that there is still one race that is unacceptable. When the thread exits >> in thread_exit() and adds the stats of both threads together we could lose >> changes in the still-running thread. > > I think I see. > > The same problem seems to affect all calls to ruxagg() and rucollect() > for threads that aren't curthread. You cannot control the stats for > other threads using a spinlock since statclock() doesn't use a spinlock > for the tick counts and shouldn't (modulo this bug) use one for the > rss's. Resetting the tick counts in ruxagg() is particulary dangerous. > Resetting the runtime in ruxagg() isn't a problem because the runtime > isn't touched by statclock(). ruxcollect() only does insufficently > locked accesses for reading the rss's, except in thread_exit(). It > should be easy to avoid the resettings by accumulating into a local > rux as is already done for ru's (put an rux in each thread and add > these up when required). This reduces to the same problem as for the > rss's. Well, it isn't terribly inconvenient to hold the sched_lock/thread_lock in statclock() where the stats are updated. This makes the solution simply to grab thread/sched lock in ruxagg(). Jeff > > Bruce >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070601025432.N799>