From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 38B7CC61DD8 for ; Mon, 16 Nov 2020 17:43:32 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D8A0720B80 for ; Mon, 16 Nov 2020 17:43:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ZmEltqhK"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="PqmyS1s6" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D8A0720B80 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=r2HxsTN3oJ9TxNhcFv+YGdhFFG2Ji5XrJAveODmWcCo=; b=ZmEltqhKBd2y8rqqWG5x/RtfH GiTwHwsnsRfBASLeHm+QByt2J8c/f9v0Phcq3qPuK0J3olW0DfoOLAavsO4VtVSniR+JvCBAUiNL/ thcF2U4R5z/ea98J80UaowdPZH7JLvw0+afQcWuBINVjAOG95A8CV9Z1jyhOWd3km6YYjUet7eV2d GIJqyONMsKAYav2Jd25aikme1SpCxkq07JWU88TbPVi/LhcTCDVOwjgHOVZzTK8H0YU6wufYP+9eh rqz2MD6TGV3npJylCiyzUyMcmR0Pi+nfWCcG8I7sAS/EoTaCQsOzSOiQEztdfB29kBCvcluElX/Rr y/z3xm+zw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1keiVf-00044C-I9; Mon, 16 Nov 2020 17:41:47 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1keiVJ-0003vP-6a for linux-arm-kernel@lists.infradead.org; Mon, 16 Nov 2020 17:41:28 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8ED0620575; Mon, 16 Nov 2020 17:41:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605548484; bh=BUdpGhQR6uvQ1UiDPnz3BIXkl0WyChUt637AGhwILLU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PqmyS1s6Xkb7owRE7Xh7P+XzYqPQ0k/xDZnr3WzJCMvp8brRHsGn4Wfl3rf1RfId1 N7HzSdqDZ6lrzKe1zmYv/R7PkeWA7zJ6YKVIB6TJiHT2D10rxyGsjjYhJjtIuy3v0m 24wvqkbaYM6SorYbYhP3MylRUHPtj65YdjjRhd+I= Date: Mon, 16 Nov 2020 17:41:20 +0000 From: Will Deacon To: Mel Gorman Subject: Re: Loadavg accounting error on arm64 Message-ID: <20201116174119.GB30723@willie-the-truck> References: <20201116091054.GL3371@techsingularity.net> <20201116114938.GN3371@techsingularity.net> <20201116125355.GB3121392@hirez.programming.kicks-ass.net> <20201116125803.GB3121429@hirez.programming.kicks-ass.net> <20201116152946.GR3371@techsingularity.net> <20201116164928.GF3121392@hirez.programming.kicks-ass.net> <20201116172444.GV3371@techsingularity.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201116172444.GV3371@techsingularity.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201116_124125_429869_C9A84332 X-CRM114-Status: GOOD ( 21.46 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Zijlstra , Davidlohr Bueso , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Nov 16, 2020 at 05:24:44PM +0000, Mel Gorman wrote: > On Mon, Nov 16, 2020 at 05:49:28PM +0100, Peter Zijlstra wrote: > > > So while we might be able to avoid a smp_rmb() before the read of > > > sched_contributes_to_load and rely on p->on_cpu ordering there, > > > we may still need a smp_wmb() after nr_interruptible() increments > > > instead of waiting until the smp_store_release() is hit while a task > > > is scheduling. That would be a real memory barrier on arm64 and a plain > > > compiler barrier on x86-64. > > > > Wish I read this before sending the changelog > > > I'm mighty confused by your words here; and the patch below. What actual > > scenario are you worried about? > > > > The wrong one apparently. Even if the IRQ is released, the IPI would > deliver to the CPU that should observe the correct value or take the > other path when smp_cond_load_acquire(&p->on_cpu, !VAL) waits for the > schedule to finish so I'm now both confused and wondering why smp_wmb > made a difference at all. Probably still worth trying Peter's hack to pad the bitfields though, as I think that's still a plausible issue (and one which would appear to be fixed by that smp_wmb() too). Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel