cvs commit: src/sys/kern kern_resource.c

[Bruce Evans]

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?

I had it changed to use sched_lock for a few minutes, then decided
that Giant was not too bad here.  We already have to use sched_lock
for the RUSAGE_SELF case so it's silly to use another lock too.  The
p_cru change in kern_exit.c is locked by the following: Giant,
PROC_LOCK(p), and not quite by sched_lock (sched_lock is released just
before), so we can use any of these in getrusage().  I decided not to
use sched_lock because I want to drop it earlier (after readinf the
times in calcru()).  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().

Bruce