All of lore.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 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.