RE: Variable ticks

[Brown, Len]

>I was thinking about variable tick times, and I can think of three 
>classes of action needing CPU attention.
>- device interrupts, which occur at no predictable time but would pull 
>the CPU out of a HLT or low power state.
>- process sleeps of various kinds, which have a known time of 
>occurence.
>- polled devices...
>
>Question one, are there other actions to consider?

Yes.
Speaking for ACPI C3 state, note that DMA also
wakes up the CPU -- even if there was no device interrupt.
(aka, "the trouble with USB")

>Question two, what about those polled devices?

it is a real challenge to save power under such conditions,
unless you can throttle the polling rate such that
the processor can actually enters idle while polling
is underway.

>I've been asked to give a high level overview of the recent discussion 
>for a meeting, and while I want to keep it at the level of "slower 
>clock, fewer interrupts" and "faster clock, better sleep 
>resolution," I 
>don't want to leave out any important issues, or be asked a question 
>(like how to handle polling devices) when I have no idea what 
>people are thinking in an area.

>From a power management point of view, what is important
is what we do when idle.  ie. on my laptop, from a power
savings point of view, I wouldn't care
much if HZ=1000 all the time if HZ=0 when in idle.

Outside of idle, the tick rate is much less important to
power savings, unless the change in tick rate was significant
enough to change the load enough that we'd want to change the
target non-idle MHz of the processor.

cheers,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/