[procps] Re: C-States handling - new switch?
- From: Jaromir Capik <jcapik@xxxxxxxxxx>
- To: procps@xxxxxxxxxxxxx
- Date: Tue, 31 Jan 2012 10:41:22 -0500 (EST)
I just reproduced the issue with 'mount -o bind'
and some scripting. I increased the user counter
by 10 each second and the other counters weren't
incremented.
The result was really 100% for user and 0% for others.
Does anybody know if there's any way how to reliably
detect the maximum possible increment? This could be used
for scaling the results to more useful values.
Thanks,
Jaromir.
----- Original Message -----
From: "Jaromir Capik" <jcapik@xxxxxxxxxx>
To: procps@xxxxxxxxxxxxx
Sent: Tuesday, January 31, 2012 3:21:21 PM
Subject: [procps] Re: C-States handling - new switch?
Hello Jim.
Is this the mentioned patch?
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=60_top_nohz.dpatch;att=1;bug=495882
Because if it is, then it solves only the issue mentioned by me,
but doesn't solve the following issue:
-----------------------------------
Hi,
The root issue is not just that sometimes we have 0% used + 0% idle = 0% total
(?), I believe that's only a corner case of the more general issue that on a
tickless kernel you're more likley to have fewer updates or ticks under
/proc/stat per time interval used by top...
For instance, I've also seen some cases where the numbers look "too round" to
be true. Examples:
Cpu1 : 25.0%us, 50.0%sy, 0.0%ni, 25.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Or:
Cpu1 : 33.3%us, 33.3%sy, 0.0%ni, 33.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Or:
Cpu1 : 14.3%us, 14.3%sy, 0.0%ni, 71.4%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Or:
Cpu1 : 0.0%us, 50.0%sy, 0.0%ni, 50.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Or:
Cpu8 : 33.3%us, 66.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Take the last one of those... I believe what happened was that the "cpu8" row
of /proc/stat in the interval used by top only had 3 ticks, in other words, an
increase of 1 for the user counter and an increase of 2 for the system counter
(I didn't verify that but that's what it looks to me). Similar for the others
above. It seems that the CPU did very little job and spent most of the rest of
the time stopped on C-states.
As the kernel is now tickless it won't be woken up about 1,000 times per second
which would ensure the numbers would get updated more often and the numbers
wouldn't look this wrong even when the CPU is stopped on C-states...
The numbers look very wrong because we cannot use them to estimate how much
more we can do with this CPU, for instance, it seems that it's in full capacity
at that moment when in fact it's almost completely idle.
I was thinking that at least the "cpu" row totaling the numbers of all CPUs
would be correct, but I think it will not... Consider the case of a machine
with 4 CPUs where the only thing running is a single-threaded CPU-bound
process. This process will take up 100% user of a single CPU. Let's say the
other 3 CPUs have absolutely nothing to do and the kernel will stop them on
some deeper C-states (C3 or C6). As the kernel is tickless, they will probably
not get any interrupts either (assume irqbalance is off). In that case, CPU0
will be 100% user, 0% sys, 0% idle, the other three CPUs will be 0% user, 0%
sys, 0% idle (no counters increasing) and the "cpu" row which sums the others
up will be 100% user, 0% sys, 0% idle as the counters of the other 3 won't make
any difference! It will look like this system is 100% loaded when in fact it's
only 25% loaded...
I think there needs to be some compensation in the /proc/stat counters for time
spent on C-states or an extra row that would measure the percentage of the time
they spent there...
Thanks,
Fil
-----------------------------------
Any thoughts?
Thanks,
Jaromir.
----- Original Message -----
From: "Jim Warner" <james.warner@xxxxxxxxxxx>
To: procps@xxxxxxxxxxxxx
Sent: Thursday, January 26, 2012 12:38:19 PM
Subject: [procps] Re: C-States handling - new switch?
On Jan 25, 2012, at 12:06 PM, Jim Warner wrote:
> On Jan 25, 2012, at 7:12 AM, Jaromir Capik wrote:
>> Do You consider it a good idea to introduce a new
>> switch for considering the off state as idle state?
>
> ...
> Comments would be welcomed.
Well here's some comments...
As it turns out, newtop incorporated a debian patch circa 2009 dealing with SMP
kernels built with CONFIG_NO_HZ/Dynamic Ticks. That patch also has the effect
of forcing Nahalem type cpus which are off to display as idle.
The current logic could be made slightly more efficient and perhaps tied to a
conditional if one wished to see all-zero cpu states. But as things now stand,
any on-line cpu should reflect 100.0% idle as a minimum.
Regards,
Jim
Other related posts:
