linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

  reply	other threads:[~2014-03-24 10:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1367590072-10496-1-git-send-email-jonghwa3.lee@samsung.com>
     [not found] ` <1393928852-22725-1-git-send-email-l.majewski@samsung.com>
2014-03-17 15:38   ` [RFC v3 0/5] cpufreq:LAB: Support for LAB governor Lukasz Majewski
2014-03-18  6:55     ` Viresh Kumar
2014-03-18  9:17       ` Lukasz Majewski
2014-03-24  6:47         ` Lukasz Majewski
2014-03-24  6:51           ` Viresh Kumar
2014-03-24  8:48   ` Viresh Kumar
2014-03-24 10:00     ` Lukasz Majewski [this message]
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=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).