Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp1120805ybg; Mon, 27 Jul 2020 08:24:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw9v9KiD8NCgns8aRQLN8o7TITFJDJUMh27s7mXc0P+p1YGMXx9LiIrcs8rLlEDJFGxWMS9 X-Received: by 2002:a17:906:ca11:: with SMTP id jt17mr2079381ejb.148.1595863453314; Mon, 27 Jul 2020 08:24:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595863453; cv=none; d=google.com; s=arc-20160816; b=WPvuR692OSsGe34dzKz53g1/dK6XiiKfAPqt22/Oy5Ov4/HoCXedbmeTKmJUcIdBNC PRLXwuKjy7nf3g31Ogi9KZZz55Kk8FFtWoW9peDq/NtNR9q66g2iEjR/S4+16oHkJNIV uD8AsAo7xlXPVxPObzY2o6NG6uXeUAr3XJkmN/mIC8QZDyTwWZm+PD9dwRoBzLRJ4CYN KLBB2pPOrsZo9truo7h0VptH0YwBP+9pdmi/6uPG4ftVWvzijwdEXNkiml2MWTZC0ttZ COMfqTlbdL8EnTn0H/WA29FN4FfjV8H5pGcUKq13jGe7B8lZaVXp5UJnlBLVarKddc5I DhZQ== 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=U6YmzLvD55tp2Mq3KBfRX3afsq1F2RBxs6jcyVXCZEs=; b=S3m3SXXR98twntPfm1wwhy2jM0gp4kLhI626HAJr3O9honDpBwRhMf3LdLPcG7HF8L xRmIIr6VZnmzdl8C0De66+sRJpzOqcpIo/g6+Q6N+vHxNINuu1Ir0dHkiScQEPzKOYYP glPsJ6y2902mdqiYAQoPXTiUg1PIcYA4eCUYPnAZbrQ2H8O52hc8fBR6kVGNtT/koslO 7u3VwV2k7j2aq9jJHoX9KIjw7HxwPdk6JsrrpUdsUF/UoPuTz6nHA8xhpvhnPsMJsA0V yfzr0/l+d2E4+vV3sNl51jCDPn1MSju1MHQHpcdtMmmF82h5yEz+EbhWD/+bKZeQdun4 4dwQ== 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 b13si5676647ejp.499.2020.07.27.08.23.50; Mon, 27 Jul 2020 08:24:13 -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 S1730095AbgG0PXL (ORCPT + 99 others); Mon, 27 Jul 2020 11:23:11 -0400 Received: from foss.arm.com ([217.140.110.172]:46718 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727938AbgG0PXL (ORCPT ); Mon, 27 Jul 2020 11:23:11 -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 96F94D6E; Mon, 27 Jul 2020 08:23:10 -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 970BB3F718; Mon, 27 Jul 2020 08:23:09 -0700 (PDT) Date: Mon, 27 Jul 2020 16:23:03 +0100 From: Vincent Donnefort To: peterz@infradead.org Cc: mingo@redhat.com, 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: <20200727152303.GA301827@e120877-lin.cambridge.arm.com> References: <1595847564-239957-1-git-send-email-vincent.donnefort@arm.com> <20200727123801.GJ119549@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200727123801.GJ119549@hirez.programming.kicks-ass.net> 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 On Mon, Jul 27, 2020 at 02:38:01PM +0200, peterz@infradead.org wrote: > On Mon, Jul 27, 2020 at 11:59:24AM +0100, 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. > > > > #ifndef CONFIG_64BIT > > u64 [vminruntime|last_update_time]_copy; > > #endif > > This lacks a *why*... why did you get up this morning and wrote us this > patch. > > For 32-bit architectures, both min_vruntime and last_update_time are using similar access. This patch is simply an attempt to unify their usage by introducing two macros to rely on when accessing those. At the same time, it brings a comment regarding the barriers usage, as per the kernel policy. So overall this is just a clean-up without any functional changes. -- Vincent.