[Toybox] human_readable top header.

[enh]

On Thu, May 16, 2019 at 5:08 PM Rob Landley <rob at landley.net> wrote:
>
> This commit from february says:
>
> commit 706628b94e65cfa9e583d7a54d7cdd8de9f70c63
> Author: Elliott Hughes <enh at google.com>
> Date:   Wed Feb 13 15:10:29 2019 -0800
>
>     top: use human_readable for the header lines too.
>
>     Even phones have enough RAM these days that KiB is not a reasonable
>     unit. Traditional top always uses MiB instead of always using KiB, but
>     we may as well just let human_readable pick a unit (that way if KiB is
>     reasonable on your box, that's what you'll get).
>
> Except it doesn't.

huh. why are we never running the same version of anything? it does
for me on current debian testing (claims to be "procps-ng 3.3.15"):

$ top -b
top - 21:06:16 up 95 days,  9:05, 10 users,  load average: 0.36, 0.53, 0.57
Tasks: 313 total,   1 running, 312 sleeping,   0 stopped,   0 zombie
%Cpu(s):  5.1 us,  4.4 sy,  0.0 ni, 89.2 id,  0.0 wa,  0.0 hi,  1.3 si,  0.0 st
MiB Mem :  15980.6 total,   3967.8 free,   6903.5 used,   5109.4 buff/cache
MiB Swap:  32520.0 total,  32032.9 free,    487.1 used.   8394.0 avail Mem

whereas toybox is now back to unreasonably small units on the same laptop:

  Mem: 16364136K total, 12297484K used,  4066652K free,  1187844K buffers
 Swap: 33300476K total,   498780K used, 32801696K free,  3706260K cached

fwiw, my procps top doesn't step up to GiB even on a much larger
machine where it would make sense:

MiB Mem : 192123.8 total,   8967.9 free,  32008.4 used, 151147.6 buff/cache

> Linus Torvalds' first 386 in 1991 had 4 megs ram, meaning 4
> digits, which would be shown as 4.0M losing precision already.

aye, but this is 2019 :-)

but more to the point, i think showing KiB is fine if you have a small
number of MiB of ram. but when you have several GiB, KiB becomes
unreadable.

in the examples above, i'm not convinced MiB is a good choice. it's
just less bad than KiB.

> The problem is human_readable gives you 3 digits plus a unit, so instead of
> devuan's kilobytes (yes, still, in the current release):
>
> Tasks: 509 total,   2 running, 507 sleeping,   0 stopped,   0 zombie
> %Cpu(s): 43.6 us,  9.4 sy,  0.1 ni, 44.8 id,  2.1 wa,  0.0 hi,  0.0 si,  0.0 st
> KiB Mem : 16340584 total,   616500 free, 14289944 used,  1434140 buff/cache
> KiB Swap: 16679932 total, 13636264 free,  3043668 used.   775996 avail Mem
>
> You get:
>
> Tasks: 507 total,   4 running, 503 sleeping,   0 stopped,   0 zombie
>   Mem:       16G total,       15G used,      681M free,       42M buffers
>  Swap:       16G total,      2.9G used,       13G free,      1.2G cached
> 400%cpu  55%user   0%nice  42%sys 303%idle   0%iow   0%irq   0%sirq   0%host
>
> There's a whole lot of empty space in that display,

i'd deny that "expand to fill all available space" should be a goal
though. (insert Chrome joke here...)

quite the opposite... i find the GiB display intelligible at a glance,
but i have to count digits in the former to work out what to divide by
to get meaningful units.

> and when my laptop is
> swap-thrashing  and Swap "used" is going down 4 megabytes/second (took me about
> a week to do it to the new one, chrome is a memory hog _and_ won't show you more
> than about 80 tabs/window), I can't even _see_ that on this display.
>
> (Aside: a machine with >99 procesors would run out of space for the percentages.
> Possibly at some point that should go back to 100% for the totals?)

(yeah, i've never been convinced that the current percentage format is
very usable.)

unrelated, toybox top seems to sometimes lose the unit now? missing
'K' in buffers here:

  Mem:  3633708K total,  3132544K used,   501164K free,   8499200 buffers

oh, no, that's actually bytes judging by /proc/meminfo:

Buffers:            8300 kB

so, yeah, mixed units is another way in which i think this change is
significantly worse. (even ignoring the fact that this bogusly implies
that we have better-than-KiB data, which we don't.)

> Aesthetic issues are always hard. Possibly what I need to do is add a display
> size field to human_readable so it knows how many digits of output to produce,
> and when there's more than 3 don't decimalize, just do "12146M" and such.
>
> Rob
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net