Date: Mon, 07 Feb 2005 01:19:12 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: PeterJeremy@optushome.com.au Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/bin/ps keyword.c Message-ID: <20050207.011912.48399340.imp@bsdimp.com> In-Reply-To: <20050207081054.GA57554@cirb503493.alcatel.com.au> References: <200502061634.j16GYnuv025551@repoman.freebsd.org> <20050206184516.GB1080@darkness.comp.waw.pl> <20050207081054.GA57554@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20050207081054.GA57554@cirb503493.alcatel.com.au>
Peter Jeremy <PeterJeremy@optushome.com.au> writes:
: On Sun, 2005-Feb-06 19:45:16 +0100, Pawel Jakub Dawidek wrote:
: >On Sun, Feb 06, 2005 at 04:34:49PM +0000, Christian S.J. Peron wrote:
: >+> Since it is not un-common for a process's resident set size (rss)
: >+> to exceed 10 megabytes in size (especially in X), bump the max
: >+> column width from 4 bytes to 5. This will make the ps auxw output
: >+> uniform again when a process's rss exceeds 10 megs.
: >
: >Maybe we can use humanize_number(3) here?
:
: Please ensure that if you do use humanize_number(3), there is a way of
: getting rss and vsz values in fixed units. Tru64 switches between MB
: and GB is ps output (which can't be disabled). I regularly need to
: look at processes by size and it's very annoying to have 2.5GB and
: 2.5MB processes mixed together.
There are also people that use ps to get a feel for the size of
processes and if they appear to be growing or not. Jumping to the
next larger size is great for humans, but lousy for programs. It
would also tend to obsure the 'noise' in the number, the very thing
that our scripts are interested in.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050207.011912.48399340.imp>