On Sat, Feb 25, 2023 at 3:18 PM Rob Landley <r...@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 _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
