From owner-svn-src-head@FreeBSD.ORG Thu Dec 8 21:32:18 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 0A649106566B; Thu, 8 Dec 2011 21:32:18 +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 AB10D8FC08; Thu, 8 Dec 2011 21:32:17 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 5845146B0A; Thu, 8 Dec 2011 16:32:17 -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 AE89CB91E; Thu, 8 Dec 2011 16:32:16 -0500 (EST) Message-ID: <4EE12CE0.5070803@FreeBSD.org> Date: Thu, 08 Dec 2011 16:32:16 -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> <4EE1024C.6040800@FreeBSD.org> <86k466aip3.fsf@kopusha.home.net> In-Reply-To: <86k466aip3.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 16:32:16 -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 21:32:18 -0000 On 12/8/11 3:53 PM, Mikolaj Golub wrote: > > On Thu, 08 Dec 2011 13:30:36 -0500 John Baldwin wrote: > > JB> 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 > > JB> Hmm, I would stick as close to limits output as possible. I would > JB> consider duplicating the unit field in each of soft and hard, so you > JB> end up with something like this: > > JB> PID COMM RLIMIT SOFT HARD > JB> 48798 zsh cputime 100000 secs infinity secs > JB> 48798 zsh filesize infinity kb infinity kb > JB> 48798 zsh datasize 524288 kb 524288 kb > > JB> etc. > > Ok. > > JB> (Things like 'openfiles' is simply more intuitive than 'nofile' (no > JB> file?, huh? oh, num open files.. (except not all users will make the > JB> last step there). > > Then why do we have so non-intuitive rlimit_ident names? > > It looks like they are used only in procfs_rlimit.c. Do procfs(5) users always > make that last step with 'nofile'? :-) Well, I suspect it's best not to change the names in procfs in case there are existing binaries that parse the output of that file (unfortunately). > Is it possible to change rlimit_ident names? Just to ones that are used by > limit(1) or (if they look too long) to something like below: Hmm, I have no idea what other things might use rlimit_ident. Probably not many. (Also, for fun, note that the 'ulimit' and 'limit' built-in commands in sh and csh also have their own sets of names, fun!) I would maybe add a rlimit_names[] (just leave rlimit_ident alone), and give that the names from limits(1), and change both procstat and sh's 'ulimit' command to use those. -- John Baldwin