linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thara Gopinath <thara.gopinath@linaro.org>
To: mingo@redhat.com, peterz@infradead.org, ionela.voinescu@arm.com,
	vincent.guittot@linaro.org, rui.zhang@intel.com,
	qperret@google.com, daniel.lezcano@linaro.org,
	viresh.kumar@linaro.org
Cc: linux-kernel@vger.kernel.org, amit.kachhap@gmail.com,
	javi.merino@kernel.org, amit.kucheria@verdurent.com
Subject: [Patch v6 0/7] Introduce Thermal Pressure
Date: Wed, 11 Dec 2019 23:11:41 -0500	[thread overview]
Message-ID: <1576123908-12105-1-git-send-email-thara.gopinath@linaro.org> (raw)

Thermal governors can respond to an overheat event of a cpu by
capping the cpu's maximum possible frequency. This in turn
means that the maximum available compute capacity of the
cpu is restricted. But today in the kernel, task scheduler is
not notified of capping of maximum frequency of a cpu.
In other words, scheduler is unaware of maximum capacity
restrictions placed on a cpu due to thermal activity.
This patch series attempts to address this issue.
The benefits identified are better task placement among available
cpus in event of overheating which in turn leads to better
performance numbers.

The reduction in the maximum possible capacity of a cpu due to a
thermal event can be considered as thermal pressure. Instantaneous
thermal pressure is hard to record and can sometime be erroneous
as there can be mismatch between the actual capping of capacity
and scheduler recording it. Thus solution is to have a weighted
average per cpu value for thermal pressure over time.
The weight reflects the amount of time the cpu has spent at a
capped maximum frequency. Since thermal pressure is recorded as
an average, it must be decayed periodically. Exisiting algorithm
in the kernel scheduler pelt framework is re-used to calculate
the weighted average. This patch series also defines a sysctl
inerface to allow for a configurable decay period.

Regarding testing, basic build, boot and sanity testing have been
performed on db845c platform with debian file system.
Further, dhrystone and hackbench tests have been
run with the thermal pressure algorithm. During testing, due to
constraints of step wise governor in dealing with big little systems,
trip point 0 temperature was made assymetric between cpus in little
cluster and big cluster; the idea being that
big core will heat up and cpu cooling device will throttle the
frequency of the big cores faster, there by limiting the maximum available
capacity and the scheduler will spread out tasks to little cores as well.

Test Results

Hackbench: 1 group , 30000 loops, 10 runs
                                               Result         SD
                                               (Secs)     (% of mean)
 No Thermal Pressure                            14.03       2.69%
 Thermal Pressure PELT Algo. Decay : 32 ms      13.29       0.56%
 Thermal Pressure PELT Algo. Decay : 64 ms      12.57       1.56%
 Thermal Pressure PELT Algo. Decay : 128 ms     12.71       1.04%
 Thermal Pressure PELT Algo. Decay : 256 ms     12.29       1.42%
 Thermal Pressure PELT Algo. Decay : 512 ms     12.42       1.15%

Dhrystone Run Time  : 20 threads, 3000 MLOOPS
                                                 Result      SD
                                                 (Secs)    (% of mean)
 No Thermal Pressure                              9.452      4.49%
 Thermal Pressure PELT Algo. Decay : 32 ms        8.793      5.30%
 Thermal Pressure PELT Algo. Decay : 64 ms        8.981      5.29%
 Thermal Pressure PELT Algo. Decay : 128 ms       8.647      6.62%
 Thermal Pressure PELT Algo. Decay : 256 ms       8.774      6.45%
 Thermal Pressure PELT Algo. Decay : 512 ms       8.603      5.41%

A Brief History

The first version of this patch-series was posted with resuing
PELT algorithm to decay thermal pressure signal. The discussions
that followed were around whether intanteneous thermal pressure
solution is better and whether a stand-alone algortihm to accumulate
and decay thermal pressure is more appropriate than re-using the
PELT framework.
Tests on Hikey960 showed the stand-alone algorithm performing slightly
better than resuing PELT algorithm and V2 was posted with the stand
alone algorithm. Test results were shared as part of this series.
Discussions were around re-using PELT algorithm and running
further tests with more granular decay period.

For some time after this development was impeded due to hardware
unavailability, some other unforseen and possibly unfortunate events.
For this version, h/w was switched from hikey960 to db845c.
Also Instantaneous thermal pressure was never tested as part of this
cycle as it is clear that weighted average is a better implementation.
The non-PELT algorithm never gave any conclusive results to prove that it
is better than reusing PELT algorithm, in this round of testing.
Also reusing PELT algorithm means thermal pressure tracks the
other utilization signals in the scheduler.

