On Mon, Feb 03, 2014 at 04:17:47PM +0000, Arjan van de Ven wrote:
[...]
- A latency driven one
- A performance impact on
first one is pretty much the exit latency related time, sort of a "expected time to first instruction" (currently menuidle has the 99.999% worst case number, which is not useful for this, but is a first approximation). This is obviously the dominating number for expected-short running tasks
second on is more of a "is there any cache/TLB left or is it flushed" kind of metric. It's more tricky to compute, since what is the cost of an empty cache (or even a cache migration) after all.... .... but I suspect it's in part what the scheduler will care about more for expected-long running tasks.
Yeah, so currently we 'assume' cache hotness based on runtime; see task_hot(). A hint that the CPU wiped its caches might help there.
if there's a simple api like
sched_cpu_cache_wiped(int llc)
that would be very nice for this; the menuidle side knows this for some cases and thus can just call it. This would be a very small and minimal change
What do you mean by "menuidle side knows this for some cases" ? You mean you know that some C-state entries imply llc clean/invalidate ?
Thanks, Lorenzo