Jeff,
From looking at the straces, I think it is breaking because in default_idle(), when we call disable_timer(), it always returns 0 which means that idle_sleep() and hence nanosleep() are being called with "0 nsecs". This naturally causes the almost busy-loop. I can't quite put my finger on where it is happening, but when CONFIG_NO_HZ is not enabled, the timer_one_shot() is not being called at all. This means that the timer is never set and hence returns 0 as old value whenever setitimer is called later.
Hope that helps,
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