Date: Wed, 11 Nov 2009 23:22:36 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: d@delphij.net Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Xin LI <delphij@FreeBSD.org>, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r198848 - head/bin/ps Message-ID: <20091111230915.B3510@besplex.bde.org> In-Reply-To: <4AF4B6B2.3090706@delphij.net> References: <200911030928.nA39SjLx085597@svn.freebsd.org> <20091103214231.H23957@delplex.bde.org> <4AF4B6B2.3090706@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 6 Nov 2009, Xin LI wrote: > Bruce Evans wrote: >> On Tue, 3 Nov 2009, Xin LI wrote: >> >>> Log: >>> Increase width for %CPU, RSS and VSZ columns for now. Modern systems >>> tend to have larger memory, larger process, and more CPU. >> >> This uses space that is not available. Command names(+args) are now >> truncated to 9 columns in "ps l" output :-(. They used to be truncated to >> 11 columns recently (down from 12 columns in FreeBSD-5.2). > > I think we may have to live with this, even if we can cut down CPU > percentage part, the memory column's width is still too narrow for > modern systems. Still only for modern systems running bloatware, and ps looking at the bloatware. > I have actually thought about having the numbers > humanized but I'm afraid it would break some existing scripts :( Maybe there should be a special mode for scripts. Scripts shouldn't care about the whitespace formatting (they should detect fields using field separators and not specific columns). > [...] >> There seems to be no better fix than to further granulate and dehumanize >> the numbers so that they fit in the available space. E.g., a %CPU of >>> = 100 and < 9999 should be displayed in %4.0f format; this only >> involvues granulation, but above 9999 it needs to be dehumanized as >> well and displayed in k or M or larger granularity (it can be > 9999 >> with 100 CPUs and > 999k with 10000 CPUs). A VSZ of >= 10000 (k >> implicit) needs to be displayed in M or larger granularity (M explicit). > > Will it sound reasonable to divide pcpu by ncpu and cap the number at 100? I don't like that. It would break scripts even more than units changes. It is hard for users to interpret too. Suddenly, processes taking 100% of 1 CPU would take 12.5% of 8 CPUs on a system with 8 CPUs, and different %CPU on systems with a different number of CPUs. Users would need to know the number of CPUs and convert back. This is too surprising, especially for unthreaded processes. OTOH, users must already be used to seeing %CPU > 100 and dividing by the number of CPUs to get a more easy to understand number for threaded processes. Just print %CPU in %4.0f format when it is >= 99.5 (or whatever rounds to 100.0). This works up to 999.5 %CPU. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091111230915.B3510>