linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: peterz@infradead.org, mingo@redhat.com,
	vincent.guittot@linaro.org, vdonnefort@gmail.com
Cc: linux-kernel@vger.kernel.org, morten.rasmussen@arm.com,
	chris.redpath@arm.com, qperret@google.com, tao.zhou@linux.dev
Subject: Re: [PATCH v8 2/7] sched/fair: Decay task PELT values during wakeup migration
Date: Thu, 5 May 2022 20:41:08 +0200	[thread overview]
Message-ID: <3899a404-8016-0f4f-58b8-9353d08db4c9@arm.com> (raw)
In-Reply-To: <20220429141148.181816-3-vincent.donnefort@arm.com>

+ vdonnefort@gmail.com
- vincent.donnefort@arm.com

On 29/04/2022 16:11, Vincent Donnefort wrote:

[...]

> To that end, we need sched_clock_cpu() but it is a costly function. Limit
> the usage to the case where the source CPU is idle as we know this is when
> the clock is having the biggest risk of being outdated. In this such case,
> let's call it cfs_idle_lag the delta time between the rq_clock_pelt value
> at rq idle and cfs_rq idle. And rq_idle_lag the delta between "now" and
> the rq_clock_pelt at rq idle.
> 
> The estimated PELT clock is then:

Where is this nice diagram (timeline) from v7 ?

[...]

> +	/*
> +	 * estimated "now" is:
> +	 *   last_update_time + (the cfs_rq's last_update_time)
> +	 *   cfs_idle_lag + (delta between cfs_rq's update and rq's update)
> +	 *   rq_idle_lag (delta between rq's update and now)

The parentheses here make this hard to get. Same text as in the patch
header. What would have speed up me understanding this would have been
this line:

         now = last_update_time + cfs_idle_lag + rq_idle_lag

> +	 *
> +	 *   last_update_time = cfs_rq_clock_pelt()
> +	 *                    = rq_clock_pelt() - cfs->throttled_clock_pelt_time
> +	 *
> +	 *   cfs_idle_lag = rq_clock_pelt()@rq_idle -
> +	 *                  rq_clock_pelt()@cfs_rq_idle
> +	 *
> +	 *   rq_idle_lag = sched_clock_cpu() - rq_clock()@rq_idle
> +	 *
> +	 *   The rq_clock_pelt() from last_update_time being the same as
> +	 *   rq_clock_pelt()@cfs_rq_idle, we can write:
> +	 *
> +	 *     now = rq_clock_pelt()@rq_idle - cfs->throttled_clock_pelt_time +
> +	 *           sched_clock_cpu() - rq_clock()@rq_idle
> +	 *
> +	 *   Where:
> +	 *      rq_clock_pelt()@rq_idle        is rq->clock_pelt_idle
> +	 *      rq_clock()@rq_idle             is rq->enter_idle
> +	 *      cfs->throttled_clock_pelt_time is cfs_rq->throttled_pelt_idle
> +	 */

[...]

> +#ifdef CONFIG_CFS_BANDWIDTH
> +static inline void update_idle_cfs_rq_clock_pelt(struct cfs_rq *cfs_rq)
>  {
> -	lockdep_assert_rq_held(rq);
> -	assert_clock_updated(rq);
> -
> -	return rq->clock_pelt - rq->lost_idle_time;
> +	/*
> +	 * Make sure that pending update of rq->clock_pelt_idle and
> +	 * rq->enter_idle are visible during update_blocked_average() before

s/update_blocked_average()/update_blocked_averages()

> +	 * updating cfs_rq->throttled_pelt_idle.
> +	 */
> +	smp_wmb();

I don't understand this one. Where is the counterpart barrier?

> +	if (unlikely(cfs_rq->throttle_count))
> +		u64_u32_store(cfs_rq->throttled_pelt_idle, U64_MAX);
> +	else
> +		u64_u32_store(cfs_rq->throttled_pelt_idle,
> +			      cfs_rq->throttled_clock_pelt_time);

Nit-pick:

Using a local u64 throttled might be easier on the eye:

        if (unlikely(cfs_rq->throttle_count))
-               u64_u32_store(cfs_rq->throttled_pelt_idle, U64_MAX);
+               throttled = U64_MAX;
        else
-               u64_u32_store(cfs_rq->throttled_pelt_idle,
-                             cfs_rq->throttled_clock_pelt_time);
+               throttled = cfs_rq->throttled_clock_pelt_time;
+
+       u64_u32_store(cfs_rq->throttled_pelt_idle, throttled);

[...]

  parent reply	other threads:[~2022-05-05 18:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-29 14:11 [PATCH v8 0/7] feec() energy margin removal Vincent Donnefort
2022-04-29 14:11 ` [PATCH v8 1/7] sched/fair: Provide u64 read for 32-bits arch helper Vincent Donnefort
2022-05-05 18:25   ` Dietmar Eggemann
2022-05-05 18:44     ` Dietmar Eggemann
2022-04-29 14:11 ` [PATCH v8 2/7] sched/fair: Decay task PELT values during wakeup migration Vincent Donnefort
2022-04-29 17:09   ` Tao Zhou
2022-05-06 13:58     ` Vincent Guittot
2022-05-05 18:41   ` Dietmar Eggemann [this message]
2022-04-29 14:11 ` [PATCH v8 3/7] sched, drivers: Remove max param from effective_cpu_util()/sched_cpu_util() Vincent Donnefort
2022-04-29 14:11 ` [PATCH v8 4/7] sched/fair: Rename select_idle_mask to select_rq_mask Vincent Donnefort
2022-04-29 14:11 ` [PATCH v8 5/7] sched/fair: Use the same cpumask per-PD throughout find_energy_efficient_cpu() Vincent Donnefort
2022-04-29 14:11 ` [PATCH v8 6/7] sched/fair: Remove task_util from effective utilization in feec() Vincent Donnefort
2022-05-05 18:41   ` Dietmar Eggemann
2022-04-29 14:11 ` [PATCH v8 7/7] sched/fair: Remove the energy margin " Vincent Donnefort
2022-05-05 18:42   ` 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=3899a404-8016-0f4f-58b8-9353d08db4c9@arm.com \
    --to=dietmar.eggemann@arm.com \
    --cc=chris.redpath@arm.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=vdonnefort@gmail.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;
as well as URLs for NNTP newsgroup(s).