On Tue, Mar 11, 2008 at 04:29:47PM -0400, Joey Hess wrote: > Here's a good explanation about what procps is doing: > http://lkml.org/lkml/2002/2/18/187 It's not quite how it does it. procps uses a delta or change in the values.
> If I sum all the cpu values and divide by uptime, I get 100, every time. But is that the correct value? I'm worried that this masks the actual problem. > Meanwhile, procps warns about unknown hz values that are trending toward 100 > as the uptime increases. After enough uptime, the problem disappears. That's the strangest part of it, as it is using a delta it shouldn't matter when you do it. Unless there is some strange underflow going on. > Why are only 4 of the numbers extracted? All of them seem to be needed. > Especially on slow and disk-bound systems, the current code only > succeeds in getting a number between 95 and 105 some time after boot, > when the time the system has spent in sys+user+idle mode swamps the > iowait+irq+softirq+steal numbers. I'm not sure, for example it could be that the iowait time is a duplicate of user or system time. > Based on this, it seems right to add up all of the values if all are > available. (For values of "right" that assume this gross approach is the > right way to get the Hz value in the first place..) The right way is to have an elf note. I'll try to work out why all numbers are not added. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 http://www.enc.com.au/ csmall at : enc.com.au http://www.debian.org/ Debian GNU/Linux, software should be Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
