Yes, that double negative was a slipup. I did get some numbers out and they look pretty good. I ran upto 5 instances of UML simultaneously and in the tickful case, each instance adds roughly about 100 wakeups per second. So after 5 instances, C3 residency comes down to about 95% when all the instances are simply idling. With NO_HZ applied, the change is minimal with C3 residency still approximately 98%. UML is not even among the top three of the bad-list of wakers-up :-)
On Wed, Oct 17, 2007 at 07:29:47PM -0400, Hrishikesh wrote:
> No, I think I haven't been clear enough. The story is right :-) When it is
> "busy-looping" like in the second case is when the C3 residency comes down,
> as expected. Like you said, it looks broken, and has to be fixed.
Yes, your original post was a bit confusing:
> This happens when you run a
> patched kernel but without the NO_HZ and HR timers options disabled.
To my highly logical mind, that double-negative says that you saw the
C3 drop with NO_HZ and hrtimers enabled.
There was also this, which I paid insufficient attention to:
> This does not happen when the tickless option _is_ enabled.
However, it does look like the tickless support induces UML into a
busy loop when NO_HZ is disabled.
BTW, can you measure C3 time with a before-NO_HZ UML, so we can see
that NO_HZ has some sort of benefit on power consumption?
Work email - jdike at linux dot intel dot com