linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve Muckle <steve.muckle@linaro.org>
To: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Viresh Kumar <viresh.kumar@linaro.org>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Juri Lelli <Juri.Lelli@arm.com>,
	Patrick Bellasi <patrick.bellasi@arm.com>,
	Steve Muckle <smuckle@linaro.org>
Subject: [PATCH v3 0/3] cpufreq: avoid redundant driver calls in schedutil
Date: Wed, 13 Jul 2016 13:25:24 -0700	[thread overview]
Message-ID: <1468441527-23534-1-git-send-email-smuckle@linaro.org> (raw)

Invoking the cpufreq driver to set a frequency can be expensive. On platforms
with a cpufreq driver that does not support fast switching a thread must be
woken to complete the operation. IPIs will also occur if and when support to
process remote task wakeups is added in schedutil.

Currently schedutil calculates a raw frequency request from scheduler
utilization data. This raw frequency request does not correlate to supported
cpufreq driver frequencies aside from being capped by the CPU's maximum
frequency. Consequently, there may be many consecutive requests for different
raw frequency values which all translate to the same driver-supported
frequency. For example on a platform with 3 supported frequencies 200MHz,
400MHz, and 600MHz, raw requests for 257MHz, 389MHz, and 307MHz all map to a
driver-supported frequency of 400MHz in schedutil. Assuming these requests were
consecutive and there were no changes in policy limits (min/max), there is no
need to issue the second or third request.

In order to resolve a raw frequency request to a driver-supported one a new
cpufreq API is added, cpufreq_driver_resolve_freq(). This API relies on a new
cpufreq driver callback in the case of ->target() style drivers. Otherwise it
uses the existing frequency table operations.

Lookups are cached both in cpufreq_driver_resolve_freq() (for the benefit of the
driver) and in schedutil.

Changes since v2:
- incorporated feedback from Viresh to use resolve_freq driver callbacks
  only for ->target() style drivers, to use cpufreq's freq table operations,
  and move freq mapping caching into cpufreq policy
Changes since v1:
- incorporated feedback from Rafael to avoid referencing freq_table from
  schedutil by introducing a new cpufreq API

Steve Muckle (3):
  cpufreq: add cpufreq_driver_resolve_freq()
  cpufreq: schedutil: map raw required frequency to driver frequency
  cpufreq: acpi-cpufreq: use cached frequency mapping when possible

 drivers/cpufreq/acpi-cpufreq.c   |  5 ++++-
 drivers/cpufreq/cpufreq.c        | 25 +++++++++++++++++++++++++
 include/linux/cpufreq.h          | 16 ++++++++++++++++
 kernel/sched/cpufreq_schedutil.c | 31 +++++++++++++++++++++++--------
 4 files changed, 68 insertions(+), 9 deletions(-)

-- 
2.7.3


             reply	other threads:[~2016-07-13 20:25 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-13 20:25 Steve Muckle [this message]
2016-07-13 20:25 ` [PATCH v3 1/3] cpufreq: add cpufreq_driver_resolve_freq() Steve Muckle
2016-07-21 19:59   ` Viresh Kumar
2016-07-21 20:31     ` Rafael J. Wysocki
2016-07-21 20:30       ` Viresh Kumar
2016-07-21 20:52         ` Rafael J. Wysocki
2016-07-21 20:52           ` Viresh Kumar
2016-07-21 21:19             ` Rafael J. Wysocki
2016-07-21 21:16               ` Viresh Kumar
2016-07-21 23:21         ` Steve Muckle
2016-07-21 23:29           ` Steve Muckle
2016-07-21 23:31             ` Viresh Kumar
2016-07-21 23:30           ` Viresh Kumar
2016-07-21 23:36             ` Steve Muckle
2016-07-21 23:41               ` Steve Muckle
2016-07-22  0:44               ` Steve Muckle
2016-07-22 15:16                 ` Viresh Kumar
2016-07-22 17:49                   ` Steve Muckle
2016-07-21 21:13   ` Viresh Kumar
2016-07-13 20:25 ` [PATCH v3 2/3] cpufreq: schedutil: map raw required frequency to driver frequency Steve Muckle
2016-07-13 20:25 ` [PATCH v3 3/3] cpufreq: acpi-cpufreq: use cached frequency mapping when possible Steve Muckle
2016-07-14 10:02 ` [PATCH v3 0/3] cpufreq: avoid redundant driver calls in schedutil Pingbo Wen
2016-07-14 18:00   ` Steve Muckle
2016-07-21 20:01 ` 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=1468441527-23534-1-git-send-email-smuckle@linaro.org \
    --to=steve.muckle@linaro.org \
    --cc=Juri.Lelli@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=morten.rasmussen@arm.com \
    --cc=patrick.bellasi@arm.com \
    --cc=peterz@infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=smuckle@linaro.org \
    --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 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).