Date: Tue, 10 Feb 2004 10:49:26 -0800 (PST) From: Nate Lawson <nate@root.org> To: John Baldwin <jhb@FreeBSD.org> Cc: Bruce Evans <bde@zeta.org.au> Subject: Re: cvs commit: src/sys/kern kern_resource.c Message-ID: <20040210104736.M81968@root.org> In-Reply-To: <200402101120.11815.jhb@FreeBSD.org> References: <200402061930.i16JUCpa011145@repoman.freebsd.org> <20040210101904.C50462@gamplex.bde.org> <20040209164309.L75509@root.org> <200402101120.11815.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 10 Feb 2004, John Baldwin wrote: > 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: > > > > > 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? I am having trouble even finding time for ACPI at least through the end of the month so I'm not taking on any new tasks right now. Perhaps phk can add this task to the JKH page for one of our new recruits to pick up. :) -Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040210104736.M81968>