From owner-svn-src-head@FreeBSD.ORG Thu Dec 8 18:30:37 2011 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDD47106564A; Thu, 8 Dec 2011 18:30:37 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 836EB8FC15; Thu, 8 Dec 2011 18:30:37 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 34EE346B23; Thu, 8 Dec 2011 13:30:37 -0500 (EST) Received: from John-Baldwins-MacBook-Air.local (c-68-36-150-83.hsd1.nj.comcast.net [68.36.150.83]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 99A0AB93E; Thu, 8 Dec 2011 13:30:36 -0500 (EST) Message-ID: <4EE1024C.6040800@FreeBSD.org> Date: Thu, 08 Dec 2011 13:30:36 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Mikolaj Golub References: <201111242054.pAOKs6vj012296@svn.freebsd.org> <201111281330.11720.jhb@freebsd.org> <86liqt1ier.fsf@kopusha.home.net> In-Reply-To: <86liqt1ier.fsf@kopusha.home.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 08 Dec 2011 13:30:36 -0500 (EST) Cc: svn-src-head@freebsd.org, Robert Watson , svn-src-all@freebsd.org, src-committers@freebsd.org, Kostik Belousov Subject: Re: svn commit: r227956 - head/usr.bin/procstat X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 18:30:37 -0000 On 12/3/11 3:58 PM, Mikolaj Golub wrote: > > On Mon, 28 Nov 2011 13:30:11 -0500 John Baldwin wrote: > > JB> On Thursday, November 24, 2011 3:54:06 pm Mikolaj Golub wrote: > >> Author: trociny > >> Date: Thu Nov 24 20:54:06 2011 > >> New Revision: 227956 > >> URL: http://svn.freebsd.org/changeset/base/227956 > >> > >> Log: > >> usr.bin/procstat > >> > >> Add -l flag to display resource limits. > >> > >> PR: bin/161257 > >> Reviewed by: kib > >> MFC after: 2 weeks > > JB> Thanks for doing this! Did you consider making the procstat -l output use > JB> "pretty" output similar to the output of /usr/bin/limits? For example, > JB> using "infinity" instead of -1 and using humanize_number() for finite limits > JB> that are in units of bytes? > > I tried several variants, from one where for rlimit names rlimit_ident > constants from sys/resource.h are used and units are printed as suffixes: > > PID COMM RLIMIT SOFT HARD > 46150 zsh cpu 100000S infinity > 46150 zsh fsize infinity infinity > 46150 zsh data 524288kB 524288kB > 46150 zsh stack 65536kB 65536kB > 46150 zsh core 9765625kB 9765625kB > 46150 zsh rss infinity infinity > 46150 zsh memlock infinity infinity > 46150 zsh nproc 5547 5547 > 46150 zsh nofile 11095 11095 > 46150 zsh sbsize infinity infinity > 46150 zsh vmem infinity infinity > 46150 zsh npts infinity infinity > 46150 zsh swap infinity infinity > > to one where rlimit names are the same as in limits(1) and units are printed > in separate column: > > PID COMM RLIMIT SOFT HARD UNIT > 48885 zsh cputime 100000 infinity secs > 48885 zsh filesize infinity infinity bytes > 48885 zsh datasize 524288k 524288k bytes > 48885 zsh stacksize 65536k 65536k bytes > 48885 zsh coredumpsize 95367M 95367M bytes > 48885 zsh memoryuse infinity infinity bytes > 48885 zsh memorylocked infinity infinity bytes > 48885 zsh maxprocesses 5547 5547 > 48885 zsh openfiles 11095 11095 > 48885 zsh sbsize infinity infinity bytes > 48885 zsh vmemoryuse infinity infinity bytes > 48885 zsh pseudo-terminals infinity infinity > 48885 zsh swapuse infinity infinity bytes > > Personally I like the first variant as the most compact and the easiest to > maintain but would be glad to learn what other think about this or may be have > other suggestions. > > A couple other variations: > > PID COMM RLIMIT SOFT HARD UNIT > 47062 zsh cpu 100000 infinity secs > 47062 zsh fsize infinity infinity bytes > 47062 zsh data 524288k 524288k bytes > 47062 zsh stack 67108864 67108864 bytes > 47062 zsh core 9765625k 9765625k bytes > 47062 zsh rss infinity infinity bytes > 47062 zsh memlock infinity infinity bytes > 47062 zsh nproc 5547 5547 > 47062 zsh nofile 11095 11095 > 47062 zsh sbsize infinity infinity bytes > 47062 zsh vmem infinity infinity bytes > 47062 zsh npts infinity infinity > 47062 zsh swap infinity infinity bytes > > PID COMM RLIMIT SOFT HARD UNIT > 48798 zsh cputime 100000 infinity secs > 48798 zsh filesize infinity infinity bytes > 48798 zsh datasize 524288k 524288k bytes > 48798 zsh stacksize 65536k 65536k bytes > 48798 zsh coredumpsize 95367M 95367M bytes > 48798 zsh memoryuse infinity infinity bytes > 48798 zsh memorylocked infinity infinity bytes > 48798 zsh maxprocesses 5547 5547 > 48798 zsh openfiles 11095 11095 > 48798 zsh sbsize infinity infinity bytes > 48798 zsh vmemoryuse infinity infinity bytes > 48798 zsh pseudo-terminals infinity infinity > 48798 zsh swapuse infinity infinity bytes Hmm, I would stick as close to limits output as possible. I would consider duplicating the unit field in each of soft and hard, so you end up with something like this: PID COMM RLIMIT SOFT HARD 48798 zsh cputime 100000 secs infinity secs 48798 zsh filesize infinity kb infinity kb 48798 zsh datasize 524288 kb 524288 kb etc. (Things like 'openfiles' is simply more intuitive than 'nofile' (no file?, huh? oh, num open files.. (except not all users will make the last step there). -- John Baldwin