rusage breakdown and cpu limits.

Bruce Evans brde at optusnet.com.au
Tue May 29 23:32:48 UTC 2007


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


More information about the freebsd-arch mailing list