cvs commit: src/sys/kern kern_resource.c

[John Baldwin]

On Monday 09 February 2004 07:45 pm, Nate Lawson wrote:
> 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.

Are one of you two going to implement that then?

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org