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

[enh]

On Sat, Feb 25, 2023 at 3:18 PM Rob Landley <rob at landley.net> wrote:
>
> On 2/24/23 17:34, enh wrote:
> >> 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"!)
>
> You're the one who added those fields. :)
>
> (Less is both more and also as yet unimplemented even in pending, although
> which.c is at least the first half of it...)
>
> >> 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!).
>
> I use -O a lot. (The other ps implementations don't have that useful an -O, but
> "ps -o help" and then "ps -aO ruser,tid" is _more_ useful the fewer base display
> fields there are. And I made sure that if the header gives a field name, you can
> feed that name to -o or -O regardless of what anybody else's implementation did
> because it annoys ME otherwise. Including converting "NICE" and friends posix
> aliases back to the names from the help text. :)

i use -O a lot too, but i'm not worried about humans --- i think the
fact that "VSIZE is basically always 10GiB" is a pretty convincing
"you don't _actually_ need this" for any humans. my concern is not
breaking _scripts_.

> Yeah, you can do -o but "ps -o UID" doesn't even tell you the PID. You have to
> remember the PID,TTY,TIME,$STUFF,CMD sandwich to get "extra" standard output
> instead of just adding stuff to it. (TIME is a big silly but the
> PID,TTY,$STUFF,CMD part is all useful.)
>
> (Yes, it's a hack that -O backs up one from the end and inserts stuff there, but
> the assumption is the last field is the big command line thing that will eat all
> available space, because that's where you HAVE to put it if anything else is
> going to be aligned...)
>
> >> *shrug* Applied, but this is kinda whistling past some design questions...
>
> Backwards compatibility sucks. One of the big historical advantages of unix was
> keeping the base small so you could always at least fall _back_ to something
> simple. And yes that includes "rm -rf ." instead of gnu/systemd style nonsense like:
>
>   fsedit command=remove --recurse --no-prompt --delete-readonly --no-progress
>   --remove-empty-directories --pattern='*' --case-sensitive --any-owner
>   --continue-past-errors --no-throttle --no-one-file-system --in-foreground
>   --and-so-on...
>
> What was that insane search dictionary thing that a cron job ran on the whole
> filesystem to create a database of where each file was every night? Meaning as
> soon as you powered it up in the morning the disk was busy for twenty minutes...
> It was one of the things I had to kill when installing early redhat systems,
> along with the world readable NFS exports and so on, and is one of the reasons I
> despise cron to this day...

(locate. fwiw, i love it. i used to turn it and the macOS equivalent
off back in the days of spinning rust, but i don't even notice them
any more. tbh, i don't even know whether they run via cron or
inotify.)

> Cygnus, "Your Gnu Support". Red Hat Bought them back in the late 90's. It had
> some distinct negative side effects for a while...
>
> Sigh. I dunno, one possibility is to redefine -O work off a "PID,TTY,$STUFF,CMD"
> base regardless of context? Modulo that could still break stuff for you, and the
> current code is adding the various -f and -w nonsense to that base before
> backing up and inserting -O at the next-to-last position...

yeah, i think probably the best we can do without risking the backward
compatibility world of pain is to have better field auto-sizing
(rather than the hardcoded "7" and the Android-override "11" we have
atm). so at least then there's only the one special case, rather than
a special case on top of a special case :-)

obviously "i don't know what i don't know", but i can't actually find
anything internally at least that's parsing this. so maybe we could
try removing it from the defaults and seeing what (if anything)
_actually_ breaks. probably not right now though!

> Hmmm. I haven't implemented -x yet. (I have a whole second pass on ps to do the
> "ps ax" and "ps -ax" are different thing. I have plumbing! FLAGS_NODASH is set
> when you provided non-dash arguments...) There could be a new simpler type of
> output. But "there's too much complexity let's add something" seldom ends well...

has anyone noticed yet? i feel like the BSD syntax has kind of died out?

> >> Rob
>
> Rob