From: Lukasz Majewski <l.majewski@samsung.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
"cpufreq@vger.kernel.org" <cpufreq@vger.kernel.org>,
Linux PM list <linux-pm@vger.kernel.org>,
Jonghwa Lee <jonghwa3.lee@samsung.com>,
Lukasz Majewski <l.majewski@majess.pl>,
linux-kernel <linux-kernel@vger.kernel.org>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Myungjoo Ham <myungjoo.ham@samsung.com>,
Tomasz Figa <t.figa@samsung.com>,
Thomas Abraham <ta.omasab@gmail.com>,
Thomas Abraham <thomas.ab@samsung.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
linux-samsung-soc <linux-samsung-soc@vger.kernel.org>
Subject: Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.
Date: Mon, 24 Mar 2014 11:00:32 +0100 [thread overview]
Message-ID: <20140324110032.7aeae15e@amdc2363> (raw)
In-Reply-To: <CAKohpok1zBsX7n70r=geCOaP-9ONx2QdaUMK6cJeqhFrO1PkUg@mail.gmail.com>
Hi Viresh,
> On 4 March 2014 15:57, Lukasz Majewski <l.majewski@samsung.com> wrote:
> > Despite this patch set is working and applicable on top of 3.14-rc5,
> > please regard it solely as a pure RFC.
>
> Okay, I am trying to do a review here and because you have mentioned
> how different it is from the earlier versions, I am trying with a
> fresh mind. i.e. with zero memories of earlier discussions :)
>
> LAB was: Legacy Application Boost ??
Yes, correct.
>
> Probably mention that in your new threads as well, so that new readers
> know the details. Also, like other governors, just name it "boost"
> governor.
I think, that "LAB" name is with us for some time, so it would be a
pity to discard it.
>
> > This patch provides support for LAB governor build on top of
> > ondemand. Previous version of LAB can be found here:
> > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> >
> > LAB short reminder:
> >
> > LAB uses information about how many cores are in "idle" state (the
> > core idleness is represented as the value between 0 and 100) and
> > the overall load of the system (from 0 to 100) to decide about
> > frequency to be set. It is extremely useful with SoCs like
> > Exynos4412, which can set only one frequency for all cores.
>
> Probably a description of how exactly these two values come into play
> would have been more interesting here for all. Always think of new
> followers of your patchset and so add all interesting things about it
> when you resend it.
>
> If I remember well the logic was more or less like this:
> - More idle cores means run few running cores at high frequency
> - Less idle cores means don't run them at very high frequencies
>
> Right?
This is correct. Also, the underlying SoC - Exynos4412 has 4 cores with
option to set frequency only on all of them.
>
> What about making it as simple as:
> - changing the ondemand governor only instead of adding a new governor
My goal is to not touch the ondemand code. It has matured, so I would
like to leave it as it is.
> - Keeping the bahavior as is for all platforms not publishing boost
> frequencies
This is also done - you get the LAB configuration specified in the DT
for the particular platform/board.
> - If more cores are idle, enable switching to boost frequencies and
> take them into consideration all the time.
I'm not sure if I have understood you, but something like that is also
performed in the code.
> - If less cores are idle, disable boost frequencies..
As written above.
>
> Lets discuss this first and then I will get into the very details of
> your implementation.
Discussion about above functionalities requires consulting the
implementation to be sure that our opinions are the same.
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
WARNING: multiple messages have this Message-ID (diff)
From: l.majewski@samsung.com (Lukasz Majewski)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.
Date: Mon, 24 Mar 2014 11:00:32 +0100 [thread overview]
Message-ID: <20140324110032.7aeae15e@amdc2363> (raw)
In-Reply-To: <CAKohpok1zBsX7n70r=geCOaP-9ONx2QdaUMK6cJeqhFrO1PkUg@mail.gmail.com>
Hi Viresh,
> On 4 March 2014 15:57, Lukasz Majewski <l.majewski@samsung.com> wrote:
> > Despite this patch set is working and applicable on top of 3.14-rc5,
> > please regard it solely as a pure RFC.
>
> Okay, I am trying to do a review here and because you have mentioned
> how different it is from the earlier versions, I am trying with a
> fresh mind. i.e. with zero memories of earlier discussions :)
>
> LAB was: Legacy Application Boost ??
Yes, correct.
>
> Probably mention that in your new threads as well, so that new readers
> know the details. Also, like other governors, just name it "boost"
> governor.
I think, that "LAB" name is with us for some time, so it would be a
pity to discard it.
>
> > This patch provides support for LAB governor build on top of
> > ondemand. Previous version of LAB can be found here:
> > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> >
> > LAB short reminder:
> >
> > LAB uses information about how many cores are in "idle" state (the
> > core idleness is represented as the value between 0 and 100) and
> > the overall load of the system (from 0 to 100) to decide about
> > frequency to be set. It is extremely useful with SoCs like
> > Exynos4412, which can set only one frequency for all cores.
>
> Probably a description of how exactly these two values come into play
> would have been more interesting here for all. Always think of new
> followers of your patchset and so add all interesting things about it
> when you resend it.
>
> If I remember well the logic was more or less like this:
> - More idle cores means run few running cores at high frequency
> - Less idle cores means don't run them at very high frequencies
>
> Right?
This is correct. Also, the underlying SoC - Exynos4412 has 4 cores with
option to set frequency only on all of them.
>
> What about making it as simple as:
> - changing the ondemand governor only instead of adding a new governor
My goal is to not touch the ondemand code. It has matured, so I would
like to leave it as it is.
> - Keeping the bahavior as is for all platforms not publishing boost
> frequencies
This is also done - you get the LAB configuration specified in the DT
for the particular platform/board.
> - If more cores are idle, enable switching to boost frequencies and
> take them into consideration all the time.
I'm not sure if I have understood you, but something like that is also
performed in the code.
> - If less cores are idle, disable boost frequencies..
As written above.
>
> Lets discuss this first and then I will get into the very details of
> your implementation.
Discussion about above functionalities requires consulting the
implementation to be sure that our opinions are the same.
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
next prev parent reply other threads:[~2014-03-24 10:00 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
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 [this message]
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=20140324110032.7aeae15e@amdc2363 \
--to=l.majewski@samsung.com \
--cc=b.zolnierkie@samsung.com \
--cc=cpufreq@vger.kernel.org \
--cc=jonghwa3.lee@samsung.com \
--cc=l.majewski@majess.pl \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=myungjoo.ham@samsung.com \
--cc=rjw@rjwysocki.net \
--cc=t.figa@samsung.com \
--cc=ta.omasab@gmail.com \
--cc=thomas.ab@samsung.com \
--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.