On Mon, Feb 03, 2014 at 04:17:47PM +0000, Arjan van de Ven wrote: [...]
> >> 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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
