Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 9 Feb 2004 09:42:48 -0800 (PST)
From:      Nate Lawson <nate@root.org>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        Tim Robbins <tjr@FreeBSD.org>
Subject:   Re: cvs commit: src/sys/kern kern_resource.c
Message-ID:  <20040209094012.C73740@root.org>
In-Reply-To: <20040208074351.Y58537@gamplex.bde.org>
References:  <200402061930.i16JUCpa011145@repoman.freebsd.org> <20040208074351.Y58537@gamplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040209094012.C73740>