cvs commit: src/sys/kern kern_resource.c

[Nate Lawson]

On Tue, 10 Feb 2004, Bruce Evans wrote:
> On Mon, 9 Feb 2004, Nate Lawson wrote:
>
> > On Sun, 8 Feb 2004, Bruce Evans wrote:
> > > On Sat, 7 Feb 2004, Tim Robbins wrote:
> > > > On Fri, Feb 06, 2004 at 11:30:12AM -0800, John Baldwin wrote:
> > > > >   ...
> > > > >   - Rework getrusage() to make a copy of the rusage struct into a local
> > > > >     variable while holding Giant and then do the copyout from the local
> > > > >     variable to avoid having to have the original process rusage struct
> > > > >     locked while doing the copyout (which would not be safe).  This also
> > > > >     includes a few style fixes from Bruce to getrusage().
> > > >
> > > > Thanks (from the one who added the XXX comment). Can't we use the
> > > > proc lock here though?
> > >
> > > calcru() takes about 4.5 usec on a Celeron 366
> > > with a TSC timecounter, and this is too long to hold a spin lock since,
> > > while it is not too bad in absolute terms, it scales to 100+ usec on
> > > old machines that used to have an interrupt latency of much smaller
> > > than 100 usec.  Another way to look at the relative largeness of 4.5
> > > usec: vfork()+exit()+wait() for a small process takes about 86 usec
> > > on a Celeron 366, and 4.5 usec of that is for calcru().
> >
> > What if calcru() were postponed until the process lifetime was a minimum
> > quantum?  This sounds like we should be concerned about the vfork/exec
> > case if your above example applies.
>
> Postponing it for a quantum wouldn't help much (it would either give
> very inaccurate times or cost the same as now), but postponing it
> forever might help.  exit1() would have to read the current time (this
> is needed anyway to set switchtime), but there is no need to calculate
> the resource usage unless an ancestor actually uses
> getrusage(RUSAGE_CHILDREN, ...).  ruadd() would add tick counts instead
> of times and the RUSAGE_CHILDREN case in getrusage() would call calcru()
> to scale the tick counts like the RUSAGE_SELF case already does.  This
> would be a tiny optimization but has another advantage: calcru() has
> rounding errors that accumulate in p_cru and delaying calcru() would
> prevent them accumuating.

I think this is an excellent idea.  I suggested postponing because I
thought the data was used for CPU quotas also, but if it's only used by
getrusage(), your idea should work and make the caller pay the cost of
units conversion.

-Nate