linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Quentin Perret <quentin.perret@arm.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
	linux-kernel@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Thara Gopinath <thara.gopinath@linaro.org>,
	linux-pm@vger.kernel.org,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Chris Redpath <chris.redpath@arm.com>,
	Patrick Bellasi <patrick.bellasi@arm.com>,
	Valentin Schneider <valentin.schneider@arm.com>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Todd Kjos <tkjos@google.com>, Joel Fernandes <joelaf@google.com>
Subject: Re: [RFC PATCH 2/6] sched: Introduce energy models of CPUs
Date: Wed, 21 Mar 2018 00:45:22 +0000	[thread overview]
Message-ID: <20180321004521.GA3174@queper01-VirtualBox> (raw)
In-Reply-To: <20180320095215.GB23359@kroah.com>

On Tuesday 20 Mar 2018 at 10:52:15 (+0100), Greg Kroah-Hartman wrote:
> On Tue, Mar 20, 2018 at 09:43:08AM +0000, Dietmar Eggemann wrote:
> > From: Quentin Perret <quentin.perret@arm.com>
> > 
> > The energy consumption of each CPU in the system is modeled with a list
> > of values representing its dissipated power and compute capacity at each
> > available Operating Performance Point (OPP). These values are derived
> > from existing information in the kernel (currently used by the thermal
> > subsystem) and don't require the introduction of new platform-specific
> > tunables. The energy model is also provided with a simple representation
> > of all frequency domains as cpumasks, hence enabling the scheduler to be
> > aware of dependencies between CPUs. The data required to build the energy
> > model is provided by the OPP library which enables an abstract view of
> > the platform from the scheduler. The new data structures holding these
> > models and the routines to populate them are stored in
> > kernel/sched/energy.c.
> > 
> > For the sake of simplicity, it is assumed in the energy model that all
> > CPUs in a frequency domain share the same micro-architecture. As long as
> > this assumption is correct, the energy models of different CPUs belonging
> > to the same frequency domain are equal. Hence, this commit builds only one
> > energy model per frequency domain, and links all relevant CPUs to it in
> > order to save time and memory. If needed for future hardware platforms,
> > relaxing this assumption should imply relatively simple modifications in
> > the code but a significantly higher algorithmic complexity.
> > 
> > As it appears that energy-aware scheduling really makes a difference on
> > heterogeneous systems (e.g. big.LITTLE platforms), it is restricted to
> > systems having:
> > 
> >    1. SD_ASYM_CPUCAPACITY flag set
> >    2. Dynamic Voltage and Frequency Scaling (DVFS) is enabled
> >    3. Available power estimates for the OPPs of all possible CPUs
> > 
> > Moreover, the scheduler is notified of the energy model availability
> > using a static key in order to minimize the overhead on non-energy-aware
> > systems.
> > 
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Signed-off-by: Quentin Perret <quentin.perret@arm.com>
> > Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
> > 
> > ---
> > This patch depends on additional infrastructure being merged in the OPP
> > core. As this infrastructure can also be useful for other clients, the
> > related patches have been posted separately [1].
> > 
> > [1] https://marc.info/?l=linux-pm&m=151635516419249&w=2
> > ---
> >  include/linux/sched/energy.h |  31 +++++++
> >  kernel/sched/Makefile        |   2 +-
> >  kernel/sched/energy.c        | 190 +++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 222 insertions(+), 1 deletion(-)
> >  create mode 100644 include/linux/sched/energy.h
> >  create mode 100644 kernel/sched/energy.c
> > 
> > diff --git a/include/linux/sched/energy.h b/include/linux/sched/energy.h
> > new file mode 100644
> > index 000000000000..b4f43564ffe4
> > --- /dev/null
> > +++ b/include/linux/sched/energy.h
> > @@ -0,0 +1,31 @@
> > +#ifndef _LINUX_SCHED_ENERGY_H
> > +#define _LINUX_SCHED_ENERGY_H
> 
> No copyright or license info?  Not good :(
> 
> > --- /dev/null
> > +++ b/kernel/sched/energy.c
> > @@ -0,0 +1,190 @@
> > +/*
> > + * Released under the GPLv2 only.
> > + * SPDX-License-Identifier: GPL-2.0
> 
> Please read the documentation for the SPDX lines on how to do them
> correctly.  Newer versions of checkpatch.pl will catch this, but that is
> in linux-next for the moment.
> 
> And once you have the SPDX line, the "Released under..." line is not
> needed.
> 
> 
> > + *
> > + * Energy-aware scheduling models
> > + *
> > + * Copyright (C) 2018, Arm Ltd.
> > + * Written by: Quentin Perret, Arm Ltd.
> > + *
> > + * This file is subject to the terms and conditions of the GNU General Public
> > + * License.  See the file "COPYING" in the main directory of this archive
> > + * for more details.
> 
> This paragraph is not needed at all.

Right, I will fix all the licence issues and add one to the new header
file. I took example on existing files a while ago when I first wrote
the patches and forgot to update them later on. Sorry about that.

> 
> > + */
> > +
> > +#define pr_fmt(fmt) "sched-energy: " fmt
> > +
> > +#include <linux/sched/topology.h>
> > +#include <linux/sched/energy.h>
> > +#include <linux/pm_opp.h>
> > +
> > +#include "sched.h"
> > +
> > +DEFINE_STATIC_KEY_FALSE(sched_energy_present);
> > +struct sched_energy_model ** __percpu energy_model;
> > +
> > +/*
> > + * A copy of the cpumasks representing the frequency domains is kept private
> > + * to the scheduler. They are stacked in a dynamically allocated linked list
> > + * as we don't know how many frequency domains the system has.
> > + */
> > +LIST_HEAD(freq_domains);
> 
> global variable?  If so, please prefix it with something more unique
> than "freq_".

Will do.

> 
> > +#ifdef CONFIG_PM_OPP
> 
> #ifdefs go in .h files, not .c files, right?

Yes good point. Actually, I might be able to tweak only kernel/sched/Makefile
to ensure we have CONFIG_PM_OPP. I will look into it.

> 
> thanks,
> 
> greg k-h

Thanks,
Quentin

  reply	other threads:[~2018-03-21  0:45 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-20  9:43 [RFC PATCH 0/6] Energy Aware Scheduling Dietmar Eggemann
2018-03-20  9:43 ` [RFC PATCH 1/6] sched/fair: Create util_fits_capacity() Dietmar Eggemann
2018-03-20  9:43 ` [RFC PATCH 2/6] sched: Introduce energy models of CPUs Dietmar Eggemann
2018-03-20  9:52   ` Greg Kroah-Hartman
2018-03-21  0:45     ` Quentin Perret [this message]
2018-03-25 13:48     ` Quentin Perret
2018-03-26 22:26       ` Dietmar Eggemann
2018-04-09 12:01   ` Peter Zijlstra
2018-04-09 13:45     ` Quentin Perret
2018-04-09 15:32       ` Peter Zijlstra
2018-04-09 16:42         ` Quentin Perret
2018-04-10  6:55           ` Rafael J. Wysocki
2018-04-10  9:31             ` Quentin Perret
2018-04-10 10:20               ` Rafael J. Wysocki
2018-03-20  9:43 ` [RFC PATCH 3/6] sched: Add over-utilization/tipping point indicator Dietmar Eggemann
2018-04-09  9:40   ` Peter Zijlstra
2018-04-09  9:47     ` Peter Zijlstra
2018-04-09  9:53     ` Dietmar Eggemann
2018-04-09 11:49       ` Peter Zijlstra
2018-03-20  9:43 ` [RFC PATCH 4/6] sched/fair: Introduce an energy estimation helper function Dietmar Eggemann
2018-03-21  9:04   ` Juri Lelli
2018-03-21 12:26     ` Patrick Bellasi
2018-03-21 12:59       ` Juri Lelli
2018-03-21 13:55         ` Quentin Perret
2018-03-21 15:15           ` Juri Lelli
2018-03-21 16:26             ` Morten Rasmussen
2018-03-21 17:02               ` Juri Lelli
2018-03-21 14:02       ` Quentin Perret
2018-03-21 21:15         ` Dietmar Eggemann
2018-03-21 12:39   ` Patrick Bellasi
2018-03-21 14:26     ` Quentin Perret
2018-03-21 14:50       ` Juri Lelli
2018-03-21 15:54       ` Patrick Bellasi
2018-03-22  5:05         ` Quentin Perret
2018-03-20  9:43 ` [RFC PATCH 5/6] sched/fair: Select an energy-efficient CPU on task wake-up Dietmar Eggemann
2018-03-21 15:35   ` Patrick Bellasi
2018-03-22 20:10     ` Joel Fernandes
2018-03-23 15:47       ` Morten Rasmussen
2018-03-24  1:13         ` Joel Fernandes
2018-03-24  1:34           ` Quentin Perret
2018-03-24  6:06             ` Joel Fernandes
2018-03-24  1:22         ` Quentin Perret
2018-03-25  1:52     ` Quentin Perret
2018-03-22 16:27   ` Joel Fernandes
2018-03-22 18:06     ` Patrick Bellasi
2018-03-22 20:19       ` Joel Fernandes
2018-03-24  1:47         ` Quentin Perret
2018-03-25  0:12           ` Joel Fernandes
2018-03-23 16:00     ` Morten Rasmussen
2018-03-24  0:36       ` Joel Fernandes
2018-03-25  1:38       ` Quentin Perret
2018-03-20  9:43 ` [RFC PATCH 6/6] drivers: base: arch_topology.c: Enable EAS for arm/arm64 platforms Dietmar Eggemann
2018-03-20  9:49   ` Greg Kroah-Hartman
2018-03-20 15:20     ` Dietmar Eggemann

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=20180321004521.GA3174@queper01-VirtualBox \
    --to=quentin.perret@arm.com \
    --cc=chris.redpath@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=joelaf@google.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=rjw@rjwysocki.net \
    --cc=thara.gopinath@linaro.org \
    --cc=tkjos@google.com \
    --cc=valentin.schneider@arm.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).