Re: [RFC PATCH 3/3] idle: store the idle state index in the structrq

From: Arjan van de Ven
Date: Mon Feb 03 2014 - 11:18:12 EST


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



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/