Date: Mon, 4 Jun 2007 16:27:20 +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: <20070604160036.N1084@besplex.bde.org> In-Reply-To: <20070601123530.B606@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 1 Jun 2007, Jeff Roberson wrote: > Please grep for statclock in threadlock.diff. This removes time_lock from > statclock all together and protects the whole thing with thread_lock(). With > this change all cpus can execute statclock() concurrently with sched_smp.c. > This patch also has fixes for locking ruxagg() as well as asserts. It does > not yet protect the ru copying in exit(). I want to figure out the > synchronization issues with wait first. I don't want to get involved reviewing another large[r] patch. A bug turned up with the previously committed patches: the swapper process is now shown as having a runtime of 40-47 seconds after booting (and never changes after that), but I don't use swapping and this process has always been shown as having a runtime of 0 seconds before. The bug seems to be that proc0_post() doesn't know anything about the rusage fields in the thread struct. Until recently, it was only missing initialization of td_*ticks. Now it is missing initialization of td_runtime too, so the bug is more obvious. The rusage fields may or may not be garbage when proc0_post() runs, depending on the details of clock initialization, so they are supposed to be cleared there. The runtime before clearing used to be complete garbage since timecounters were used for the runtime and the dummy timecounter gave garbage while booting. Now 47 seconds on one of my machines is larger than the real time between init386() and proc0_post() by a factor of about 5. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070604160036.N1084>