On 04/12/2013 12:48 PM, Mike Galbraith wrote: > On Fri, 2013-04-12 at 18:23 +0200, Borislav Petkov wrote: >> On Fri, Apr 12, 2013 at 04:46:50PM +0800, Alex Shi wrote: >>> Thanks a lot for comments, Len! >> >> AFAICT, you kinda forgot to answer his most important question: >> >>> These numbers suggest that this patch series simultaneously >>> has a negative impact on performance and energy required >>> to retire the workload. Why do it? > > Hm. When I tested AIM7 compute on a NUMA box, there was a marked > throughput increase at the low to moderate load end of the test spectrum > IIRC. Fully repeatable. There were also other benefits unrelated to > power, ie mitigation of the evil face of select_idle_sibling(). I > rather liked what I saw during ~big box test-drive. > > (just saying there are other aspects besides joules in there)
Mike, Can you re-run your AIM7 measurement with turbo-mode and HT-mode disabled, and then independently re-enable them? If you still see the performance benefit, then that proves that the scheduler hacks are not about tricking into turbo mode, but something else. If the performance gains *are* about interactions with turbo-mode, then perhaps what we should really be doing here is making the scheduler explicitly turbo-aware? Of course, that begs the question of how the scheduler should be aware of cpufreq in general... thanks, Len Brown, Intel Open Source Technology Center -- 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/