cpufreq Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Stratos Karafotis <stratosk@semaphore.gr>,
	linux-kernel@vger.kernel.org, cpufreq@vger.kernel.org,
	linux-pm@vger.kernel.org
Subject: Re: [PATCH] cpufreq: ondemand: Change the calculation of target frequency
Date: Mon, 03 Jun 2013 12:57:47 +0200	[thread overview]
Message-ID: <2413427.Abjbfkms0Z@vostro.rjw.lan> (raw)
In-Reply-To: <CAKohpo=EyudEW+EX=b7=Wp-7ceqjVksDTwwSJf77_LNFaaNL3w@mail.gmail.com>

On Monday, June 03, 2013 12:25:02 PM Viresh Kumar wrote:
> Sent half written mail.. sorry.. will continue from where I left.
> 
> On 3 June 2013 12:21, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> 
> > So, obviously the calculations aren't the same..
> 
> Now, this is how I understood these two different variables:
> - cpuinfo.max_freq: maximum frequency (in kHz) which is
> supported by this CPU
> - policy->max: Maximum frequency forced by user or governor
> 
> When somebody sets policy->max, he expects cpufreq core to
> use the range between min and max as the slope cpufreq core
> has and adjust its frequencies accordingly..
> 
> Don't know if I am right or wrong :(

The reality is that the set of frequencies to use is constant and changing
policy->max doesn't change that set.  There are just fewer frequencies the
governor can choose from if policy->max is below cpuinfo.max_freq.

The question is if we want policy->max to re-scale them effectively (i.e. to
change weights so that the maximum load maps to the highest frequency available
at the moment) or if we want policy->max to work as a cap (i.e. to map all
loads above certain value to the maximum frequency available at the moment, so
that the criteria for selecting the lower frequencies don't change).  In my
opinion the second option is better, because it means "OK, we can't use some
high frequencies, but let's not hurt performance for the loads that wouldn't
require them anyway".  Otherwise, we'll effectively throttle all loads and
that not only causes performance to drop, but also causes more energy to be
used overall.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

  reply	other threads:[~2013-06-03 10:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-30 21:07 [PATCH] cpufreq: ondemand: Change the calculation of target frequency Stratos Karafotis
2013-05-31  8:51 ` Viresh Kumar
2013-05-31 16:33   ` Stratos Karafotis
2013-06-01 12:27     ` Rafael J. Wysocki
2013-06-01 12:50       ` Stratos Karafotis
2013-06-01 14:56     ` Viresh Kumar
2013-06-01 16:06       ` Stratos Karafotis
2013-06-03  6:11         ` Viresh Kumar
2013-06-01 19:37       ` Rafael J. Wysocki
2013-06-03  6:51         ` Viresh Kumar
2013-06-03  6:55           ` Viresh Kumar
2013-06-03 10:57             ` Rafael J. Wysocki [this message]
2013-06-03 11:24               ` Viresh Kumar
2013-06-03 16:12                 ` Stratos Karafotis
2013-06-03 10:32           ` Rafael J. Wysocki
2013-05-31  8:54 ` Viresh Kumar
2013-05-31 12:42   ` Rafael J. Wysocki

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=2413427.Abjbfkms0Z@vostro.rjw.lan \
    --to=rjw@sisk.pl \
    --cc=cpufreq@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=stratosk@semaphore.gr \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox