[Toybox] Still with the ps.

[Rob Landley]

So ps -o pcpu (I.E. the %CPU field) is another one busybox doesn't
implement but posix requires. To do it right, I think you have to
preread all the /proc/$PID/stat entries and add up their kernel and user
ticks, then on the second pass express percentages?

Well, ok, to do it _right_ ala top, you have to read them all, pause for
a known about of time, and then read them again. Because they give you a
historical accumulation of ticks and if you want to know what it's doing
_now_ you have to let time pass between two readings and see how much
it's gone up. But procutils ps for the xserver pid gives a constant
value in several consecutive readings even though it's wandering all
over in top, so the cumulative usage seems to be what ps provides.

So far only %cpu requires this, meaning I can do the less memory
intensive "deal with each one as I read it" and move on thing unless
they -o %cpu in which case I read a list, traverse the list, and then
llist_traverse() feeding it to the function.

(Modulo llist_traverse() operating on  "void func(void *)" and the
dirtree stuff wanting "int func(struct dirtree *)" instead. If I feed a
dirtree function to llist_traverse() the return value should be ignored
and the void * should be read as a struct dirtree * but "of course
that's how C has worked since 1974" and "gcc's optimizer is insane" may
disagree.  Grr. And thus I should probably hand-code the loop for
"portability" despite documenting a reliance on LP64 that says
sizeof(pointer) equals sizeof(long). Eh, wait for it to break for
somebody...)

Hmmm... except when I run "yes" and leave it running for a bit, it goes
up to 50% (one CPU) and then stays there. The percentage of xchat and
thunderbird and such don't go _down_, they stay the same.

Grrr. There's aggregates since boot in /proc/stat but that implies after
I've run a few large compiles nothing in the system's ever going above a
few percent again, which is not the behavior I'm seeing. What are these
programs _doing_? I ran strace and it wasn't travesing the /proc/$PID
directories more than once...

Confused,

Rob

 1445415081.0