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.
Regards,
Hrishikesh

On 10/17/07, Jeff Dike <jdike@addtoit.com> wrote:
On Wed, Oct 17, 2007 at 03:43:01PM -0400, Hrishikesh wrote:
> Ok the straces do seem to tell the story; they follow below:

Except they're telling the wrong story:

> for the case where is the kernel is patched and NO_HZ enabled,

> {it_interval={0, 0}, it_value={0, 91986}}) = 0
> nanosleep({0, 91986000}, {0, 91986000}) = 0

.1 sec

> {it_interval={0, 0}, it_value={0, 291955}}) = 0
> nanosleep({0, 291955000}, {0, 291955000}) = 0

.3 sec

> {it_interval={0, 0}, it_value={1, 701741}}) = 0
> nanosleep({1, 701741000}, {1, 701741000}) = 0

1.7 sec

> for the case where the kernel is patched, but NO_HZ is __not__ enabled,
> there is a do_nanosleep() every 100 or so us.
>
> setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}},
> {it_interval={0, 0}, it_value={0, 0}}) = 0
> nanosleep({0, 0}, {0, 0})               = 0

This actually looks very broken - it's sleeping for no time,
practically a busy-loop.  And this case is keeping the host in C3
longer than the second-long sleeps in the first case?

                                Jeff

--
Work email - jdike at linux dot intel dot com