Date: Fri, 1 Jun 2007 20:18:44 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Jeff Roberson <jroberson@chesapeake.net> Cc: freebsd-arch@FreeBSD.org Subject: Re: Updated rusage patch Message-ID: <20070601200348.G6201@delplex.bde.org> In-Reply-To: <20070601014601.I799@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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(). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070601200348.G6201>