cvs commit: src/sys/kern kern_resource.c
nate at root.org
Mon Feb 9 09:42:49 PST 2004
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.
More information about the cvs-all