[Toybox] ps down, top to go

[enh]

On Fri, May 6, 2016 at 6:01 PM, Rob Landley <rob at landley.net> wrote:
> On 05/06/2016 01:58 PM, enh wrote:
>> in case you're wondering why i sent the roadmap update saying i'd
>> switched to toybox ps although the ps pid/tid truncation bug i found
>> hasn't been fixed, it's because no current or near-future Android
>> system has max_pid > 65536 anyway.
>
> It's on the todo list! :)
>
>> (for the record, i'm no longer able to reproduce the "tcnt always 0"
>> bug, so you can ignore that. i'll poke more if i see it again.)
>
> I've sometimes had to do a "make clean" when dealing with ps. I'm not
> sure why, and would like to fix it. (Could be pilot error at this end, I
> regularly mix up -a and -A and go "why isn't it showing...")
>
>> as for top, dumpstate's "toolbox top -n 1 -d 1 -m 30 -H” is more or
>> less equivalent to “toybox top -b -n 1 -o
>> pid,tid,user,pr,ni,%cpu,s,vsz,rss,pcy,name -s 6”, except for the fact
>> that toolbox's top shows both thread and process name. so you'll see
>> something like this:
>>
>>  1794  1806 u0_a11   20   0   0% S 1502820K  54016K  fg Binder_1
>>  com.android.onetimeinitializer
>>  1794  1807 u0_a11   20   0   0% S 1502820K  54016K  fg Binder_2
>>  com.android.onetimeinitializer
>>  1811  1811 u0_a24   20   0   0% S 1518092K  57752K  bg
>> ndroid.calendar com.android.calendar
>>  1811  1816 u0_a24   29   9   0% S 1518092K  57752K  bg Jit thread
>> pool com.android.calendar
>
> Wordwrapping in the original?

yeah, sorry. gmail hates long lines.

> Binder_1 is stat[2] and com.android.fruitbasket is argv[0]?

correct. /stat[2] and /cmdline[0].

>> where (manually editing the above just to make the difference more
>> obvious) with toybox i can only get something more like:
>>
>>  1794  1806 u0_a11   20   0   0% S 1502820K  54016K  fg [Binder_1]
>>  1794  1807 u0_a11   20   0   0% S 1502820K  54016K  fg [Binder_2]
>>  1811  1811 u0_a24   20   0   0% S 1518092K  57752K  bg com.android.calendar
>>  1811  1816 u0_a24   29   9   0% S 1518092K  57752K  bg [Jit thread pool]
>>
>> so the []s are helpful in making the threads stand out, but unlike ps
>> it's a lot less obvious with top *whose* jit thread pool and *whose*
>> binder threads we're looking at. afaict this would require either
>> adding yet another slightly different "name" field or changing the
>> interpretation of one of the existing ones. thoughts?
>
> The half-dozen different name fields are enough of a nightmare I've been
> pondering pulling them out of the alphabetical list and grouping them in
> the help output, because I can never remember which one does what and
> they're currently kinda hard to look up.

yeah, i've thought the same too. but you can't really win. sometimes
folks will want alphabetical ("what does X mean?") and other times
logical ("what are my choices for the 'name' concept?").

> (Of course when I sat down to clean up the ps help text, the first issue
> is that I implemented a lot more fields for top and pgrep and such than
> ps --help currently lists, and when trying to document them all I went
> down the rathole of trying to figure out what the difference between -o
> PR and -o PRI actually is, which involved reading kernel source for an
> hour (the comment on task_prio() in kernel/sched/core.c does not seem to
> match the MAX_RT_PRIO value from include/linux/sched/prio.h), and then I
> got interrupted, and I have a half-finished blog entry about it and it's
> on the todo list. The REALLY sad part is I worked through this and
> understood it when I implemented it, but didn't write it _down_. You'd
> think I'd know better by now...)

these kinds of things are, i think, the best argument for a logical
grouping. makes it easier to contrast them with one another. but the
ps help is already pretty long.

> That said, if we did break out the name list I could add -o tname or -o
> alias or -o nomdeplume or whatever strange behavior you need without
> feeling too bad about it. (Or we could work out what the components are
> and try to simplify it so this is "-o RAWNAME,ARG0". I think I'd have to
> break out the current name list and stare at them as a group to figure
> out which approach is better.)
>
>> (if you want a stand-alone C pthread test .c file let me know, but if
>> you're running chrome, you can see this even with toybox ps -A -T ---
>> chrome has plenty of threads.)
>
> chromium-browser has 46 threads (and that's with most tabs killed: the
> trick is to set /etc/resolv.conf to 127.0.0.1 after a crash forces you
> to reopen all your tabs). But thunderbird has 45, apache2 has 27,
> something called osspd has 12... I think I'm good. :) ("ps -ATfk tcnt"
> works great by the way. Possibly I should try to rephrase the
> documentation so "ps -ATfk -tcnt" reversing that is more obvious. Terse
> vs thorough, the endless struggle...)
>
> I'm still in Tokyo for most of this coming week keeping
> http://j-core.org/news.html updating (a _different_ todo list is
> flushing madly, always does when I come here), and I'm likely to be
> quiet on toybox until I get back to Austin (might not even get the
> necessary top polishing in this week), but after this trip I seriously
> want to make a big push to get as much into Android-next as I can while
> the merge window equivalent is open.

yeah, it's finally starting to look like the end is in sight for
toolbox. i'll start another thread with a question about
getevent/sendevent...

> (I've more or less told my boss I'm
> likely to disappear for a few weeks after this trip. Fix the help text
> collator, restart mk/genext2, do mk/genvfatfs with some mtools-alikes,
> implement vi and less, get toysh to at _least_ the level of msh from
> uclinux (which is only 53 lines long), the cleanup/promote lsof, dd,
> expr, more, tar, tr, figure out how to deal with stuff like rev.c that
> does fdopen() on loopfiles and thus seems to WANT a FILE * version...)
>
> Hmmm, I _could_ have the argument be a long and then have a flag that
> makes it give you a FILE * instead of an fd. Or I could switch
> everything to FILE * by default and then you can fileno() if you want to
> go the other way, which is slightly less efficient (unnecessary malloc
> and struct initialization) but avoids most of the horrible resource
> tracking issues... Yeah, that's probably simpler from an implementation
> standpoint, and simple beats efficient on a first pass.
>
> But that's ANOTHER can of worms to open. I should _probably_ cut a
> synchronization release with just what I've got done already on the
> flight back, just to clear the decks for the next round.

as a friend of mine always says, "version numbers are free" :-)

> But first, more jcore stuff...
>
> Rob
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.