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 12:28:40 +0200 [thread overview]
Message-ID: <519F40D8.7040500@linaro.org> (raw)
In-Reply-To: <CAKohpom+wsGj=1nurNtoiRaZCD7KRbx0BO+tNXpoqO+FmmzehA@mail.gmail.com>
On 05/24/2013 11:13 AM, Viresh Kumar wrote:
> On 24 May 2013 14:36, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>> I agree with Viresh, a new governor is not necessary here for that.
>
> Their patchset had two parts.. One is LAB and other is overclocking.
> We are trying to solve overclocking for which they never wanted a
> new governor. :)
>
>> 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.
>
> The problem is that it was added at the wrong place.. It should have
> been at cpu/cpuX/cpufreq/boost...
Yes, I saw in the commit log (615b7300717b9ad5c23d1f391843484fe30f6c12),
that should be done.
> Consider how will we achieve it for big LITTLE.. We know we can
> go to overdrive only for a single core in big but for two cores in
> LITTLE at the same time.. So, we need that in the location I just
> mentioned...
I thought the constraints should be hardcoded in the driver and only one
option is exposed to the userspace. If the user sets
ondemand|performance + boost, then the exynos's or b.L's drivers know
when they can go to boost (1x core, 1x big core, 2x little core, ...).
> Over that.. I believe it is governor specific too.. It shouldn't be part
> of conservative as it should be conservative rather then aggressive :)
Yes, it is part of the governor policy and maybe that could fall in the
common cpufreq framework.
>> 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 ... :)
>
> I didn't get it completely.. So, with the options I gave user can only
> say.. boost if required and only when few cores are active. User
> can't just set max freq continuously if he wishes..
Ok, may be I misunderstood. You suggested to define 'overdrive_cores'
where the user can setup when to overdrive a core. If the user set an
incorrect value, IIUC, the thermal value can go beyond the thermal limit
and break the board. I am just worried this option is dangerous.
--
<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 12:28:40 +0200 [thread overview]
Message-ID: <519F40D8.7040500@linaro.org> (raw)
In-Reply-To: <CAKohpom+wsGj=1nurNtoiRaZCD7KRbx0BO+tNXpoqO+FmmzehA@mail.gmail.com>
On 05/24/2013 11:13 AM, Viresh Kumar wrote:
> On 24 May 2013 14:36, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>> I agree with Viresh, a new governor is not necessary here for that.
>
> Their patchset had two parts.. One is LAB and other is overclocking.
> We are trying to solve overclocking for which they never wanted a
> new governor. :)
>
>> 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.
>
> The problem is that it was added at the wrong place.. It should have
> been at cpu/cpuX/cpufreq/boost...
Yes, I saw in the commit log (615b7300717b9ad5c23d1f391843484fe30f6c12),
that should be done.
> Consider how will we achieve it for big LITTLE.. We know we can
> go to overdrive only for a single core in big but for two cores in
> LITTLE at the same time.. So, we need that in the location I just
> mentioned...
I thought the constraints should be hardcoded in the driver and only one
option is exposed to the userspace. If the user sets
ondemand|performance + boost, then the exynos's or b.L's drivers know
when they can go to boost (1x core, 1x big core, 2x little core, ...).
> Over that.. I believe it is governor specific too.. It shouldn't be part
> of conservative as it should be conservative rather then aggressive :)
Yes, it is part of the governor policy and maybe that could fall in the
common cpufreq framework.
>> 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 ... :)
>
> I didn't get it completely.. So, with the options I gave user can only
> say.. boost if required and only when few cores are active. User
> can't just set max freq continuously if he wishes..
Ok, may be I misunderstood. You suggested to define 'overdrive_cores'
where the user can setup when to overdrive a core. If the user set an
incorrect value, IIUC, the thermal value can go beyond the thermal limit
and break the board. I am just worried this option is dangerous.
--
<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 10:28 UTC|newest]
Thread overview: 58+ 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
2013-05-24 9:06 ` Daniel Lezcano
2013-05-24 9:13 ` Viresh Kumar
2013-05-24 10:28 ` Daniel Lezcano [this message]
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 ` [RFC v3 1/5] cpufreq:LAB:ondemand Adjust ondemand to be able to reuse its methods 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 ` [RFC v3 3/5] cpufreq:LAB:lab Add LAB governor code 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 ` [RFC v3 5/5] cpufreq:LAB:dts:trats2: Add DTS nodes for LAB governor 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-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-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 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: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=519F40D8.7040500@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.