From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751051AbcGMLTn (ORCPT ); Wed, 13 Jul 2016 07:19:43 -0400 Received: from foss.arm.com ([217.140.101.70]:36367 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750890AbcGMLTf (ORCPT ); Wed, 13 Jul 2016 07:19:35 -0400 Subject: Re: [PATCH v2 06/13] sched: Store maximum per-cpu capacity in root domain To: Peter Zijlstra 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> <20160712114258.GK30154@twins.programming.kicks-ass.net> Cc: Morten Rasmussen , mingo@redhat.com, yuyang.du@intel.com, vincent.guittot@linaro.org, mgalbraith@suse.de, linux-kernel@vger.kernel.org From: Dietmar Eggemann Message-ID: <578623A1.5040808@arm.com> Date: Wed, 13 Jul 2016 12:18:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160712114258.GK30154@twins.programming.kicks-ass.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/07/16 12:42, Peter Zijlstra wrote: > 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. > OK, thanks, will add them. So this maps to the point '(*) For aligned memory locations whose size allows them to be accessed with a single memory-reference instruction, prevents "load tearing" and "store tearing," ...' under 'The READ_ONCE() and WRITE_ONCE() functions can prevent any number of optimizations ...' section in the 'COMPILER BARRIER' paragraph in Documentation/memory-barriers.txt.