Re: [RFC PATCH 0/2] cpufreq: Introduce LAB cpufreq governor.

From: Viresh Kumar
Date: Tue Apr 09 2013 - 08:02:19 EST


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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/