On 9 April 2013 16:07, Lukasz Majewski <l.majewski@xxxxxxxxxxx> wrote: >> On Mon, Apr 1, 2013 at 1:54 PM, Jonghwa Lee > Our approach is a bit different than cpufreq_ondemand one. Ondemand > takes the per CPU idle time, then on that basis calculates per cpu load. > The next step is to choose the highest load and then use this value to > properly scale frequency. > > On the other hand LAB tries to model different behavior: > > As a first step we applied Vincent Guittot's "pack small tasks" [*] > patch to improve "race to idle" behavior: > http://article.gmane.org/gmane.linux.kernel/1371435/match=sched+pack+small+tasks Luckily he is part of my team :) http://www.linaro.org/linux-on-arm/meet-the-team/power-management BTW, he is using ondemand governor for all his work. > Afterwards, we decided to investigate different approach for power > governing: > > Use the number of sleeping CPUs (not the maximal per-CPU load) to > change frequency. We thereof depend on [*] to "pack" as many tasks to > CPU as possible and allow other to sleep. He packs only small tasks. And if there are many small tasks we are packing, then load must be high and so ondemand gov will increase freq. > Contrary, when all cores are heavily loaded, we decided to reduce > frequency by around 30%. With this approach user experience recution is > still acceptable (with much less power consumption). Don't know.. running many cpus at lower freq for long duration will probably take more power than running them at high freq for short duration and making system idle again. > We have posted this "RFC" patch mainly for discussion, and I think it > fits its purpose :-). Yes, no issues with your RFC idea.. its perfect.. @Vincent: Can you please follow this thread a bit and tell us what your views are? -- viresh -- 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
