[Toybox] [PATCH] ps: widen the VSIZE field for Android's default view.

[enh]

On Fri, Feb 24, 2023 at 3:28 PM Rob Landley <rob at landley.net> wrote:
>
> On 2/23/23 14:35, enh via Toybox wrote:
> > On LP64 systems, address space is effectively free,
>
> I remember when the ipv6 guys said that back in the 1990's. This is why
> wikipedia[citation needed] blocks editing from the entire v6 address space.
>
> > and the security
> > folks have found a variety of ways to use large PROT_NONE regions. For
> > example, Android currently spends 3GiB on the CFI shadow and 7GiB
> > padding the scudo heap, meaning that even toybox cat has a VmSize around
> > 10GiB. This means that the default ps output doesn't line up.
>
> And this is why resident set size was invented.

oh, yeah, and that's literally the next column in the default Android
ps output ... the trouble is, i'm a coward, and i don't feel like
removing VSIZE from the default ps output. specifically: i'm assuming
that people are parsing this output, and i'll break them if i do this,
and the benefit of not confusing people who're actually _looking_ at
the numbers is less than the cost of breaking all those scripts. (that
is, after all, the very reason why the _Android_ default for toybox ps
is different from the "default default"!)

> Is there an "RSS if everything actually populated was faulted in" metric? RSS
> plus swap space plus nonresident file backed pages? Hmmm... It really gets down
> to "what do we WANT to be measuring here, and why"?
>
> Sigh. SZ and VSZ are the same SLOT_vsize with different units:
>
>     else if (which==PS_SZ) ll >>= 12;
>     else if (which==PS_VSZ) ll >>= 10;
>
> (Which implies the "ps -o help" description of SZ is wrong because that implies
> it's RSS instead of VSZ. Or is the SLOT entry wrong and it SHOULD be SLOT_rss? I
> tested all of this by hand at one point...)
>
> Not digging into it right now. That said, If RSS _isn't_ the right metric, then
> the next place to look would be /proc/self/smaps_rollup which I believe is newer
> than this code and just... sigh. Did they add any of those new metrics to
> /proc/self/stat? No of course they didn't, why would they do that...
>
> > Arguably this should be a change to the default width (currently 7) of
> > the VSZ entry in the "typos" array, but as long as desktop Linux isn't
> > using its address space for security mitigations, that seemed like it
> > might be too contentious.
>
> Possibly it argues that the VSZ units should be something other than 1k, but
> mostly I think it argues that VSZ has become somewhat meaningless on android?

yeah, top doesn't have as much of a problem (beyond raising the
question of "why does everything have the same vsize?") because it
uses the human-readable "10G" form instead. but if i was brave enough
to change ps' units, i'd be brave enough to just remove the
not-very-meaningful-on-Android field (that ironically is only shown by
default on Android, because it was _very_ meaningful back in the
32-bit days!).

> *shrug* Applied, but this is kinda whistling past some design questions...
>
> Rob