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

[Rob Landley]

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. :)

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...

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...

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...

>> Rob

Rob