[Toybox] [PATCH] top: don't report GiB sizes in KiB.

[enh]

On Fri, Sep 11, 2020 at 11:41 AM Rob Landley <rob at landley.net> wrote:

> On 9/10/20 1:42 PM, enh wrote:
> >     The design is short of shifting out from under human_readable(). The
> above
> >     probably fixes it, but if this happens again I should step back and
> rethink the
> >     objective here. (Specifying units instead of autodetecting them,
> >
> > fwiw, that's how both Android and Chrome's equivalents ended up: two
> variants,
> > one with auto-detection and another where the caller passes in the units.
>
> I added an argument to pass in the units. It can auto-adjust up from there
> if
> there aren't enough digits, but not down. Not supplying enough digits to
> display
> a number in the units you want is pilot error.
>
> >     possibly a
> >     version that operates on an array of values instead of one at a
> time.
> >
> >
> > (but that's an interesting idea too.)
> >
> >
> >     There's a
> >     lot of "measure all the output so it matches up" ala ls, and no
> generic plumbing
> >     to handle that, but a design for efficient plumbing to handle that
> is not
> >     immediately obvious to me. Hmmm...)
> >
> > that's something i've wondered about a couple of  times too, but  i
> think that's
> > an orthogonal  problem to this one. ls deliberately mismatches units, and
> > despite what i've said here about consistency in tables, i think that's
> the
> > right behavior for ls. you don't have any reason to  expect that the
> entries in
> > ls' output are likely to be at all similar, whereas with top you're
> basically
> > carving up your available RAM, so the entries are effectively
> "percentages that
> > humans can grok better" :-)
>
> The "top" entries are already auto-adjusting units:
>
>   PID USER         PR  NI VIRT  RES  SHR S[%CPU] %MEM     TIME+ ARGS
> 13347 landley      20   0 6.1M 1.7M 1.5M R 35.1   0.0   0:00.05 top
> 31919 landley      20   0 1.5G 238M  94M S  5.4   1.4  34:45.26 chromium
> --type+
> 11907 landley      20   0 4.7G 1.3G 119M S  5.4   8.3 935:00.04 chromium
> --show+
>
> Chromium is being its usual self, and we have 4 characters per memory
> field.
>
> Right now I have a patch to make the commas just care about "1,234.5" vs
> "1.234,5" as a binary choice (which covers the vast majority of the
> planet, and
> will never matter on android anyway because you nerfed that), vs a patch to
> revert the whole mess back to how it was before I started meddling with it.
>
> (I looked at removing and commas but keeping the megabyte forcing, which
> gets
> back to "with 8 digits of space 64 gigs would still show as kilobytes,
> which is
> what you were objecting to in the first place, despite that being what
> debian
> does for me with 16 gigs of ram I.E. 8 digits"...)
>

do you have an older or newer top than me? i gave my version number before
(procps-ng 3.3.16) but didn't explicitly say i was doing so in order for
you to be able to compare. i get MiB even on a box with only 16GiB.


> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20200911/df5cebcc/attachment-0001.htm>