From owner-cvs-all@FreeBSD.ORG Mon Feb 9 16:45:08 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCFC816A4D0 for ; Mon, 9 Feb 2004 16:45:08 -0800 (PST) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 9CFBF43D1F for ; Mon, 9 Feb 2004 16:45:08 -0800 (PST) (envelope-from nate@root.org) Received: (qmail 75528 invoked by uid 1000); 10 Feb 2004 00:45:10 -0000 Date: Mon, 9 Feb 2004 16:45:10 -0800 (PST) From: Nate Lawson To: Bruce Evans In-Reply-To: <20040210101904.C50462@gamplex.bde.org> Message-ID: <20040209164309.L75509@root.org> References: <200402061930.i16JUCpa011145@repoman.freebsd.org> <20040208074351.Y58537@gamplex.bde.org> <20040210101904.C50462@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-all@FreeBSD.org cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: John Baldwin cc: Tim Robbins Subject: Re: cvs commit: src/sys/kern kern_resource.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2004 00:45:08 -0000 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. -Nate