Re: rusage breakdown and cpu limits.

Jeff Roberson wrote:
On Wed, 30 May 2007, Bruce Evans wrote:

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.

From thread_exit():
/* Add our usage into the usage of all our children. */
if (p->p_numthreads == 1)
ruadd(p->p_ru, &p->p_rux, &p->p_stats->p_cru, &p->p_crux);

This is only called when the last thread is exiting (as part of exit())
.... and we are adding our process's rusage to the storage for
have already put their rusage numbers. I assume that wait() will reap it from there later.

making it per-thread would effectively remove the conditional and make something
similar happen on every thread_exit(). (not necessarily a bad thing).





Is the comment wrong or the code wrong? This adds our child's rusage to our own. I assume the comment is actually wrong and that we're adding our children's resource usage to our own so the pstats structure can be freed and our parent can aggregate it all together.

Jeff



Bruce


_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: rusage breakdown and cpu limits.
    ... There will be a lot of code churn, ... there should be somewhere to store the aggregated stats from threads that have already exited. ... delayed conversion of stats to the form needed by getrusage(). ...
    (freebsd-arch)
  • Re: rusage breakdown and cpu limits.
    ... there should be somewhere to store the aggregated stats from threads that have already exited. ... delayed conversion of stats to the form needed by getrusage(). ...
    (freebsd-arch)
  • Failing to understand getrusage()
    ... I'm failing to understand how getrusage() works, which is a bit perplexing, ... From doing some googling it looks like there may be a delay between the process's resident set size increasing and the stats that getrusageuses being updated. ... I'm actually instrumenting Perl applications, using Perl's built-in debugger, instrumenting at the Perl level, so solutions of the form "Use profiling application" aren't going to be applicable. ...
    (freebsd-stable)