Hey Jeff,
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 10/18/07, Jeff Dike <jdike@addtoit.com> wrote:
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