From owner-cvs-src@FreeBSD.ORG Tue Feb 8 05:45:44 2005 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 5BEBC16A525; Tue, 8 Feb 2005 05:45:44 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB39E43D45; Tue, 8 Feb 2005 05:45:43 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])j185jaA6012528; Tue, 8 Feb 2005 16:45:36 +1100 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j185jXVU028880; Tue, 8 Feb 2005 16:45:34 +1100 Date: Tue, 8 Feb 2005 16:45:33 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: "M. Warner Losh" In-Reply-To: <20050207.011912.48399340.imp@bsdimp.com> Message-ID: <20050208162733.C21504@delplex.bde.org> References: <200502061634.j16GYnuv025551@repoman.freebsd.org> <20050207081054.GA57554@cirb503493.alcatel.com.au> <20050207.011912.48399340.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: PeterJeremy@optushome.com.au cc: src-committers@FreeBSD.org cc: pjd@FreeBSD.org cc: cvs-all@FreeBSD.org cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/bin/ps keyword.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, 08 Feb 2005 05:45:44 -0000 On Mon, 7 Feb 2005, M. Warner Losh wrote: > In message: <20050207081054.GA57554@cirb503493.alcatel.com.au> > Peter Jeremy 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. I agree that jumping to the next size is only great for those humans who are not people. I disagree that it is lousy for programs. humanize_number() basically gives numbers in scientific notation. This is great for programs and in limited domains where the range of numbers is very large, but few humans think in it. humanize_number() should be named something like hidefy_number(), and df's -h flag should be described as giving hideous or human-unreadable output. The point about "noise" in the output is good. If apply to affect df so much. It applies to programs that periodically repeat output like iostat(1) more. Bruce