[Toybox] ps down, top to go

[Rob Landley]

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?

Binder_1 is stat[2] and com.android.fruitbasket is argv[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.

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

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

But first, more jcore stuff...

Rob