All of lore.kernel.org
 help / color / mirror / Atom feed
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!

  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.