All of lore.kernel.org
 help / color / mirror / Atom feed
From: Quentin Perret <quentin.perret@arm.com>
To: Patrick Bellasi <patrick.bellasi@arm.com>
Cc: Juri Lelli <juri.lelli@gmail.com>,
	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>,
	Valentin Schneider <valentin.schneider@arm.com>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	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 4/6] sched/fair: Introduce an energy estimation helper function
Date: Wed, 21 Mar 2018 14:02:37 +0000	[thread overview]
Message-ID: <20180321140235.GA2168@queper01-VirtualBox> (raw)
In-Reply-To: <20180321122621.GA13951@e110439-lin>

On Wednesday 21 Mar 2018 at 12:26:21 (+0000), Patrick Bellasi wrote:
> On 21-Mar 10:04, Juri Lelli wrote:
> > Hi,
> > 
> > On 20/03/18 09:43, Dietmar Eggemann wrote:
> > > From: Quentin Perret <quentin.perret@arm.com>
> > > 
> > > In preparation for the definition of an energy-aware wakeup path, a
> > > helper function is provided to estimate the consequence on system energy
> > > when a specific task wakes-up on a specific CPU. compute_energy()
> > > estimates the OPPs to be reached by all frequency domains and estimates
> > > the consumption of each online CPU according to its energy model and its
> > > percentage of busy time.
> > > 
> > > 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>
> > > ---
> > >  kernel/sched/fair.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >  1 file changed, 81 insertions(+)
> > > 
> > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > index 6c72a5e7b1b0..76bd46502486 100644
> > > --- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -6409,6 +6409,30 @@ static inline int cpu_overutilized(int cpu)
> > >  }
> > >  
> > >  /*
> > > + * Returns the util of "cpu" if "p" wakes up on "dst_cpu".
> > > + */
> > > +static unsigned long cpu_util_next(int cpu, struct task_struct *p, int dst_cpu)
> > > +{
> > > +	unsigned long util = cpu_rq(cpu)->cfs.avg.util_avg;
> > 
> > What about other classes? Shouldn't we now also take into account
> > DEADLINE (as schedutil does)?
> 
> Good point, although that would likely require to factor out from
> schedutil the utilization aggregation function, isn't it?
> 
> > BTW, we now also have a getter method in sched/sched.h; it takes
> > UTIL_EST into account, though. Do we need to take that into account when
> > estimating energy consumption?
> 
> Actually I think that this whole function can be written "just" as:
> 
> ---8<---
>    unsigned long util = cpu_util_wake(cpu);
> 
>    if (cpu != dst_cpu)
>         return util;
> 
>    return min(util + task_util(p), capacity_orig_of(cpu));
> ---8<---
> 

Yes this should be functionally equivalent. However, with your
suggestion you can potentially remove the task contribution from the
cpu_util in cpu_util_wake() and then add it back right after if
cpu==dst_cpu. This is sub-optimal and that's why I implemented things
slightly differently. But maybe this optimization really is too small to
justify the extra complexity involved ...

> which will reuse existing functions as well as getting for free other
> stuff (like the CPU util_est).
> 
> Considering your observation above, it makes also easy to add into
> util the DEADLINE and RT utilizations, just before returning the
> value.
> 
> > > +	unsigned long capacity = capacity_orig_of(cpu);
> > > +
> > > +	/*
> > > +	 * If p is where it should be, or if it has no impact on cpu, there is
> > > +	 * not much to do.
> > > +	 */
> > > +	if ((task_cpu(p) == dst_cpu) || (cpu != task_cpu(p) && cpu != dst_cpu))
> > > +		goto clamp_util;
> > > +
> > > +	if (dst_cpu == cpu)
> > > +		util += task_util(p);
> > > +	else
> > > +		util = max_t(long, util - task_util(p), 0);
> > > +
> > > +clamp_util:
> > > +	return (util >= capacity) ? capacity : util;
> > > +}
> > > +
> > > +/*
> > >   * Disable WAKE_AFFINE in the case where task @p doesn't fit in the
> > >   * capacity of either the waking CPU @cpu or the previous CPU @prev_cpu.
> > >   *
> > > @@ -6432,6 +6456,63 @@ static int wake_cap(struct task_struct *p, int cpu, int prev_cpu)
> > >  	return !util_fits_capacity(task_util(p), min_cap);
> > >  }
> > >  
> > > +static struct capacity_state *find_cap_state(int cpu, unsigned long util)
> > > +{
> > > +	struct sched_energy_model *em = *per_cpu_ptr(energy_model, cpu);
> > > +	struct capacity_state *cs = NULL;
> > > +	int i;
> > > +
> > > +	/*
> > > +	 * As the goal is to estimate the OPP reached for a specific util
> > > +	 * value, mimic the behaviour of schedutil with a 1.25 coefficient
> > > +	 */
> > > +	util += util >> 2;
> > 
> > What about other governors (ondemand for example). Is this supposed to
> > work only when schedutil is in use (if so we should probably make it
> > conditional on that)?
> 
> Yes, I would say that EAS mostly makes sense when you have a "minimum"
> control on OPPs... otherwise all the energy estimations are really
> fuzzy.
> 
> > Also, even when schedutil is in use, shouldn't we ask it for a util
> > "computation" instead of replicating its _current_ heuristic?
> 
> Are you proposing to have the 1.25 factor only here and remove it from
> schedutil?
> 
> > I fear  the two might diverge in the future.
> 
> That could be avoided by factoring out from schedutil the
> "compensation" factor into a proper function to be used by all the
> interested playes, isn't it?
> 
> -- 
> #include <best/regards.h>
> 
> Patrick Bellasi

  parent reply	other threads:[~2018-03-21 14:02 UTC|newest]

Thread overview: 55+ 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
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 [this message]
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  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=20180321140235.GA2168@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=juri.lelli@gmail.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 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.