Re: rusage breakdown and cpu limits.

On Tue, 29 May 2007, Jeff Roberson wrote:

On Wed, 30 May 2007, Bruce Evans wrote:
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
...

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);

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.

Yes, it is the comment that is wrong. The comment that (now partly)
describes this code correctly is still in kern_exit.c:

% /*
% * Save exit status and finalize rusage info except for times,
% * adding in child rusage info later when our time is locked.
% */

Recent history:
kern_exit.c 1.276 moved the call later in the file and updated this comment.
1.284 moved the call even later and added the wrong comment to it.
1.286 moved the call and its wrong comment to kern_thread.c.

The "later" in the comment in kern_exit.c is now even later and in a
different file. I think 1.276 and 1.284 had no significant effect, since
the races for the non-times parts of the rusage are lost before the part
of the code that is moved, and 1.276 and 1.284 don't affect the race for
the times parts.

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: Updated rusage patch
    ... More notes on locking below. ... the same races as in RELENG_4: ... exit1() uses no locking and thus races with statclock. ... The only races that are present when reading without locks are potentially inconsistent rusage where the stats are not all from a single snapshot of the program. ...
    (freebsd-arch)
  • Re: Updated rusage patch
    ... I believe the sched lock locking is necessary for rux. ... The only races that are present when reading without locks are potentially inconsistent rusage where the stats are not all from a single snapshot of the program. ... To fix this we'd have to do the final accumulation under sched_lock the last time we lock it. ...
    (freebsd-arch)