All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Vincent Donnefort <vincent.donnefort@arm.com>,
	peterz@infradead.org, mingo@redhat.com,
	vincent.guittot@linaro.org
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 1/7] sched/fair: Provide u64 read for 32-bits arch helper
Date: Thu, 5 May 2022 20:25:56 +0200	[thread overview]
Message-ID: <251d4cd4-7a28-af7b-942e-4e9f762fc05f@arm.com> (raw)
In-Reply-To: <20220429141148.181816-2-vincent.donnefort@arm.com>

On 29/04/2022 16:11, Vincent Donnefort wrote:
> Introducing macro helpers u64_u32_{store,load}() to factorize lockless
> accesses to u64 variables for 32-bits architectures.
> 
> Users are for now cfs_rq.min_vruntime and sched_avg.last_update_time. To
> accommodate the later where the copy lies outside of the structure
> (cfs_rq.last_udpate_time_copy instead of sched_avg.last_update_time_copy),
> use the _copy() version of those helpers.
> 
> Those new helpers encapsulate smp_rmb() and smp_wmb() synchronization and
> therefore, have a small penalty in set_task_rq_fair() and init_cfs_rq().

... but obviously only on 32bit machines. And for set_task_rq_fair() we
now do one smp_rmb per cfs_rq (prev and next), like we do one smp_wmb()
per cfs_rq in update_cfs_rq_load_avg().

[...]

> @@ -3786,8 +3770,9 @@ update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq)
>  	decayed |= __update_load_avg_cfs_rq(now, cfs_rq);
>  
>  #ifndef CONFIG_64BIT

Can we not get rid of this last CONFIG_64BIT here?

> -	smp_wmb();
> -	cfs_rq->load_last_update_time_copy = sa->last_update_time;
> +	u64_u32_store_copy(sa->last_update_time,
> +			   cfs_rq->last_update_time_copy,
> +			   sa->last_update_time);

(sa->last_update_time = sa->last_update_time); should dissolve on 64bit.

>  #endif

[...]

Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>

  reply	other threads:[~2022-05-05 18:33 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 [this message]
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
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=251d4cd4-7a28-af7b-942e-4e9f762fc05f@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=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.