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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 72F34CCD19A for ; Wed, 18 Sep 2024 11:17:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:Message-ID:In-Reply-To:Subject:cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Rl3Suv9Gr0inplGz8jcD4PSr30+237FWTUImYGXvpRo=; b=MHluCIvEUo5bmLzcdID61hHYJy mDQFtGA9FkBq5ItcuOThMzoq72LewmZkGtz5QY6sXS/Z3zNgxW979qJUnwJwA/WB/4f9xjuKLx6Sl 5St0HMr17NzdMnQnNhWlxz7STPUjZV1DtCpfyCZ3My1uF+s2iIEqZeRDIAyxj1CCDcT6geW3CkcUg mfvolj8XR+hkbhk5vNDYCdQ9RPU+5nC/K1tkrTjiytskAKd1OxVQSys4GtY4mtEEEGAq3Xw8fSSsM 4TRdjjK7FIY7HWdVsd076/oThFPRJMI8AE4+CsWxzh/Fkvah1u5QYLuAjX7iaKlHNW8+jBKvICBYn m7SBj+vg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1sqsfx-000000086xV-0Smp; Wed, 18 Sep 2024 11:16:49 +0000 Received: from gentwo.org ([62.72.0.81]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1sqseq-000000086oi-0kvr for linux-arm-kernel@lists.infradead.org; Wed, 18 Sep 2024 11:15:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gentwo.org; s=default; t=1726657424; bh=ZgUWGooFw76r+k5wBvmlHDduQIe0avoz9de+sDKki94=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=RnYf2xIjia8kxFaxgE5zNbG1A4jQohfdQhO9/HqyD7NHlSSZ+uqty1MGTQhdUUSnB 4+e7y0HXJ78In+FNkWr+1jUsmr10WlgqINk7f04CDnG+iUb19ZniyUC2k15r+u4xoO //LIPfjTRRkUHc71bLql/EdvKlGy+hUvgvnJAXII= Received: by gentwo.org (Postfix, from userid 1003) id 7D55D401CA; Wed, 18 Sep 2024 04:03:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 7C90A401C5; Wed, 18 Sep 2024 04:03:44 -0700 (PDT) Date: Wed, 18 Sep 2024 04:03:44 -0700 (PDT) From: "Christoph Lameter (Ampere)" To: Will Deacon cc: Thomas Gleixner , Catalin Marinas , Peter Zijlstra , Ingo Molnar , Waiman Long , Boqun Feng , Linus Torvalds , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org Subject: Re: [PATCH v3] Avoid memory barrier in read_seqcount() through load acquire In-Reply-To: <20240917071246.GA27290@willie-the-truck> Message-ID: <4b546151-d5e1-22a3-a6d5-167a82c5724d@gentwo.org> References: <20240912-seq_optimize-v3-1-8ee25e04dffa@gentwo.org> <20240917071246.GA27290@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240918_041540_262363_4B0A1797 X-CRM114-Status: GOOD ( 16.01 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 17 Sep 2024, Will Deacon wrote: > > +config ARCH_HAS_ACQUIRE_RELEASE > > + bool > > + help > > + Setting ARCH_HAS_ACQUIRE_RELEASE indicates that the architecture > > + supports load acquire and release. Typically these are more effective > > + than memory barriers. Code will prefer the use of load acquire and > > + store release over memory barriers if this option is enabled. > > + > > Unsurprisingly, I'd be in favour of making this unconditional rather than > adding a new Kconfig option. Would that actually hurt any architectures > where we care about the last few shreds of performance? Other arches do not have acquire / release and will create additional barriers in the fallback implementation of smp_load_acquire. So it needs to be an arch config option. > > + if (USE_COND_LOAD_ACQUIRE) > > + return smp_cond_load_acquire((unsigned int *)&s->sequence, (s->sequence & 1) == 0); > > This looks wrong to me. > > The conditional expression passed to smp_cond_load_acquire() should be > written in terms of 'VAL', otherwise you're introducing an additional > non-atomic access to the sequence counter. Hmmm... The compiler seems to have optimized that out. Will use VAL in next rollup.