Message-id: <516408CA.5030009@samsung.com>
Date:	Tue, 09 Apr 2013 21:25:46 +0900
From:	jonghwa3.lee@...sung.com
To:	Lukasz Majewski <l.majewski@...sung.com>
Cc:	Viresh Kumar <viresh.kumar@...aro.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux PM list <linux-pm@...r.kernel.org>,
	"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
	MyungJoo Ham <myungjoo.ham@...sung.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Chanwoo Choi <cw00.choi@...sung.com>, sw0312.kim@...sung.com,
	Marek Szyprowski <m.szyprowski@...sung.com>
Subject: Re: [RFC PATCH 0/2] cpufreq: Introduce LAB cpufreq governor.

Hi, sorry for my late reply.
I just want to add comment to assist Lukasz's.
I put my comments below of Lukasz's.

On 2013년 04월 09일 19:37, Lukasz Majewski wrote:

> Hi Viresh,
> 
> First of all I'd like to apologize for a late response.
> Please find my comments below. 
> 
>> On Mon, Apr 1, 2013 at 1:54 PM, Jonghwa Lee
>> <jonghwa3.lee@...sung.com> wrote:
>>> <<Purpose>>
>>>  One of the problem of ondemand is that it considers the most busy
>>> cpu only while doesn't care how many cpu is in busy state at the
>>> moment. This may results in unnecessary power consumption, and it'll
>>> be critical for the system having limited power source.
>>>
>>>  To get the best energy efficiency, LAB governor considers not only
>>> idle time but also the number of idle cpus. It primarily focuses on
>>> supplying adequate performance to users within the limited resource.
>>> It checks the number of idle cpus then controls the maximum
>>> frequency dynamically. And it also applies different frequency
>>> increasing level depends on that information. In simple terms the
>>> less the number of busy cpus, the better performance will be given.
>>>  In addition, stable system's power consumption in the busy state
>>> can be achieved also with using LAB governor. This will help to
>>> manage and estimate power consumption in certain system.
>>
>> Hi Jonghwa,
>>
>> First of all, i should accept that i haven't got to the minute details
>> about your
>> patch until now but have done a broad review of it.
>>
>> There are many things that i am concerned about:
>> - I don't want an additional governor to be added to cpufreq unless
>> there is a very very strong reason for it. See what happened to
>> earlier attempts:
>>
>> https://lkml.org/lkml/2012/2/7/504
>>
>> But it doesn't mean you can't get it in. :)
>>
>> - What the real logic behind your patchset: I haven't got it
>> completely with your
>> mails. So what you said is:
>>
>>   - The lesser the number of busy cpus: you want to run at higher
>> freqs
>>   - The more the number of busy cpus: you want to run at lower freqs
>>
>> But the basic idea i had about this stuff was: The more the number of
>> busy cpus, the more loaded the system is, otherwise scheduler wouldn't
>> have used so many cpus and so there is need to run at higher frequency
>> rather than a lower one. Which would save power in a sense.. Finish
>> work early and let most of the cpus enter idle state as early as
>> possible. But with your solution we would run at lower frequencies
>> and so these cpus will take longer to get into idle state again. This
>> will really kill lot of power.
> 
> 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	
> 
> 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. 
> On this basis we can increase (even overclock) frequency (when other
> CPUs sleep) to improve performance of the only running CPU. 
> 
> 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).
> When system is "idle" - only small background tasks are running, the
> frequency is reduced to minimum. 
> 
> To sum up:
> 
> Different approach (number of idle CPUs) is used by us to control
> ondemand governor. We also heavily depend on [*] patch set.
>


In additions, it is hard to say just letting high performance to busy system is
the best way for reducing the power consumption. Yes, as like Viresh said, we
can save the time of busy working, but that is not always perfect
solution. If we push all CPUs to keep high performance as much as they can,
the temperature will increase rapidly. In my test, on-demand governor reached
the thermal limits frequently, while lab governor didn't. And the high
temperature also effects the power consumption increasing. I got a rough result
which has 10% differences in power consumption between 20% temperature differed
conditions.

    <<Consumed power with maximum frequency at different temperature>>

      Temperature     Power consumption(mWh)         Loss(%)
         65'C                  53.89                  Base
         80'C                  59.88                   10

So, to reduce the power consumption, it looks we have to give our cares more to
avoid the situation where system goes to high temperature. It is more meaningful
for the mobile environment. In mobile devices, high temperature will also affect
user's experience badly and can't be decreased easily.

Maybe temperature problem is not the duty of cpufreq governor. However, if we
just take a look at power consumption gain, we can find the right of the this
governor either.

    <<Consumed power during the web browsing with foreground movie play>>

        Governor     Power consumption(mWh)       Percentage(%)
        ondemand            70.28                     100
          lab               55.14                      78

    ===> There is almost 22% gain for power consumption.


              <<Results of various performance test>>

    ## v8 benchmark test (http://v8.googlecode.com)
        Governor       score          Percentage(%)
        ondemand       1736.75            100
          lab          1576.75             91

    ===> 10% performance loss.

    ## Dhrystone
    	Governor       dhrystone     Percentage(%)
        ondemand        2362204           100
          lab           2197802            93

    ===> 7% performance loss.

    ## Egypt GLbenchmark (http://www.glbenchmark.com)
        Governor       Frames      FPS
        ondemand        5612      49.65
          lab           5559      49.19

    ===> Almost no differences.

(Above whole tests were tested on the EXYNOS4412 SoC based board.)

Thanks,
Jonghwa

>>
>> Think about it.
>>
>> - In case you need some sort of support on this use case, why
>> replicate ondemand governor again by creating another governor. I
>> have had some hard time removing the amount of redundancy inside
>> governors and you are again going towards that direction. Modifying
>> ondemand governor for this response would be a better option.
> 
> We have only posted the "RFC" so, we are open for suggestions. 
> 
> At cpufreq_governor.c file the dbs_check_cpu function is responsible
> for calculating the maximal load (among CPUs). I think that we could
> also count the number of sleeping CPUs (as the average of time
> accumulated data). Then we could pass this data to newly written
> function (e.g. lab_check_cpu) defined at cpufreq_ondemand.c (and
> pointed to by gov_check_cpu).
> 
> This would require change to dbs_check_cpu function and extending
> ONDEMAND governor by lab_check_cpu() function.
> 
>>
>> - You haven't rebased of latest code from linux-next :)
>>
> 
> We have posted this "RFC" patch mainly for discussion, and I think it
> fits its purpose :-).
> 
> 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists