Date: Sun, 8 Feb 2004 08:04:43 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Tim Robbins <tjr@freebsd.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_resource.c Message-ID: <20040208074351.Y58537@gamplex.bde.org> In-Reply-To: <20040206221255.GA54490@cat.robbins.dropbear.id.au> References: <200402061930.i16JUCpa011145@repoman.freebsd.org> <20040206221255.GA54490@cat.robbins.dropbear.id.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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 _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040208074351.Y58537>