Date: Thu, 7 Jun 2007 13:59:03 -0700 (PDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Bruce Evans <brde@optusnet.com.au> Cc: Attilio Rao <attilio@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Updated rusage patch Message-ID: <20070607135511.P606@10.0.0.1> In-Reply-To: <20070606152352.H606@10.0.0.1> 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> <20070601123530.B606@10.0.0.1> <20070604160036.N1084@besplex.bde.org> <46652D17.5090903@FreeBSD.org> <20070605214404.X47001@delplex.bde.org> <20070606152352.H606@10.0.0.1>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 6 Jun 2007, Jeff Roberson wrote: > On Tue, 5 Jun 2007, Bruce Evans wrote: > >> >> This can probably be fixed more simply by calling rufetch() to reset the >> time state in threads as a side effect. Do this before resetting the >> state in the process. > > Ok, I agree with bde here, just call rufetch and this will clear each thread, > and then you can clear the rux in the proc. > > I'd like to make a list of the remaining problems with rusage and potential > fixes. Then we can decide which ones myself and attilio will resolve > immediately to clean up some of the effect of the sched lock changes. > > 1) The ruadd() in thread_exit() is not safe since we're accessing another > thread's unlocked rusage structure. Potential solution is to allocate p_ru > as part of the proc struct and add into there, which will be protected by the > PROC_SLOCK, which bde seemed to like better anyway. > > 2) We may lose information between exit1() and thread_exit() due to the way > p_ru is initialized before we're done exiting. There also seems to be a race > where wait() operates on a process before it's done in thread_exit() which > means wait may return rusage information without the child added in! The > solution will be to fix this race, and then access p_ru directly in wait(). The patch at http://people.freebsd.org/~jeff/rusage3.diff fixes points 1 and 2 as well as the p_runtime iniitialization problem. This moves the collection of child rusage back into exit1() and changes the exiting threads to accumulate their rusage into p_ru under protection of the process spinlock. This also removes the gross lock/unlock of proc slock (formerly sched_lock) from wait and implements something more sensible. Jeff > > 3) There is no locking around rufetch() and calcru(). calcru() may apply > new rux values to an old rusage, giving inaccurate results. The solution is > to either require the proc slock around both calls, or provide a new routine > which does the fetch and calc while grabbing the lock itself. > > 4) libkvm has had the rusage support if'd out because I broke it when I > removed pstats.p_ru. Do we care about rusage in libkvm? Should we go to the > trouble of traversing the list of threads and sum'ing it up? Can we export > some subset of the information? Does anyone use this (other than bde ;). > > Jeff > >> >> ANother minor problem is that proc0_post() isn't the right place to >> reset the time state except for proc0. It hacks on some of the time >> state for all processes and thus for all CPUs, but only resets switchtime >> and switchticks for the current CPU. Resetting of switchtime and >> switchticks for startup of other CPUs now seems to be in sched_throw(). >> I think this is not properly synchronous with the resetting of the >> rest of the state, but the errors from this are tiny. >> >> Bruce >> > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070607135511.P606>