So right now we have the pmqos framework (and before that we had a simpler version of this);
so if your realtime (or realtime-like) system cannot deal with latency longer then X usec,
you can just tell the kernel,, and the deeper power states that have this latency, just won't get used.
What you're mentioning is sort-of-kinda different. It's the "most of the time go as deep as you can,
but when I do IO, it hurts throughput".
There's two approaches to that in principle
1) Work based on historic behavior, and go less deep when there's lots of activity in the (recent) past
A few folks at Intel are working on something like this
2) You have the IO layer tell the kernel "heads up, something coming down soon"
This is more involved, especially since it's harder to predict when the disk will be done.
(it could be a 10msec seek, but it could also be in the disks cache memory, or it could be an SSD or,
the disk may have to read the sector 5 times because of weak magnetics... it's all over the map)
Another complication is that we need to only do this for "synchronous" IO's.. which is known at higher layers
in the block stack, but I think gets lost towards the bottom.
There's another problem with 2); in a multicore world; all packages EXACPT for the one which will get the irq can go to a deeper state anyway....
but it might be hard to predict which CPU will get the completion irq.
--
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
