public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Patrick Bellasi <patrick.bellasi@arm.com>
To: Joel Fernandes <joelaf@google.com>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Quentin Perret <quentin.perret@arm.com>,
	Thara Gopinath <thara.gopinath@linaro.org>,
	Linux PM <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>
Subject: Re: [RFC PATCH 5/6] sched/fair: Select an energy-efficient CPU on task wake-up
Date: Thu, 22 Mar 2018 18:06:23 +0000	[thread overview]
Message-ID: <20180322180623.GE13951@e110439-lin> (raw)
In-Reply-To: <CAJWu+oqO75h0Ue0=zqD1KTcHFF7tUKYgCHQzXx39RyyGTjiang@mail.gmail.com>

On 22-Mar 09:27, Joel Fernandes wrote:
> Hi,
> 
> On Tue, Mar 20, 2018 at 2:43 AM, Dietmar Eggemann
> <dietmar.eggemann@arm.com> wrote:
> >
> > From: Quentin Perret <quentin.perret@arm.com>

[...]

> > +static inline bool wake_energy(struct task_struct *p, int prev_cpu)
> > +{
> > +       struct sched_domain *sd;
> > +
> > +       if (!static_branch_unlikely(&sched_energy_present))
> > +               return false;
> > +
> > +       sd = rcu_dereference_sched(cpu_rq(prev_cpu)->sd);
> > +       if (!sd || sd_overutilized(sd))
> 
> Shouldn't you check for the SD_ASYM_CPUCAPACITY flag here?

I think that should be already covered by the static key check
above...

> 
> > +               return false;
> > +
> > +       return true;
> > +}
> > +
> >  /*
> >   * select_task_rq_fair: Select target runqueue for the waking task in domains
> >   * that have the 'sd_flag' flag set. In practice, this is SD_BALANCE_WAKE,
> > @@ -6529,18 +6583,22 @@ static int
> >  select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int wake_flags)
> >  {
> >         struct sched_domain *tmp, *affine_sd = NULL, *sd = NULL;
> > +       struct sched_domain *energy_sd = NULL;
> >         int cpu = smp_processor_id();
> >         int new_cpu = prev_cpu;
> > -       int want_affine = 0;
> > +       int want_affine = 0, want_energy = 0;
> >         int sync = (wake_flags & WF_SYNC) && !(current->flags & PF_EXITING);
> >
> > +       rcu_read_lock();
> > +
> >         if (sd_flag & SD_BALANCE_WAKE) {
> >                 record_wakee(p);
> > +               want_energy = wake_energy(p, prev_cpu);
> >                 want_affine = !wake_wide(p) && !wake_cap(p, cpu, prev_cpu)
> > -                             && cpumask_test_cpu(cpu, &p->cpus_allowed);
> > +                             && cpumask_test_cpu(cpu, &p->cpus_allowed)
> > +                             && !want_energy;
> >         }
> >
> > -       rcu_read_lock();
> >         for_each_domain(cpu, tmp) {
> >                 if (!(tmp->flags & SD_LOAD_BALANCE))
> >                         break;
> > @@ -6555,6 +6613,14 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int wake_f
> >                         break;
> >                 }
> >
> > +               /*
> > +                * Energy-aware task placement is performed on the highest
> > +                * non-overutilized domain spanning over cpu and prev_cpu.
> > +                */
> > +               if (want_energy && !sd_overutilized(tmp) &&
> > +                   cpumask_test_cpu(prev_cpu, sched_domain_span(tmp)))
> 
> Shouldn't you check for the SD_ASYM_CPUCAPACITY flag here for tmp level?

... and this then should be covered by the previous check in
wake_energy(), which sets want_energy.

> 
> > +                       energy_sd = tmp;
> > +
> >                 if (tmp->flags & sd_flag)
> >                         sd = tmp;
> >                 else if (!want_affine)
> > @@ -6586,6 +6652,8 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int wake_f
> >                         if (want_affine)
> >                                 current->recent_used_cpu = cpu;
> >                 }
> > +       } else if (energy_sd) {
> > +               new_cpu = find_energy_efficient_cpu(energy_sd, p, prev_cpu);
> 
> Even if want_affine = 0 (want_energy = 1), we can have sd = NULL if
> sd_flag and tmp->flags don't match. In this case we wont enter the EAS
> selection path because sd will be = NULL. So should you be setting sd
> = NULL explicitly if energy_sd != NULL , or rather do the if
> (energy_sd) before doing the if (!sd) ?

That's the same think I was also proposing in my reply to this patch.
But in my case the point was mainly to make the code easier to
follow... which at the end it's also to void all the consideration on
dependencies you describe above.

Joel, can you have a look at what I proposed... I was not entirely
sure that we miss some code paths doing it that way.

> If you still want to keep the logic this way, then probably you should
> also check if (tmp->flags & sd_flag) == true in the loop? That way
> energy_sd wont be set at all (Since we're basically saying we dont
> want to do wake up across this sd (in energy aware fashion in this
> case) if the domain flags don't watch the wake up sd_flag.
> 
> thanks,
> 
> - Joel

-- 
#include <best/regards.h>

Patrick Bellasi

  reply	other threads:[~2018-03-22 18:06 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
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 [this message]
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=20180322180623.GE13951@e110439-lin \
    --to=patrick.bellasi@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=peterz@infradead.org \
    --cc=quentin.perret@arm.com \
    --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