On 12/06/12 11:27, Arjan van de Ven wrote: > ... >> The exposed configuration interface might be as simple as choosing one of several discrete settings: >> - max single-threaded performance >> - max multi-threaded performance > > > these are identical on todays silicon btw; or rather, this is not a P state choice item, but a task scheduler policy item. Here's where there is a difference in power management: if you want to maximize single-thread performance, you're willing to enable power-expensive boost modes on behalf of a thread. You don't want to do that for multithreaded performance because your thermal envelope may not let you boost them all at once. Or at least that is what I was thinking. Also some people will be all about I/O throughput, and others will care more about latency than anything else, and percentages for those people may be wildly different than for general computation. So we can't guarantee any particular percentage outside some well-defined benchmarks. But we could try to lump them all together as best we can and have a couple of knobs on the side like the current "io_is_busy", perhaps. >> - "server" setting -- save power but only in ways that do not affect performance > > this is a fiction btw... if there was a way to reduce power and not affect performance, that's your "max performance" setting. > anything else will sacrifice SOME performance from max... I know people who don't pay for electricity or cooling and think max performance == run every thread at maximum possible speed all the time, even if it is idle. But boost modes mean "maximum possible speed" is a fluid concept. ... > > and defining a common policy interface I'm quite fine with (not quite in the way you defined it, but ok...) > But that's not going to lead to a common implementation as a "governor" ;-( > > My idea for a policy "dial" is mostly > > * Uncompromised performance > * Balanced - biased towards performance (say, defined to be lowest power at most a 2 1/2% perf hit) > * Balanced (say, at most a 5% perf hit) > * Balanced - biased towards lower power (sat, at most a 10% perf hit) > * Uncompromised lowest power > > we can argue about the exact %ages, but the idea is to give at least some reasonably definition that people can understand, > but that also can be measured I am quite happy with your definitions above. It is the same in spirit as what I was trying for, just better stated. I expect the performance degradation percentages are going to vary a lot depending on what techniques are available in the hardware. If we want to generalize this to encompass older hardware too (which I think is a good idea), I could see percentages being, say, <3% <10% <20% to give more room to work with, and nicer newer hardware being able to do better as your percentages indicate. On reporting frequency: would it be practical to report some sort of medium-term average frequency, or if that is not available, to just report the max freq that the hardware thread is currently eligible to use? DCN -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
