Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp3288839pxa; Tue, 18 Aug 2020 11:13:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEnobOFeZLJQQSFGgf707OIJ2KsaLRm98b/hxKY/tYS4GZldUFz+SroLiwqK7FmlwJG0we X-Received: by 2002:a17:906:82c1:: with SMTP id a1mr21026649ejy.172.1597774379819; Tue, 18 Aug 2020 11:12:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597774379; cv=none; d=google.com; s=arc-20160816; b=RyyBFy1u/jNFqLLBGv/ZsMh75ptOp1opjBXofdTf/hwLoYTfvHnTpO2S9Fm8QCi9X7 aK/NNld3+ODbivlr/6ZWFbCAcElURv1qMrQeNH5nJTRSP+d6Al4QTejfQO9u365b+NWV rSykLCZOr9K2l5F7Kn/Mf0peg7NVdXjlPEEwPGK8NIEUj7R8rtqh+gV7P+LycDF9GFBP OdM3SeX1SmSPdZRMMkuzVhr/TKmgO5w+3WgSOEqyGS3sE1tDmTyiisdcBdo5VkoWb4uY dUGd5hxCJmc/vWKFqlA28o5nGH3O8DxZQR0uCim+SPAVfkCzFjLXwR692y1Swk2kFmxM TBJQ== 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=k3bO0kBlUPiImNt/G3oSTbYYQ3hLN+aXNsiQKRaFOVE=; b=L383ml0LO1zheT2iAsW25aDraf+7DJEVUpTnSa6z65GCtK6nV7WQfKXNJj+96Xqbw3 T+PaWaYH53KCag1ZS3BquWCXfCBNv46FfrW9tbiRQJbJjQfmVJU/g1ALo4kxbI6IpVi5 ZFc3D0QFjc+IPLXmf5NQGytDgA+oAHgEDepIQnyCKvZSHqjgI91GhWRiuD64iB3vEmC5 5D0IiBDE1Wsm2XC4yd0O8PQmGcBCsHL9gE8auEnWy8F6o2ZaVdOK/ZxURiDL4LTBTvTG 53Fxb4sxeiaGv2zG7XigMfAAkSLU1VikH9UWkCYlTqF2phwj6tERBJOuTb1MIb2leOBK GP/Q== 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 gl17si13630653ejb.589.2020.08.18.11.12.35; Tue, 18 Aug 2020 11:12:59 -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 S1726702AbgHRSLd (ORCPT + 99 others); Tue, 18 Aug 2020 14:11:33 -0400 Received: from foss.arm.com ([217.140.110.172]:46846 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726435AbgHRSL3 (ORCPT ); Tue, 18 Aug 2020 14:11:29 -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 E336631B; Tue, 18 Aug 2020 11:11:28 -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 E2F913F6CF; Tue, 18 Aug 2020 11:11:27 -0700 (PDT) Date: Tue, 18 Aug 2020 19:11:20 +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: <20200818181120.GA297937@e120877-lin.cambridge.arm.com> References: <1595847564-239957-1-git-send-email-vincent.donnefort@arm.com> <20200727123801.GJ119549@hirez.programming.kicks-ass.net> <20200727152303.GA301827@e120877-lin.cambridge.arm.com> <20200728111302.GV119549@hirez.programming.kicks-ass.net> <20200728120027.GN43129@hirez.programming.kicks-ass.net> <20200728195320.GA426859@e120877-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200728195320.GA426859@e120877-lin.cambridge.arm.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 Peter, [...] > > > > > > How about something like: > > > > > > #ifdef CONFIG_64BIT > > > > > > #define DEFINE_U64_U32(name) u64 name > > > #define u64_u32_load(name) name > > > #define u64_u32_store(name, val)name = val > > > > > > #else > > > > > > #define DEFINE_U64_U32(name) \ > > > struct { \ > > > u64 name; \ > > > u64 name##_copy; \ > > > } > > > > > > #define u64_u32_load(name) \ > > > ({ \ > > > u64 val, copy; \ > > > do { \ > > > val = name; \ > > > smb_rmb(); \ > > > copy = name##_copy; \ > > > } while (val != copy); \ > > > > wrong order there; we should first read _copy and then the regular one > > of course. > > > > > val; > > > }) > > > > > > #define u64_u32_store(name, val) \ > > > do { \ > > > typeof(val) __val = (val); \ > > > name = __val; \ > > > smp_wmb(); \ > > > name##_copy = __val; \ > > > } while (0) > > > > > > #endif > > > > The other approach is making it a full type and inline functions I > > suppose. > > I didn't pick this approach originally, as I thought it would be way too > invasive. If the API looks way cleaner, it nonetheless doesn't match > last_update_time usage. The variable is declared in sched_avg while its copy > is in struct cfs_rq. > > Moving the copy in sched_avg would mean: > > * Setting the copy for all struct sched_avg in ___update_load_sum(), instead > of just the cfs_rq.avg in update_cfs_rq_load_avg(). > > * Having the DEFINE_U64_U32 declaration in include/linux/sched.h to cover > struct sched_avg. Gentle ping