From owner-svn-src-head@FreeBSD.ORG Thu Dec 8 20:53:51 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 AE3A61065677; Thu, 8 Dec 2011 20:53:51 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4B6038FC18; Thu, 8 Dec 2011 20:53:49 +0000 (UTC) Received: by bkbzv15 with SMTP id zv15so2665600bkb.13 for ; Thu, 08 Dec 2011 12:53:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=NUhXvg0m57yhQlA1POZxvMzKEnOpq8D/TtN927xwBwo=; b=Jjn/Vwwd19MJMnECY6r2CFtpqpHkx/+C9B7qL3a0ifSk2UyNB3UCltneeAmUgFyvSK ImVWFFJZPAm0dovJDA20eHfmvKkwCImctCv62P0L3huD/MgCw8hKUiheg4P5RojXquAA bK2NF19e9xD+5hPh67OmKsQeKK0szslXkARIA= Received: by 10.205.130.146 with SMTP id hm18mr1934662bkc.19.1323377629047; Thu, 08 Dec 2011 12:53:49 -0800 (PST) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id e18sm5042095bkr.15.2011.12.08.12.53.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Dec 2011 12:53:46 -0800 (PST) From: Mikolaj Golub To: John Baldwin References: <201111242054.pAOKs6vj012296@svn.freebsd.org> <201111281330.11720.jhb@freebsd.org> <86liqt1ier.fsf@kopusha.home.net> <4EE1024C.6040800@FreeBSD.org> X-Comment-To: John Baldwin Sender: Mikolaj Golub Date: Thu, 08 Dec 2011 22:53:44 +0200 In-Reply-To: <4EE1024C.6040800@FreeBSD.org> (John Baldwin's message of "Thu, 08 Dec 2011 13:30:36 -0500") Message-ID: <86k466aip3.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 20:53:51 -0000 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'? :-) 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: cputime filesize datasize stacksize coresize rmemuse memlocked maxproc openfiles sbsize vmemuse openpts swapuse or any other names, just so I wouldn't need to hardcode the names in procstat? -- Mikolaj Golub