Messages in this thread | | | Date | Wed, 12 Dec 2012 21:55:52 +0800 | Subject | Re: [PATCH 0/18] sched: simplified fork, enable load average into LB and power awareness scheduling | From | Alex Shi <> |
| |
>>>> >>>> >>>> well... it's not always beneficial to group or to spread out >>>> it depends on cache behavior mostly which is best >>> >>> >>> Let me try to understand what this means: so "performance" above with >>> 8 threads means that those threads are spread out across more than one >>> socket, no? >>> >>> If so, this would mean that you have a smaller amount of tasks on each >>> socket, thus the smaller wattage. >>> >>> The "powersaving" method OTOH fills up the one socket up to the brim, >>> thus the slightly higher consumption due to all threads being occupied. >>> >>> Is that it? >> >> >> not sure. >> >> by and large, power efficiency is the same as performance efficiency, with >> some twists. >> or to reword that to be more clear >> if you waste performance due to something that becomes inefficient, you're >> wasting power as well. >> now, you might have some hardware effects that can then save you power... >> but those effects >> then first need to overcome the waste from the performance inefficiency... >> and that almost never happens. >> >> for example, if you have two workloads that each fit barely inside the last >> level cache... >> it's much more efficient to spread these over two sockets... where each has >> its own full LLC >> to use. >> If you'd group these together, both would thrash the cache all the time and >> run inefficient --> bad for power. >> >> now, on the other hand, if you have two threads of a process that share a >> bunch of data structures, >> and you'd spread these over 2 sockets, you end up bouncing data between the >> two sockets a lot, >> running inefficient --> bad for power. >> > > Agree with all of the above. However.. > >> having said all this, if you have to tasks that don't have such cache >> effects, the most efficient way >> of running things will be on 2 hyperthreading halves... it's very hard to >> beat the power efficiency of that. > > .. there are alternatives to hyperthreading. On ARM's big.LITTLE > architecture you could simply schedule them on the LITTLE cores. The > big cores just can't beat the power efficiency of the LITTLE ones even > with 'race to halt' that you allude to below. And usecases like mp3 > playback simply don't require the kind of performance that the big > cores can offer. > >> But this assumes the tasks don't compete with resources much on the HT >> level, and achieve good scaling. >> and this still has to compete with "race to halt", because if you're done >> quicker, you can put the memory >> in self refresh quicker. >> >> none of this stuff is easy for humans or computer programs to determine >> ahead of time... or sometimes even afterwards. >> heck, even for just performance it's really really hard already, never mind >> adding power. >> >> my personal gut feeling is that we should just optimize this scheduler stuff >> for performance, and that >> we're going to be doing quite well on power already if we achieve that. > > If Linux is to continue to work efficiently on heterogeneous > multi-processing platforms, it needs to provide scheduling mechanisms > that can be exploited as per the demands of the HW architecture.
Linus definitely disagree such ideas. :) So, need to summaries the logical beyond all hardware.
> example is the "small task packing (and spreading)" for which Vincent > Guittot has posted a patchset[1] earlier and so has Alex now.
Sure. I just thought my patchset should handled the 'small task packing' scenario. Could you guy like to have a try? > > [1] http://lwn.net/Articles/518834/
| |