v3->v4:
        - "Patch 3/7:sched: Initialize per cpu thermal pressure structure"
           is dropped as it is no longer needed following changes in other
           other patches.
        - rest of the change log mentioned in specific patches.

v5->v6:
	- "Added arch_ interface APIs to access and update thermal pressure.
	   Moved declaration of per cpu thermal_pressure valriable and
	   infrastructure to update the variable to topology files.

Thara Gopinath (6):
  sched/pelt.c: Add support to track thermal pressure
  sched/fair: Add infrastructure to store and update  instantaneous
    thermal pressure
  sched/fair: Enable periodic update of thermal pressure
  sched/fair: update cpu_capcity to reflect thermal pressure
  thermal/cpu-cooling: Update thermal pressure in case of a maximum
    frequency capping
  sched/fair: Enable tuning of decay period


Thara Gopinath (7):
  sched/pelt.c: Add support to track thermal pressure
  sched: Add hook to read per cpu thermal pressure.
  Add infrastructure to store and update instantaneous thermal pressure
  sched/fair: Enable periodic update of average thermal pressure
  sched/fair: update cpu_capacity to reflect thermal pressure
  thermal/cpu-cooling: Update thermal pressure in case of a maximum
    frequency capping
  sched/fair: Enable tuning of decay period

 Documentation/admin-guide/kernel-parameters.txt |  5 +++
 arch/arm/include/asm/topology.h                 |  3 ++
 arch/arm64/include/asm/topology.h               |  3 ++
 drivers/base/arch_topology.c                    | 13 +++++++
 drivers/thermal/cpu_cooling.c                   | 19 +++++++++--
 include/linux/arch_topology.h                   | 11 ++++++
 include/linux/sched/topology.h                  |  8 +++++
 include/trace/events/sched.h                    |  4 +++
 kernel/sched/fair.c                             | 45 +++++++++++++++++++++++++
 kernel/sched/pelt.c                             | 22 ++++++++++++
 kernel/sched/pelt.h                             |  7 ++++
 kernel/sched/sched.h                            |  1 +
 12 files changed, 139 insertions(+), 2 deletions(-)

-- 
2.1.4


             reply	other threads:[~2019-12-12  4:11 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-12  4:11 Thara Gopinath [this message]
2019-12-12  4:11 ` [Patch v6 1/7] sched/pelt.c: Add support to track thermal pressure Thara Gopinath
2019-12-16 13:43   ` Peter Zijlstra
2019-12-17 12:54   ` Dietmar Eggemann
     [not found]     ` <CALD-y_xHS7CaZ8SU--VP5+2F5Y8cVb4sw0XuG+JUpP_jxE7yuQ@mail.gmail.com>
2020-01-09 12:24       ` Dietmar Eggemann
2019-12-23 17:56   ` Ionela Voinescu
2020-01-02 14:40     ` Thara Gopinath
2019-12-12  4:11 ` [Patch v6 2/7] sched: Add hook to read per cpu " Thara Gopinath
2019-12-16 14:35   ` Peter Zijlstra
2019-12-17 12:54     ` Dietmar Eggemann
2019-12-12  4:11 ` [Patch v6 3/7] Add infrastructure to store and update instantaneous " Thara Gopinath
2019-12-16 14:37   ` Peter Zijlstra
2019-12-17 12:54   ` Dietmar Eggemann
2019-12-23 17:50   ` Ionela Voinescu
2019-12-12  4:11 ` [Patch v6 4/7] sched/fair: Enable periodic update of average " Thara Gopinath
2019-12-16 14:39   ` Peter Zijlstra
2019-12-16 17:59     ` Quentin Perret
2019-12-17 12:57       ` Dietmar Eggemann
2019-12-27 15:22         ` Thara Gopinath
2019-12-12  4:11 ` [Patch v6 5/7] sched/fair: update cpu_capacity to reflect " Thara Gopinath
2019-12-17 12:54   ` Dietmar Eggemann
2019-12-23 17:52   ` Ionela Voinescu
2019-12-12  4:11 ` [Patch v6 6/7] thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping Thara Gopinath
2019-12-23 17:54   ` Ionela Voinescu
2019-12-12  4:11 ` [Patch v6 7/7] sched/fair: Enable tuning of decay period Thara Gopinath
2019-12-23 17:55   ` Ionela Voinescu
2019-12-16 14:56 ` [Patch v6 0/7] Introduce Thermal Pressure Peter Zijlstra
2020-01-11 15:04   ` Thara Gopinath

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=1576123908-12105-1-git-send-email-thara.gopinath@linaro.org \
    --to=thara.gopinath@linaro.org \
    --cc=amit.kachhap@gmail.com \
    --cc=amit.kucheria@verdurent.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=ionela.voinescu@arm.com \
    --cc=javi.merino@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=qperret@google.com \
    --cc=rui.zhang@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 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).