[Toybox] human_readable top header.

Tue May 21 14:09:09 PDT 2019

On Tue, May 21, 2019 at 1:19 PM Rob Landley <rob at landley.net> wrote:
>
> On 5/20/19 11:19 PM, enh wrote:
> > 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"):
>
> Package: procps
> Version: 2:3.3.12-3+devuan2.1
>
> > $ 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
>
> If the units are too small than the field is probably too big. Given that the
> units move by the thousands the size basically changes in 3 digit increments, so
> instead of 9 digits it sounds like it should have 6?
>
> Or if you want to switch to the procps 3.3.15 display and hardcode megabytes
> with one digit of decimal place, I can do that too...
>
> > 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.
>
> I want a _good_ choice, the question is what? Possibly I should look at total
> memory (since that's the biggest number and a constant) and derive the units
> from that, which means I should be able to supply units _to_ human_readable_big()...

yeah, that sounds like it's along the right lines.

i'm not trying to say "machine where KiB is the right unit don't
exist" so much as "machines where GiB is the right unit (and KiB is
very much not the right unit) do exist".

> >> 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...)
>
> Indeed, trimming the space down might make sense.
>
> > 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.)
>
> Agreed. Hmmm...
>
> >> 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.
>
> Aesthetic issues remain hard.

yeah, though we should be able to recognize something that looks
reasonable on my ridiculous work desktop, my phone, and your
representative 4MiB RAM nommu device when we have it...

> Rob