svn commit: r227956 - head/usr.bin/procstat
John Baldwin
jhb at FreeBSD.org
Thu Dec 8 21:32:18 UTC 2011
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
More information about the svn-src-head
mailing list