Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp986805ybg; Mon, 27 Jul 2020 05:07:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJydhMt7NaYKdFhP7HFz1QnH//cggtC8hLKvda9ZhYXZHAGE3nzYKnPHKIc69yhki8NfG6FN X-Received: by 2002:a05:6402:1687:: with SMTP id a7mr20606551edv.358.1595851632237; Mon, 27 Jul 2020 05:07:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595851632; cv=none; d=google.com; s=arc-20160816; b=KOvf5mnN9yw3P4UOTmThuMrQ2FdeUGcnlkx+UGaGi0l6rYQiF5M5vbVWhV862y/QMK RAypQba019HYFN46CgbDBbFbwrtthYqMiBebc2yXDZ+JG7XrKN2s2TEPXSSEGqajE7SC Xk+gLeFAfZ6jmDT2043xofxlQOJ+5ZZ3FtR5TMSB3z/XfZudVgMB0QFQ7T1mf4Im2Uni 6b+PG5fubSiVCAp3h0lqvrPG9WIff/gHLmaYSqcsi8YMYRE0TUTzbHKuh+VYH0Y7hkUE nKugFfewmlnHCmbKcbcH3NUCXFKZDjmCI3zING0+kuz54lc97C9t0TaPsRWmT6x6k2jY pV0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=fZ0sEPSaGxinA7qmh+bUkUq634pTh50QkEpizgUvX9o=; b=aUohNjbjY5BmNyRdY319+X9enVCsyEbiw+4Vffnuag51GNTRiS/GjJXDN6PwUV9KWn UyinDcHKOG18E2C9jddN9VvyimLCGZwLcqY0p4BNWfFQuVrhuKAgG5tZA13/tx76TKd0 G4gOu3mn1Hyk0QPdMB5xwpCa97aYCHClbwdEJYVfKw/zt+aF6LNFc+vaMRpV0YIdqL6A mV8Amch59urwyjid4IUkvUqVIybDwGxtMNQdyy44EOZ1pDbQl59QaQXC5FvQ8Wq6dtAe rBJokMHk8SsROBh65aF7AaJ3064lv6STJip++Ubj2VclUMLwkMSlV0hFI8U2zXVcWCY+ mIKA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d6si5482093edp.16.2020.07.27.05.06.49; Mon, 27 Jul 2020 05:07:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728281AbgG0MFa (ORCPT + 99 others); Mon, 27 Jul 2020 08:05:30 -0400 Received: from foss.arm.com ([217.140.110.172]:42832 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727978AbgG0MFa (ORCPT ); Mon, 27 Jul 2020 08:05:30 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2DDB230E; Mon, 27 Jul 2020 05:05:30 -0700 (PDT) Received: from e120877-lin.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 112FF3F66E; Mon, 27 Jul 2020 05:05:28 -0700 (PDT) Date: Mon, 27 Jul 2020 13:05:21 +0100 From: Vincent Donnefort To: Ingo Molnar Cc: mingo@redhat.com, peterz@infradead.org, vincent.guittot@linaro.org, linux-kernel@vger.kernel.org, dietmar.eggemann@arm.com, lukasz.luba@arm.com, valentin.schneider@arm.com Subject: Re: [PATCH] sched/fair: provide u64 read for 32-bits arch helper Message-ID: <20200727120520.GA257620@e120877-lin.cambridge.arm.com> References: <1595847564-239957-1-git-send-email-vincent.donnefort@arm.com> <20200727112454.GB55660@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200727112454.GB55660@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Mon, Jul 27, 2020 at 01:24:54PM +0200, Ingo Molnar wrote: > > * vincent.donnefort@arm.com wrote: > > > From: Vincent Donnefort > > > > Introducing two macro helpers u64_32read() and u64_32read_set_copy() to > > factorize the u64 vminruntime and last_update_time read on a 32-bits > > architecture. 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(). > > > > The choice of using a macro over an inline function is driven by the > > conditional u64 variable copy declarations. > > Could you please explain how "conditional u64 variable copy > declarations" prevents us to use an inline function for this I meant, as the "copy" variable [vminruntime|last_update_time]_copy, is declared only in the !CONFIG_64BIT case, a function call would fail when CONFIG_64BIT is set. u64_32read(cfs_rq->min_vruntime, cfs_rq->min_vruntime_copy); ^ not declared I could rephrase this part to something more understandable ? > > > +/* > > + * u64_32read() / u64_32read_set_copy() > > + * > > + * Use the copied u64 value to protect against data race. This is only > > + * applicable for 32-bits architectures. > > + */ > > +#if !defined(CONFIG_64BIT) && defined(CONFIG_SMP) > > +# define u64_32read(val, copy) \ > > +({ \ > > + u64 _val; \ > > + u64 _val_copy; \ > > + \ > > + do { \ > > + _val_copy = copy; \ > > + /* \ > > + * paired with u64_32read_set_copy, ordering access \ > > + * to val and copy. \ > > + */ \ > > + smp_rmb(); \ > > + _val = val; \ > > + } while (_val != _val_copy); \ > > + \ > > + _val; \ > > +}) > > +# define u64_32read_set_copy(val, copy) \ > > +do { \ > > + /* paired with u64_32read, ordering access to val and copy */ \ > > + smp_wmb(); \ > > + copy = val; \ > > +} while (0) > > +#else > > +# define u64_32read(val, copy) (val) > > +# define u64_32read_set_copy(val, copy) do { } while (0) > > +#endif > > + > > Thanks, > > Ingo -- Vincent