Re: Variable ticks

From: Bill Davidsen
Date: Mon Jul 25 2005 - 16:02:04 EST

Brown, Len wrote:

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?

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")

Trouble? Why would USB do DMA unless there was a device activity?

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.

That could hurt the polling performance, all right. ;-)

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.

Isn't that more or less what on demand does?

Thanks for the feedback, I can probably just say that DMA wakes the CPU from C3 and let it ride, I don't want to skip it, but neither do I need to go into detail.

-bill davidsen (davidsen@xxxxxxx)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at