Date: Wed, 30 May 2007 07:38:11 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Julian Elischer <julian@elischer.org> Cc: freebsd-arch@freebsd.org Subject: Re: rusage breakdown and cpu limits. Message-ID: <20070530072219.G11288@besplex.bde.org> In-Reply-To: <465C90F5.1000906@elischer.org> References: <20070529105856.L661@10.0.0.1> <200705291456.38515.jhb@freebsd.org> <20070529121653.P661@10.0.0.1> <465C90F5.1000906@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 29 May 2007, Julian Elischer wrote: > Jeff Roberson wrote: >> I think I'm going to make the rusage struct per-thread and aggregate it on >> demand. There will be a lot of code churn, but it will be simple. There >> are a few cases where which will be complicated, and cpulimit is one of >> them. > > So, there should be somewhere to store the aggregated stats from threads that > have already exited. We already have that. It is the per-process rusage. There is already delayed accumulation for tick counts (these are currently accumulated in the rusage from the thread at context switch time). There is also delayed conversion of stats to the form needed by getrusage(). Stats are kept in raw form as long as possible (forever if nothing calls getrusage() or wait[34]() to look at them) to avoid conversion overhead for them on every exit(). So there are many precedents for delayed stats handling. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070530072219.G11288>