Messages in this thread | | | Date | Mon, 03 Feb 2014 08:17:47 -0800 | From | Arjan van de Ven <> | Subject | Re: [RFC PATCH 3/3] idle: store the idle state index in the struct rq |
| |
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
>> 1) A latency driven one >> 2) 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
| |