cvs commit: src/sys/kern kern_resource.c

[Nate Lawson]

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:
> >
> > > jhb         2004/02/06 11:30:12 PST
> > >
> > >   FreeBSD src repository
> > >
> > >   Modified files:
> > >     sys/kern             kern_resource.c
> > >   Log:
> > >   - Correct the translation of old rlimit values to properly handle the old
> > >     RLIM_INFINITY case for ogetrlimit().
> > >   - Use %jd and intmax_t to output negative time in usec in calcru().
> > >   - 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.

-Nate