From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id AE69B38F63D for ; Wed, 5 Aug 2026 14:53:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785941617; cv=none; b=iwK9qSbvVCmBQRwZ72OqlDdHksCQ6S5aWTvRPTATeqvidFNW3smafCuv/zpxAXyNTePYZ09mASGlAncy/5DZ+EzpfUcMBRFMsjVA1pjwbiuW5wV5azBubLV640dJ1FDK9WExSR7hSSzTtexTtTB8RHP/G3z/RDmC1+0u7ve4z4Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785941617; c=relaxed/simple; bh=K0NMuw1cdB8mhCo22y55f2vhoceFHsGS1XGjNj01RFk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IPfTlL1+xSbxHFOnToP6MvBd2D3h4q07/J8UKfBZpwIL5GTuVIkaomlrEE12aR/i3HAyfU5Q1FLh9VkDZgl7BoovT2u3+3d3mn3E3Fsi1i0Jx0zrzLMs3kY//zYMHYsrkqKbHe84jFev740nc63OB00TLHEeIrCU7PsdMYR2EoM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=XgANokC1; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="XgANokC1" 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 D705F153B; Wed, 5 Aug 2026 07:53:28 -0700 (PDT) Received: from J2N7QTR9R3 (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8A06C3F632; Wed, 5 Aug 2026 07:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1785941612; bh=K0NMuw1cdB8mhCo22y55f2vhoceFHsGS1XGjNj01RFk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XgANokC1wy/pXB+aYJ4f7KYRB1lAKM4KkLXZvORJwCDGWcBvspQ5D2OkQ0mEdzGOw IfCn2OXVY2KnBju9YVSjsvw24cmBPBpNC0hQn/mS+3lJWMJys3O8g7ZXwNRoex59zK a9PT5dHCKKnOQwWU2QAJ6XszSUhjjlD/4dkCiI3A= Date: Wed, 5 Aug 2026 15:53:28 +0100 From: Mark Rutland To: "Christoph Lameter (Ampere)" Cc: Yang Shi , Ryan Roberts , dennis@kernel.org, tj@kernel.org, urezki@gmail.com, catalin.marinas@arm.com, will@kernel.org, david@kernel.org, akpm@linux-foundation.org, hca@linux.ibm.com, gor@linux.ibm.com, agordeev@linux.ibm.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [RFC v2 PATCH 0/16] Optimize this_cpu_*() ops for non-x86 (ARM64 for this series) Message-ID: References: <20260715180455.515692-1-yang@os.amperecomputing.com> <0344c559-1959-4531-9265-d5a5180eb7cd@arm.com> <25d1e09b-53e4-7cd5-87db-b58437e4e690@gentwo.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25d1e09b-53e4-7cd5-87db-b58437e4e690@gentwo.org> On Mon, Jul 27, 2026 at 03:06:27PM -0700, Christoph Lameter (Ampere) wrote: > On Wed, 22 Jul 2026, Mark Rutland wrote: > > I expect that should come with a reasonable benefit, but I don't have > > benchmark figures yet as I haven't finished converting the xchg and > > cmpxchg implementations. > > > > > It sounds like it just moved the cost from one place to the other > > > place and it also seems hacky TBH. > > Yang Shi's patch has *no* critical section. There is no additional code > for the RMV instruction. The RMV instruction is executed on the correct > per cpu area. None of that was in question. > One of the reasons for the performance win is the > eliminattion of these critical sections. Your approach still has some form > of prologue and posthandling like the current preempt approach and > therefore will not be able to have the same performance gains. In absolute terms, yes. However, I'm fairly confident that the vast majority of the overhead we have today can be eliminated with simpler alternatives. There is a trade-off, and there are surprisingly complex interactions between page tables and other things (e.g. entry code). There is risk and maintenance burden associated with that. Hence people want to understand how much of the benefit is attributable to what. So far, the statements haven't convinced me people actually know what portion of the overhead come from which factor, e.g. * How much of that attributable to conditional work when re-enabling preemption? * How much of that is attributable to RMW sequences to modify the preempt count itself? * How much of that is attributable to system register accesses (SP_EL0 and TPIDR_ELx)? Any of those could easily dominate the other factors and might easily be avoidable. Most of that should be measurable today. For example you could restore the preempt_{enable,disable} calls atop Yang Shi's patches. > The code is more efficient, there is no restart necessary and the > technique is already widely used on x86 for a long time. It's true that the per-cpu page table approach will have fewer instructions in the fast path. However, the other statements here are potentially misleading: (1) There is no restart in the scheme I have proposed, so restarting is irrelevant to the comparison. (2) On x86, this_cpu*() operations use segment relative addressing, NOT per-cpu page tables. If arm64 had a similar addressing scheme, I expect we would use it. (3) There are a number of novel problems associated with per-cpu page tables (e.g the various unsolved issues Yang has described), which do not apply to x86's implementation of this_cpu_*() operations. > Having the ability in general to map mmemory differently depending on the > cpu opens up a number of other optimization like > What we are proposing here is a basic new feature that simplifies code and > allows addititonal performance and functional features that are so far not > possible on ARM64. While this simplifies the this_cpu_*() operations, I don't believe this is a simplification overall, and IMO, describing it as such is misleading. Mark.