Date: Tue, 3 Nov 2009 22:31:49 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Xin LI <delphij@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r198848 - head/bin/ps Message-ID: <20091103214231.H23957@delplex.bde.org> In-Reply-To: <200911030928.nA39SjLx085597@svn.freebsd.org> References: <200911030928.nA39SjLx085597@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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). %CPU != CPU. Modern systems don't really have more %CPU. The maximum percentage of anything is still 100.0. However, there are various bugs that result in a percentage of 100.0 being misdisplayed and "percentages" of more than 100.0 occurring: - ps used %4.1f format. This works for all percentages <= 99.9 (after rounding), but not for 100.0. Now ps uses %5.1 format, so 100.0 is displayed correctly, but all normal percentages are displayed worse than before (space that is not available is used to make them harder to read). - %CPU is not divided by the number of CPUs. Thus a multi-threaded process can have %CPU almost as large as <number of CPUs> * 100.0. This might be a feature. E.g., on mostly-idle systems, the idle process consists of <number of CPUs> threads which take akmost 100.0% CPU each, so the total %CPU for the idle process is almost the above maximum (it is now 799.2 on ref8.freebsd.org due to ref8 having 8 mostly-idle CPUs). Since ps now uses %5.1 format, it can display %CPU correctly on all systems with <= 9 CPUs, and on most systems with 10 CPUs (since the value of 1000.0 which is too wide for %5.1 format is even harder to reach on a 10-CPU system than the value of 100.0 which is too wide for %4.1 format is to reach on 1 a-CPU system). The format is still broken on systems with >= 11 CPUs. - perhaps schedular bugs can result in %CPU being transiently slightly greater than 100.0 for an individual thread. Expanding %CPU doesn't truncate "ps l" since "ps l" doesn't print %CPU. Thus the recent truncation is only from 11 COMMAND columns to 9 instead of to 8. 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). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091103214231.H23957>