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: Juri Lelli <juri.lelli@arm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Patrick Bellasi <patrick.bellasi@arm.com>,
	Joel Fernandes <joelaf@google.com>,
	Morten Rasmussen <morten.rasmussen@arm.com>
Subject: [RFC/RFT][PATCH 1/2] cpufreq: schedutil: Use policy-dependent latency multupliers
Date: Mon, 10 Apr 2017 02:10:46 +0200	[thread overview]
Message-ID: <2407280.n9qVSLCrF5@aspire.rjw.lan> (raw)
In-Reply-To: <3498238.liCqOyIkGA@aspire.rjw.lan>

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

Make the schedutil governor compute the initial (default) value of
the rate_limit_us sysfs attribute by multiplying the transition
latency by a multiplier depending on the policy and set by the
scaling driver (instead of using a constant for this purpose).

That will allow scaling drivers to make schedutil use smaller default
values of rate_limit_us and reduce the default average time interval
between consecutive frequency changes.

Make intel_pstate use the opportunity to reduce the rate limit
somewhat.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/cpufreq/cpufreq.c        |    1 +
 drivers/cpufreq/intel_pstate.c   |    2 ++
 include/linux/cpufreq.h          |    8 ++++++++
 kernel/sched/cpufreq_schedutil.c |    2 +-
 4 files changed, 12 insertions(+), 1 deletion(-)

Index: linux-pm/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq.c
+++ linux-pm/drivers/cpufreq/cpufreq.c
@@ -1072,6 +1072,7 @@ static struct cpufreq_policy *cpufreq_po
 	init_waitqueue_head(&policy->transition_wait);
 	init_completion(&policy->kobj_unregister);
 	INIT_WORK(&policy->update, handle_update);
+	policy->latency_multiplier = LATENCY_MULTIPLIER;
 
 	policy->cpu = cpu;
 	return policy;
Index: linux-pm/include/linux/cpufreq.h
===================================================================
--- linux-pm.orig/include/linux/cpufreq.h
+++ linux-pm/include/linux/cpufreq.h
@@ -120,6 +120,14 @@ struct cpufreq_policy {
 	bool			fast_switch_possible;
 	bool			fast_switch_enabled;
 
+	/*
+	 * Multiplier to apply to the transition latency to obtain the preferred
+	 * average time interval between consecutive invocations of the driver
+	 * to set the frequency for this policy.  Initialized by the core to the
+	 * LATENCY_MULTIPLIER value.
+	 */
+	unsigned int		latency_multiplier;
+
 	 /* Cached frequency lookup from cpufreq_driver_resolve_freq. */
 	unsigned int cached_target_freq;
 	int cached_resolved_idx;
Index: linux-pm/kernel/sched/cpufreq_schedutil.c
===================================================================
--- linux-pm.orig/kernel/sched/cpufreq_schedutil.c
+++ linux-pm/kernel/sched/cpufreq_schedutil.c
@@ -530,7 +530,7 @@ static int sugov_init(struct cpufreq_pol
 		goto stop_kthread;
 	}
 
-	tunables->rate_limit_us = LATENCY_MULTIPLIER;
+	tunables->rate_limit_us = policy->latency_multiplier;
 	lat = policy->cpuinfo.transition_latency / NSEC_PER_USEC;
 	if (lat)
 		tunables->rate_limit_us *= lat;
Index: linux-pm/drivers/cpufreq/intel_pstate.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -41,6 +41,7 @@
 #define INTEL_PSTATE_HWP_SAMPLING_INTERVAL	(50 * NSEC_PER_MSEC)
 
 #define INTEL_CPUFREQ_TRANSITION_LATENCY	20000
+#define INTEL_CPUFREQ_LATENCY_MULTIPLIER	250
 
 #ifdef CONFIG_ACPI
 #include <acpi/processor.h>
@@ -2237,6 +2238,7 @@ static int intel_cpufreq_cpu_init(struct
 		return ret;
 
 	policy->cpuinfo.transition_latency = INTEL_CPUFREQ_TRANSITION_LATENCY;
+	policy->latency_multiplier = INTEL_CPUFREQ_LATENCY_MULTIPLIER;
 	/* This reflects the intel_pstate_get_cpu_pstates() setting. */
 	policy->cur = policy->cpuinfo.min_freq;
 

  reply	other threads:[~2017-04-10  0:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-10  0:07 [RFC/RFT][PATCH 0/2] cpufreq: schedutil: Updates related to the rate limit Rafael J. Wysocki
2017-04-10  0:10 ` Rafael J. Wysocki [this message]
2017-04-10 10:38   ` [RFC/RFT][PATCH 1/2] cpufreq: schedutil: Use policy-dependent latency multupliers Brendan Jackman
2017-04-10 11:03     ` Rafael J. Wysocki
2017-04-10 22:20   ` [RFC/RFT][PATCH 1/2] cpufreq: schedutil: Use policy-dependent transition delays Rafael J. Wysocki
2017-04-11 11:14     ` Viresh Kumar
2017-04-11 14:01       ` Rafael J. Wysocki
2017-04-14 22:51     ` Rafael J. Wysocki
2017-04-15  2:23       ` Joel Fernandes
2017-04-18  9:43       ` Brendan Jackman
2017-04-17  5:41     ` Viresh Kumar
2017-04-10  0:11 ` [RFC/RFT][PATCH 2/2] cpufreq: schedutil: Utilization aggregation Rafael J. Wysocki
2017-04-10  6:39   ` Joel Fernandes
2017-04-10 20:59     ` Rafael J. Wysocki
2017-04-11  1:57       ` Joel Fernandes
2017-04-11 20:53         ` Rafael J. Wysocki
2017-04-10 11:26   ` Juri Lelli
2017-04-10 21:13     ` Rafael J. Wysocki
2017-04-11  7:00       ` Juri Lelli
2017-04-11 21:03         ` 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=2407280.n9qVSLCrF5@aspire.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=joelaf@google.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.