Date: Tue, 5 Jun 2007 22:45:26 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Attilio Rao <attilio@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Updated rusage patch Message-ID: <20070605214404.X47001@delplex.bde.org> In-Reply-To: <46652D17.5090903@FreeBSD.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> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 5 Jun 2007, Attilio Rao wrote: > Bruce Evans wrote: >> ... >> 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. > > Yes, I always wondered why proc0_post() doesn't initialize [s,i,u]ticks too. > However, could you please give a look and a try to this patch: > http://users.gufi.org/~rookie/works/patches/schedlock/proc_post.diff > > and see if it solves your problem. 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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070605214404.X47001>