From owner-cvs-src@FreeBSD.ORG Tue Feb 10 10:04:56 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A298116A4CE for ; Tue, 10 Feb 2004 10:04:56 -0800 (PST) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8859E43D2F for ; Tue, 10 Feb 2004 10:04:56 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 27943 invoked from network); 10 Feb 2004 18:04:55 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 10 Feb 2004 18:04:55 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i1AI4oM0087821; Tue, 10 Feb 2004 13:04:51 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Nate Lawson , Bruce Evans Date: Tue, 10 Feb 2004 11:20:11 -0500 User-Agent: KMail/1.5.4 References: <200402061930.i16JUCpa011145@repoman.freebsd.org> <20040210101904.C50462@gamplex.bde.org> <20040209164309.L75509@root.org> In-Reply-To: <20040209164309.L75509@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200402101120.11815.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: Tim Robbins Subject: Re: cvs commit: src/sys/kern kern_resource.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2004 18:04:56 -0000 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 <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org