From owner-svn-src-all@FreeBSD.ORG Tue Nov 3 11:31:55 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78981106566C; Tue, 3 Nov 2009 11:31:55 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 140D18FC13; Tue, 3 Nov 2009 11:31:54 +0000 (UTC) Received: from c220-239-235-116.carlnfd3.nsw.optusnet.com.au (c220-239-235-116.carlnfd3.nsw.optusnet.com.au [220.239.235.116]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id nA3BVoHl030841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Nov 2009 22:31:52 +1100 Date: Tue, 3 Nov 2009 22:31:49 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Xin LI In-Reply-To: <200911030928.nA39SjLx085597@svn.freebsd.org> Message-ID: <20091103214231.H23957@delplex.bde.org> References: <200911030928.nA39SjLx085597@svn.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r198848 - head/bin/ps X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 11:31:55 -0000 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 * 100.0. This might be a feature. E.g., on mostly-idle systems, the idle process consists of 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