From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Lukasz Majewski <l.majewski@samsung.com>,
Jonghwa Lee <jonghwa3.lee@samsung.com>,
"Rafael J. Wysocky" <rjw@sisk.pl>,
linux-kernel@vger.kernel.org, cpufreq@vger.kernel.org,
linux-pm@vger.kernel.org,
Vicent Guittot <vincent.guittot@linaro.org>,
MyungJoo Ham <myungjoo.ham@samsung.com>,
Lukasz Majewski <l.majewski@majess.pl>
Subject: Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results
Date: Fri, 24 May 2013 11:06:17 +0200 [thread overview]
Message-ID: <519F2D89.5030602@linaro.org> (raw)
In-Reply-To: <CAKohponbX7u_k9ZYQ7KyBeyKh93Qu+niGZj60t9c1n+AmaA6pg@mail.gmail.com>
On 05/24/2013 10:51 AM, Viresh Kumar wrote:
> On 24 May 2013 14:00, Lukasz Majewski <l.majewski@samsung.com> wrote:
>> The overclock frequency (1.5 GHz) is possible to set as an ordinary,
>> available frequency (policy->max) for ondemand.
>>
>> Unfortunately with our load patterns, this frequency rapidly increases
>> internal chip temperature (chip goes out of available power/thermal
>> dissipation range), and consumes extra power when not needed.
>>
>> The core idea with overclock is to increase ("boost") the frequency
>> when conditions allow to do it (for example load is affined to a single
>> core, other are idle). Then we will not exceed power/thermal budget, but
>> increase performance (and even save power).
>>
>>
>> Overclocking is efficiently utilized by LAB, which relies on a number of
>> idle cpus. Thus, we can easily asses if we can enable it.
>>
>> I also foresee potential use of overclocking, when scheduler will take a
>> major role of power saver for mobile (ARM) linux. Since it will try to
>> pack as much tasks as possible to a single core - it will need a
>> framework/API to "boost" their execution.
>
> Okay.. so its exactly what I thought the reason would be.
>
> What I would have done if I was in your place is:
>
> Add following sysfs tunables to ondemand governor:
>
> - overdrive_freq: We will go over this frequency only when
> number of busy cores is <= overdrive_cores..
> For your case it will be 1.4 GHz
>
> - overdrive_cores: We will enable overdrive frequencies only if no. of
> busy cores is <= overdrive_cores. Zero by default (So, that this feature
> is disabled by default) and 1 for your case.
>
> And your driver will include all the available frequencies in the freq
> table.
>
> I hope this will be the most generic solution to your problem..
I agree with Viresh, a new governor is not necessary here for that.
There is the /sys/devices/system/cpufreq/boost option existing for x86
platform, why do not reuse it ? It is supposed to do exactly what you
want to achieve.
IMO, the logic of boosting one core when the other are idle should be in
the driver itself and certainly not setup by the user, except if we
consider acceptable the user can burn its board ... :)
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Lukasz Majewski <l.majewski@samsung.com>,
Jonghwa Lee <jonghwa3.lee@samsung.com>,
"Rafael J. Wysocky" <rjw@sisk.pl>,
linux-kernel@vger.kernel.org, cpufreq@vger.kernel.org,
linux-pm@vger.kernel.org,
Vicent Guittot <vincent.guittot@linaro.org>,
MyungJoo Ham <myungjoo.ham@samsung.com>,
Lukasz Majewski <l.majewski@majess.pl>
Subject: Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results
Date: Fri, 24 May 2013 11:06:17 +0200 [thread overview]
Message-ID: <519F2D89.5030602@linaro.org> (raw)
In-Reply-To: <CAKohponbX7u_k9ZYQ7KyBeyKh93Qu+niGZj60t9c1n+AmaA6pg@mail.gmail.com>
On 05/24/2013 10:51 AM, Viresh Kumar wrote:
> On 24 May 2013 14:00, Lukasz Majewski <l.majewski@samsung.com> wrote:
>> The overclock frequency (1.5 GHz) is possible to set as an ordinary,
>> available frequency (policy->max) for ondemand.
>>
>> Unfortunately with our load patterns, this frequency rapidly increases
>> internal chip temperature (chip goes out of available power/thermal
>> dissipation range), and consumes extra power when not needed.
>>
>> The core idea with overclock is to increase ("boost") the frequency
>> when conditions allow to do it (for example load is affined to a single
>> core, other are idle). Then we will not exceed power/thermal budget, but
>> increase performance (and even save power).
>>
>>
>> Overclocking is efficiently utilized by LAB, which relies on a number of
>> idle cpus. Thus, we can easily asses if we can enable it.
>>
>> I also foresee potential use of overclocking, when scheduler will take a
>> major role of power saver for mobile (ARM) linux. Since it will try to
>> pack as much tasks as possible to a single core - it will need a
>> framework/API to "boost" their execution.
>
> Okay.. so its exactly what I thought the reason would be.
>
> What I would have done if I was in your place is:
>
> Add following sysfs tunables to ondemand governor:
>
> - overdrive_freq: We will go over this frequency only when
> number of busy cores is <= overdrive_cores..
> For your case it will be 1.4 GHz
>
> - overdrive_cores: We will enable overdrive frequencies only if no. of
> busy cores is <= overdrive_cores. Zero by default (So, that this feature
> is disabled by default) and 1 for your case.
>
> And your driver will include all the available frequencies in the freq
> table.
>
> I hope this will be the most generic solution to your problem..
I agree with Viresh, a new governor is not necessary here for that.
There is the /sys/devices/system/cpufreq/boost option existing for x86
platform, why do not reuse it ? It is supposed to do exactly what you
want to achieve.
IMO, the logic of boosting one core when the other are idle should be in
the driver itself and certainly not setup by the user, except if we
consider acceptable the user can burn its board ... :)
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
next prev parent reply other threads:[~2013-05-24 9:06 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-03 14:07 [RFC v2 0/3] LAB: Support for Legacy Application Booster governor Jonghwa Lee
2013-05-03 14:07 ` [RFC v2 1/3] cpufreq:overclocking: Overclocking support at Exynos4 SoC Jonghwa Lee
2013-05-03 14:07 ` [RFC v2 2/3] cpufreq:LAB: Introduce new cpufreq LAB(Legacy Application Boost) governor Jonghwa Lee
2013-05-03 14:07 ` [RFC v2 3/3] cpufreq:LAB: Modify cpufreq_governor to support LAB Governor Jonghwa Lee
2013-05-22 9:07 ` [RFC v2 0/3] LAB: Support for Legacy Application Booster governor Viresh Kumar
2013-05-22 10:27 ` Lukasz Majewski
2013-05-22 11:16 ` Viresh Kumar
2013-05-22 12:05 ` Lukasz Majewski
2013-05-22 14:44 ` [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results Lukasz Majewski
2013-05-24 5:56 ` Lukasz Majewski
2013-05-24 7:52 ` Viresh Kumar
2013-05-24 8:30 ` Lukasz Majewski
2013-05-24 8:51 ` Viresh Kumar
2013-05-24 9:06 ` Daniel Lezcano [this message]
2013-05-24 9:06 ` Daniel Lezcano
2013-05-24 9:13 ` Viresh Kumar
2013-05-24 10:28 ` Daniel Lezcano
2013-05-24 10:28 ` Daniel Lezcano
2013-05-24 10:32 ` Viresh Kumar
2013-05-24 11:34 ` Lukasz Majewski
2013-05-24 11:20 ` Lukasz Majewski
2013-05-27 5:33 ` Viresh Kumar
2013-05-27 7:34 ` Lukasz Majewski
2013-05-27 12:00 ` Rafael J. Wysocki
2013-05-27 12:16 ` Lukasz Majewski
2013-05-27 13:24 ` Viresh Kumar
2013-05-27 19:48 ` Rafael J. Wysocki
2013-05-28 6:40 ` Lukasz Majewski
2013-05-28 9:44 ` Viresh Kumar
2013-05-28 12:30 ` Rafael J. Wysocki
2013-05-28 13:26 ` Lukasz Majewski
2013-05-28 21:48 ` Rafael J. Wysocki
2013-05-29 5:23 ` Viresh Kumar
2013-05-29 7:09 ` Lukasz Majewski
2013-05-29 7:39 ` Viresh Kumar
2013-05-29 13:45 ` Lukasz Majewski
2014-03-04 10:27 ` [RFC v3 0/5] cpufreq:LAB: Support for LAB governor Lukasz Majewski
2014-03-04 10:27 ` Lukasz Majewski
2014-03-04 10:27 ` [RFC v3 1/5] cpufreq:LAB:ondemand Adjust ondemand to be able to reuse its methods Lukasz Majewski
2014-03-04 10:27 ` Lukasz Majewski
2014-03-04 10:27 ` [RFC v3 2/5] cpufreq:LAB:cpufreq_governor Adjust cpufreq_governor.[h|c] to support LAB Lukasz Majewski
2014-03-04 10:27 ` Lukasz Majewski
2014-03-04 10:27 ` [RFC v3 3/5] cpufreq:LAB:lab Add LAB governor code Lukasz Majewski
2014-03-04 10:27 ` Lukasz Majewski
2014-03-04 10:27 ` [RFC v3 4/5] cpufreq:LAB:Kconfig Add LAB definitions to Kconfig Lukasz Majewski
2014-03-04 10:27 ` Lukasz Majewski
2014-03-04 10:27 ` [RFC v3 5/5] cpufreq:LAB:dts:trats2: Add DTS nodes for LAB governor Lukasz Majewski
2014-03-04 10:27 ` Lukasz Majewski
2014-03-17 15:38 ` [RFC v3 0/5] cpufreq:LAB: Support " Lukasz Majewski
2014-03-17 15:38 ` Lukasz Majewski
2014-03-17 15:38 ` Lukasz Majewski
2014-03-18 6:55 ` Viresh Kumar
2014-03-18 6:55 ` Viresh Kumar
2014-03-18 6:55 ` Viresh Kumar
2014-03-18 9:17 ` Lukasz Majewski
2014-03-18 9:17 ` Lukasz Majewski
2014-03-18 9:17 ` Lukasz Majewski
2014-03-24 6:47 ` Lukasz Majewski
2014-03-24 6:47 ` Lukasz Majewski
2014-03-24 6:47 ` Lukasz Majewski
2014-03-24 6:51 ` Viresh Kumar
2014-03-24 6:51 ` Viresh Kumar
2014-03-24 6:51 ` Viresh Kumar
2014-03-24 8:48 ` Viresh Kumar
2014-03-24 8:48 ` Viresh Kumar
2014-03-24 8:48 ` Viresh Kumar
2014-03-24 10:00 ` Lukasz Majewski
2014-03-24 10:00 ` Lukasz Majewski
2014-03-24 10:00 ` Lukasz Majewski
2014-03-24 10:15 ` Viresh Kumar
2014-03-24 10:15 ` Viresh Kumar
2014-03-24 10:15 ` Viresh Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=519F2D89.5030602@linaro.org \
--to=daniel.lezcano@linaro.org \
--cc=cpufreq@vger.kernel.org \
--cc=jonghwa3.lee@samsung.com \
--cc=l.majewski@majess.pl \
--cc=l.majewski@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=myungjoo.ham@samsung.com \
--cc=rjw@sisk.pl \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.