From: Vincent Donnefort <vdonnefort@google.com>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: peterz@infradead.org, mingo@redhat.com,
vincent.guittot@linaro.org, linux-kernel@vger.kernel.org,
morten.rasmussen@arm.com, chris.redpath@arm.com,
qperret@google.com, tao.zhou@linux.dev, kernel-team@android.com
Subject: Re: [PATCH v9 2/7] sched/fair: Decay task PELT values during wakeup migration
Date: Mon, 6 Jun 2022 10:31:16 +0100 [thread overview]
Message-ID: <Yp3JZIokwFxT+X6M@google.com> (raw)
In-Reply-To: <72bd6945-c167-65ba-6f81-fad2768972dc@arm.com>
[...]
> > @@ -8114,6 +8212,10 @@ static bool __update_blocked_fair(struct rq *rq, bool *done)
> > if (update_cfs_rq_load_avg(cfs_rq_clock_pelt(cfs_rq), cfs_rq)) {
> > update_tg_load_avg(cfs_rq);
> >
> > + /* sync clock_pelt_idle with last update */
>
> update_idle_cfs_rq_clock_pelt() syncs cfs_rq->throttled_pelt_idle with
> cfs_rq->throttled_clock_pelt_time. Not sure what `clock_pelt_idle` and
> `last update` here mean?
Indeed, this comment is not helpful at all. What matters here is that the cfs_rq
is idle and we need to update the throttled_pelt_idle accordingly.
>
> [...]
>
> > +/* The rq is idle, we can sync to clock_task */
> > +static inline void _update_idle_rq_clock_pelt(struct rq *rq)
> > +{
> > + rq->clock_pelt = rq_clock_task(rq);
> > +
> > + u64_u32_store(rq->enter_idle, rq_clock(rq));
> > + /* Paired with smp_rmb in migrate_se_pelt_lag */
>
> minor:
>
> s/migrate_se_pelt_lag/migrate_se_pelt_lag()
>
> [...]
>
> > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> > index bf4a0ec98678..97bc26e5c8af 100644
> > --- a/kernel/sched/sched.h
> > +++ b/kernel/sched/sched.h
> > @@ -648,6 +648,10 @@ struct cfs_rq {
> > int runtime_enabled;
> > s64 runtime_remaining;
> >
> > + u64 throttled_pelt_idle;
> > +#ifndef CONFIG_64BIT
> > + u64 throttled_pelt_idle_copy;
> > +#endif
> > u64 throttled_clock;
> > u64 throttled_clock_pelt;
> > u64 throttled_clock_pelt_time;
> > @@ -1020,6 +1024,12 @@ struct rq {
> > u64 clock_task ____cacheline_aligned;
> > u64 clock_pelt;
> > unsigned long lost_idle_time;
> > + u64 clock_pelt_idle;
> > + u64 enter_idle;
> > +#ifndef CONFIG_64BIT
> > + u64 clock_pelt_idle_copy;
> > + u64 enter_idle_copy;
> > +#endif
> >
> > atomic_t nr_iowait;
>
> `throttled_pelt_idle`, `clock_pelt_idle` and `enter_idle` are clock
> snapshots when cfs_rq resp. rq go idle. But the naming does not really
> show this relation. And this makes reading those equations rather difficult.
>
> What about something like `throttled_clock_pelt_time_enter_idle`,
> `clock_pelt_enter_idle`, `clock_enter_idle`? Especially the first one is
> too long but something which shows that those are clock snapshots when
> enter idle would IMHO augment readability in migrate_se_pelt_lag().
What if I drop the "enter"?
clock_idle;
clock_pelt_idle;
throttled_clock_pelt_time_idle;
>
> Besides these small issues:
>
> Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Thanks!
next prev parent reply other threads:[~2022-06-06 9:31 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 [this message]
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
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=Yp3JZIokwFxT+X6M@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.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.