Date: Mon, 13 Mar 2006 12:36:14 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: Kostik Belousov <kostikbel@gmail.com>, stable@freebsd.org Subject: Re: Failing to understand getrusage() Message-ID: <20060313103614.GJ37572@deviant.kiev.zoral.com.ua> In-Reply-To: <20060310224950.GC75952@comp.chem.msu.su> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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+--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060313103614.GJ37572>