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?
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")
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 ([email protected])
"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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |