All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Linux PM <linux-pm@vger.kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Juri Lelli <juri.lelli@arm.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Patrick Bellasi <patrick.bellasi@arm.com>,
	Joel Fernandes <joelaf@google.com>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	John <john.ettedgui@gmail.com>
Subject: [RFC/RFT][PATCH] cpufreq: schedutil: Reduce frequencies slower
Date: Thu, 30 Mar 2017 23:36:41 +0200	[thread overview]
Message-ID: <1514608.eWxQqcMBcc@aspire.rjw.lan> (raw)

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The schedutil governor reduces frequencies too fast in some
situations which cases undesirable performance drops to
appear.

To address that issue, make schedutil reduce the frequency slower by
setting it to the average of the value chosen during the previous
iteration of governor computations and the new one coming from its
frequency selection formula.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=194963
Reported-by: John <john.ettedgui@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---

This addresses a practical issue, but one in the "responsiveness" or
"interactivity" category which is quite hard to represent quantitatively.

As reported by John in BZ194963, schedutil does not ramp up P-states quickly
enough which causes audio issues to appear in his gaming setup.  At least it
evidently is worse than ondemand in this respect and the patch below helps.

The patch essentially repeats the trick added some time ago to the load-based
P-state selection algorithm in intel_pstate, which allowed us to make it viable
for performance-oriented users, and which is to reduce frequencies at a slower
pace.

The reason why I chose the average is because it is computationally cheap
and pretty much the max reasonable slowdown and the idea is that in case
there's something about to run that we don't know about yet, it is better to
stay at a higher level for a while more to avoid having to get up from the floor
every time.

But technically speaking it is a filter. :-)

So among other things I'm wondering if that leads to substantial increases in
energy consumption anywhere.

Thanks,
Rafael

---
 kernel/sched/cpufreq_schedutil.c |    3 +++
 1 file changed, 3 insertions(+)

Index: linux-pm/kernel/sched/cpufreq_schedutil.c
===================================================================
--- linux-pm.orig/kernel/sched/cpufreq_schedutil.c
+++ linux-pm/kernel/sched/cpufreq_schedutil.c
@@ -101,6 +101,9 @@ static void sugov_update_commit(struct s
 	if (sg_policy->next_freq == next_freq)
 		return;
 
+	if (sg_policy->next_freq > next_freq)
+		next_freq = (sg_policy->next_freq + next_freq) >> 1;
+
 	sg_policy->next_freq = next_freq;
 	sg_policy->last_freq_update_time = time;
 

             reply	other threads:[~2017-03-30 21:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-30 21:36 Rafael J. Wysocki [this message]
2017-03-31 10:22 ` [RFC/RFT][PATCH] cpufreq: schedutil: Reduce frequencies slower Juri Lelli
2017-03-31 21:51   ` Rafael J. Wysocki
     [not found]     ` <CAFEhuF=sWvuC3Q1NsqdRuiGzK4uD8ie5zbEnVsuGMdJK3y9e3Q@mail.gmail.com>
2017-04-01 23:29       ` Andres Oportus
2017-04-02  2:03         ` Rafael J. Wysocki
2017-04-02  4:38           ` Andres Oportus
2017-04-11 21:23 ` Rafael J. Wysocki
2017-04-12  9:01   ` Juri Lelli
2017-04-12  9:03 ` 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=1514608.eWxQqcMBcc@aspire.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=joelaf@google.com \
    --cc=john.ettedgui@gmail.com \
    --cc=juri.lelli@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=morten.rasmussen@arm.com \
    --cc=patrick.bellasi@arm.com \
    --cc=peterz@infradead.org \
    --cc=srinivas.pandruvada@linux.intel.com \
    --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.