cvs commit: src/sys/kern kern_resource.c

[Bruce Evans]

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.

Brucer