From owner-freebsd-stable@FreeBSD.ORG Mon Mar 13 10:37:05 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1A0C16A400 for ; Mon, 13 Mar 2006 10:37:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (ll-227.216.82.212.sovam.net.ua [212.82.216.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 037E743D45 for ; Mon, 13 Mar 2006 10:37:03 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.3/8.13.3) with ESMTP id k2DAaHIS069832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Mar 2006 12:36:17 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k2DAaHie046958; Mon, 13 Mar 2006 12:36:17 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.4/8.13.4/Submit) id k2DAaEdR046948; Mon, 13 Mar 2006 12:36:14 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 13 Mar 2006 12:36:14 +0200 From: Kostik Belousov To: Yar Tikhiy Message-ID: <20060313103614.GJ37572@deviant.kiev.zoral.com.ua> References: <44077091.3060604@freebsd.org> <80813.1141343429@thrush.ravenbrook.com> <20060306231556.GB64952@comp.chem.msu.su> <20060307101156.GF37572@deviant.kiev.zoral.com.ua> <20060307150631.GC82066@comp.chem.msu.su> <20060307161259.GG37572@deviant.kiev.zoral.com.ua> <20060310224950.GC75952@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sWvRP97dwRHm9fX+" Content-Disposition: inline In-Reply-To: <20060310224950.GC75952@comp.chem.msu.su> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on fw.zoral.com.ua Cc: Kostik Belousov , stable@freebsd.org Subject: Re: Failing to understand getrusage() X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 10:37:05 -0000 --sWvRP97dwRHm9fX+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 11, 2006 at 01:49:50AM +0300, Yar Tikhiy wrote: > On Tue, Mar 07, 2006 at 06:12:59PM +0200, Kostik Belousov wrote: > >=20 > > It may be desirable to add ru_maxrss sampling at the calcru time too. > > Something like this: > >=20 > > Index: sys/kern/kern_resource.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > RCS file: /usr/local/arch/ncvs/src/sys/kern/kern_resource.c,v > > retrieving revision 1.156 > > diff -u -r1.156 kern_resource.c > > --- sys/kern/kern_resource.c 22 Feb 2006 16:58:48 -0000 1.156 > > +++ sys/kern/kern_resource.c 7 Mar 2006 16:10:27 -0000 > > @@ -853,9 +853,16 @@ > > struct rusage *rup; > > { > > struct proc *p; > > + struct vmspace *vm; > > + long rss; > > =20 > > p =3D td->td_proc; > > PROC_LOCK(p); > > + vm =3D p->p_vmspace; > > + rss =3D pgtok(vmspace_resident_count(vm)); > > + if (rup->ru_maxrss < rss) > > + rup->ru_maxrss =3D rss; > > + > > switch (who) { > > =20 > > case RUSAGE_SELF: > >=20 >=20 > Please excuse me for a dumb question, but what makes ru_maxrss so > different from other ru_ fields that it deserves special handling > in kern_getrusage()? Perhaps the all-or-nothing approach will be > better for the sake of consistency... Current resource usage accounting is inaccurate (i.e. done at sampling points) only for several fields, ru_maxrss being one of them. E.g., ru_nsignals is precise. Sure, the best would be implementing approach like solaris microaccounting (AFAIR, solaris could measure used parts of the time-slice where the thread runs on CPU, and do this measure on demand, not stressing the system when the exact numbers are not needed). My small fix just add little more sence to result of maxrss calculation, making it to never return meaningless values like 0. Better, pmaps shall be modified to correctly set maxrss (this seems to be not hard, could someone look at the patch if I implement it ?). --sWvRP97dwRHm9fX+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEFUseC3+MBN1Mb4gRAstYAKCnpO9QypqvY6dtvaoXHokHfLTZ3ACg13vS wkfgS8qHBHI6cqjFM+eGN7A= =FxQj -----END PGP SIGNATURE----- --sWvRP97dwRHm9fX+--