On 2/3/2014 6:56 AM, Peter Zijlstra wrote:
Arjan, could you have a look at teaching your Thunderpants to wrap lines at ~80 chars please?
I'll try but it suffers from Apple-disease
- 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
* if you don't care about llc vs core local caches then that parameter can go away
* I assume this is also called for the local cpu... if not then we need to add a cpu number argument
* we can also call this from architecture code when wbinvd or the arm equivalent is called etc