Date: Tue, 10 Feb 2004 11:20:11 -0500 From: John Baldwin <jhb@FreeBSD.org> To: Nate Lawson <nate@root.org>, Bruce Evans <bde@zeta.org.au> Cc: Tim Robbins <tjr@FreeBSD.org> Subject: Re: cvs commit: src/sys/kern kern_resource.c Message-ID: <200402101120.11815.jhb@FreeBSD.org> In-Reply-To: <20040209164309.L75509@root.org> References: <200402061930.i16JUCpa011145@repoman.freebsd.org> <20040210101904.C50462@gamplex.bde.org> <20040209164309.L75509@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 09 February 2004 07:45 pm, Nate Lawson wrote: > On Tue, 10 Feb 2004, Bruce Evans wrote: > > On Mon, 9 Feb 2004, Nate Lawson wrote: > > > 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: > > > > > > ... > > > > > > - 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. > > > > Postponing it for a quantum wouldn't help much (it would either give > > very inaccurate times or cost the same as now), but postponing it > > forever might help. exit1() would have to read the current time (this > > is needed anyway to set switchtime), but there is no need to calculate > > the resource usage unless an ancestor actually uses > > getrusage(RUSAGE_CHILDREN, ...). ruadd() would add tick counts instead > > of times and the RUSAGE_CHILDREN case in getrusage() would call calcru() > > to scale the tick counts like the RUSAGE_SELF case already does. This > > would be a tiny optimization but has another advantage: calcru() has > > rounding errors that accumulate in p_cru and delaying calcru() would > > prevent them accumuating. > > I think this is an excellent idea. I suggested postponing because I > thought the data was used for CPU quotas also, but if it's only used by > getrusage(), your idea should work and make the caller pay the cost of > units conversion. Are one of you two going to implement that then? -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200402101120.11815.jhb>