public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vincent Donnefort <vdonnefort@google.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: peterz@infradead.org, mingo@redhat.com,
	linux-kernel@vger.kernel.org, dietmar.eggemann@arm.com,
	morten.rasmussen@arm.com, chris.redpath@arm.com,
	qperret@google.com, tao.zhou@linux.dev, kernel-team@android.com,
	Vincent Donnefort <vincent.donnefort@arm.com>
Subject: Re: [PATCH v9 6/7] sched/fair: Remove task_util from effective utilization in feec()
Date: Mon, 6 Jun 2022 10:41:36 +0100	[thread overview]
Message-ID: <Yp3L0EwERCp3iAYg@google.com> (raw)
In-Reply-To: <CAKfTPtA9qTCteP+VfR_9qnQkoxq=k3ACGrdPiKmc-sox0vXmgw@mail.gmail.com>

[...]

> > +
> > +/*
> > + * compute_energy(): Use the Energy Model to estimate the energy that @pd would
> > + * consume for a given utilization landscape @eenv. If @dst_cpu < 0 the task
> 
> I find this comment a bit confusing because compute_energy() adds the
> task contribution if dst_cpu >= 0 but doesn't remove it. The fact that
> eenv->pd_busy_time has been previously computed without the
> contribution of the task, is outside the scope of this this function
> whereas the comment suggest that the remove will happen in
> compute_energy()

Arg, leftover from a previous version where this function was adding or removing
the contribution. I'll update!

> 
> > + * contribution is removed from the energy estimation.
> > + */
> > +static inline unsigned long
> > +compute_energy(struct energy_env *eenv, struct perf_domain *pd,
> > +              struct cpumask *pd_cpus, struct task_struct *p, int dst_cpu)
> > +{
> > +       unsigned long max_util = eenv_pd_max_util(eenv, pd_cpus, p, dst_cpu);
> > +       unsigned long busy_time = eenv->pd_busy_time;
> > +
> > +       if (dst_cpu >= 0)
> > +               busy_time = min(eenv->pd_cap, busy_time + eenv->task_busy_time);
> > +
> > +       return em_cpu_energy(pd->em_pd, max_util, busy_time, eenv->cpu_cap);
> >  }
> >

[...]

> > @@ -6878,13 +6947,15 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
> >                 if (max_spare_cap_cpu < 0 && !compute_prev_delta)
> >                         continue;
> >
> > +               eenv_pd_busy_time(&eenv, cpus, p);
> >                 /* Compute the 'base' energy of the pd, without @p */
> > -               base_energy_pd = compute_energy(p, -1, cpus, pd);
> > +               base_energy_pd = compute_energy(&eenv, pd, cpus, p, -1);
> >                 base_energy += base_energy_pd;
> >
> >                 /* Evaluate the energy impact of using prev_cpu. */
> >                 if (compute_prev_delta) {
> > -                       prev_delta = compute_energy(p, prev_cpu, cpus, pd);
> > +                       prev_delta = compute_energy(&eenv, pd, cpus, p,
> > +                                                   prev_cpu);
> >                         if (prev_delta < base_energy_pd)
> 
> side question:
> -base_energy_pd is the energy for the perf domain without task p
> -prev_delta is the energy for the same perf domain if task p is put on dst_cpu
> 
> How can prev_delta be lower than base_energy ?

It can happen if one of the CPU utilization is updated in the middle of feec().

> 
> if dst_cpu doesn't belong to the perf domain, prev_delta should be
> equal to base_energy_pd
> if dst_cpu belongs to the perf domain, the compute_energy should be
> higher because the busy_time will be higher
> 
> >                                 goto unlock;
> >                         prev_delta -= base_energy_pd;
> > @@ -6893,8 +6964,8 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
> >
> >                 /* Evaluate the energy impact of using max_spare_cap_cpu. */
> >                 if (max_spare_cap_cpu >= 0) {
> > -                       cur_delta = compute_energy(p, max_spare_cap_cpu, cpus,
> > -                                                  pd);
> > +                       cur_delta = compute_energy(&eenv, pd, cpus, p,
> > +                                                  max_spare_cap_cpu);
> >                         if (cur_delta < base_energy_pd)
> 
> same question as above
> 
> >                                 goto unlock;
> >                         cur_delta -= base_energy_pd;
> > --
> > 2.36.1.124.g0e6072fb45-goog
> >

  reply	other threads:[~2022-06-06  9:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-23 15:51 [PATCH v9 0/7] feec() energy margin removal Vincent Donnefort
2022-05-23 15:51 ` [PATCH v9 1/7] sched/fair: Provide u64 read for 32-bits arch helper Vincent Donnefort
2022-05-23 15:51 ` [PATCH v9 2/7] sched/fair: Decay task PELT values during wakeup migration Vincent Donnefort
2022-05-30 16:31   ` Vincent Guittot
2022-05-31  8:16   ` Dietmar Eggemann
2022-06-06  9:31     ` Vincent Donnefort
2022-06-07  6:57       ` Vincent Guittot
2022-06-07 10:03         ` Vincent Donnefort
2022-06-07 10:19           ` Vincent Guittot
2022-05-23 15:51 ` [PATCH v9 3/7] sched, drivers: Remove max param from effective_cpu_util()/sched_cpu_util() Vincent Donnefort
2022-05-31  7:59   ` Vincent Guittot
2022-05-23 15:51 ` [PATCH v9 4/7] sched/fair: Rename select_idle_mask to select_rq_mask Vincent Donnefort
2022-06-02 13:07   ` Vincent Guittot
2022-05-23 15:51 ` [PATCH v9 5/7] sched/fair: Use the same cpumask per-PD throughout find_energy_efficient_cpu() Vincent Donnefort
2022-06-02 13:16   ` Vincent Guittot
2022-05-23 15:51 ` [PATCH v9 6/7] sched/fair: Remove task_util from effective utilization in feec() Vincent Donnefort
2022-05-31  8:17   ` Dietmar Eggemann
2022-06-06  9:32     ` Vincent Donnefort
2022-06-02 13:58   ` Vincent Guittot
2022-06-06  9:41     ` Vincent Donnefort [this message]
2022-06-07  6:59       ` Vincent Guittot
2022-05-23 15:51 ` [PATCH v9 7/7] sched/fair: Remove the energy margin " Vincent Donnefort

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=Yp3L0EwERCp3iAYg@google.com \
    --to=vdonnefort@google.com \
    --cc=chris.redpath@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=morten.rasmussen@arm.com \
    --cc=peterz@infradead.org \
    --cc=qperret@google.com \
    --cc=tao.zhou@linux.dev \
    --cc=vincent.donnefort@arm.com \
    --cc=vincent.guittot@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