From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S933124AbcGLLnI (ORCPT <rfc822;w@1wt.eu>);
	Tue, 12 Jul 2016 07:43:08 -0400
Received: from bombadil.infradead.org ([198.137.202.9]:35330 "EHLO
	bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S933091AbcGLLnF (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 12 Jul 2016 07:43:05 -0400
Date: Tue, 12 Jul 2016 13:42:58 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>, mingo@redhat.com,
        yuyang.du@intel.com, vincent.guittot@linaro.org, mgalbraith@suse.de,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 06/13] sched: Store maximum per-cpu capacity in root
 domain
Message-ID: <20160712114258.GK30154@twins.programming.kicks-ass.net>
References: <1466615004-3503-1-git-send-email-morten.rasmussen@arm.com>
 <1466615004-3503-7-git-send-email-morten.rasmussen@arm.com>
 <20160711101832.GN30909@twins.programming.kicks-ass.net>
 <5783C646.5050606@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5783C646.5050606@arm.com>
User-Agent: Mutt/1.5.23.1 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Jul 11, 2016 at 05:16:06PM +0100, Dietmar Eggemann wrote:
> On 11/07/16 11:18, Peter Zijlstra wrote:
> > On Wed, Jun 22, 2016 at 06:03:17PM +0100, Morten Rasmussen wrote:
> >> @@ -6905,11 +6906,19 @@ static int build_sched_domains(const struct cpumask *cpu_map,
> >>  	/* Attach the domains */
> >>  	rcu_read_lock();
> >>  	for_each_cpu(i, cpu_map) {
> >> +		rq = cpu_rq(i);
> >>  		sd = *per_cpu_ptr(d.sd, i);
> >>  		cpu_attach_domain(sd, d.rd, i);
> >> +
> >> +		if (rq->cpu_capacity_orig > rq->rd->max_cpu_capacity)
> >> +			rq->rd->max_cpu_capacity = rq->cpu_capacity_orig;
> >>  	}
> > 
> > Should you not set that _before_ cpu_attach_domain(), such that the
> > state is up-to-date when its published?
> 
> yes, much better.
> 
> > Also, since its lockless, should we not use {READ,WRITE}_ONCE() with it?
> 
> You mean for rq->rd->max_cpu_capacity ? IMHO, there is a data dependency
> between the read and the write and the code only runs on one cpu.
> 
> I assume here that this is related to item 2 'Overlapping loads and
> stores within a particular CPU ...' in GUARANTEES of
> doc/Documentation/memory-barriers.txt.
> 
> Do I miss something?

Well, the value 'rd->max_cpu_capacity' is read by all CPUs attached to
the root_domain, right? So CPUs already attached can observe this change
when we update the value, we want them to observe either the old or the
new max value, not a random mix of bytes.

{READ,WRITE}_ONCE() ensure whole word load/store, iow they avoid
load/store-tearing.