From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8EA2D3E959C for ; Wed, 5 Aug 2026 08:16:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785917813; cv=none; b=gezaBzZJzlLNj55O6TkuP2eapVLUQBStapHwTLj/nBPV8KDzL2byfvL95zWP6+UvcvnQUKAugOufEJ7RyJr+AWW6jDBAeJnw9QD3xfB7Qa7mh2oAMKNLXx23nQNmk7AXkOUy/T3ORaVJYfcwYrEBTmlQzQ79kDIDXxjxueiixvA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785917813; c=relaxed/simple; bh=GmYyrdZe1B0PBpV7nWZEHOZ78x8Fhml0/nyFckT8Q5U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SuaA3gz4IjmQdxpEb6GkvGAsOlpsmIH+pfCPhEwU/q4Er26BYULS4fjxKfOgKpGunbacKw8g26xRYKLB3bm+IBCUc/YtYQpeCo+zPieU+t0fz4uBk9l5/TNzw+V8wPLmB5lV0vD5SjXbMvBnadofadnQRp2kBV37zZjgXVxhkeo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=T1dfoJYr; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="T1dfoJYr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6B6411F000E9; Wed, 5 Aug 2026 08:16:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785917809; bh=GmYyrdZe1B0PBpV7nWZEHOZ78x8Fhml0/nyFckT8Q5U=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=T1dfoJYrP3ggTDguqaQhaDmZLHe3mJjru4jCT/1ANuiGL1fot3+s/dHfHfhjYoyEX Y/aoGoTTs2LxtCJHGd5OZv4Owb8anEX7nZ58Cgw3J9H/zzQiBn6w/oiPjSeGxP3u+E mYDuXnJmHjwfW6tfBp1xS0WGTKuLh8ZX8Yh8rSfPMcpsINud33uvR4MdiF0syKhk7T utgpQXaaxlwgXTCPSMKCC9+pkhuX90w61xunWQsdzZiRliIxSsrtcJDlhjr4Ykn/nQ XHnITQrz2tNu+rbNWvGoQt9hshksDufbzvK3Orz/AFL06/C0FFAzaDTVmR0YTcEHVn UuniWlaO51HGw== Date: Wed, 5 Aug 2026 09:16:30 +0100 From: "Lorenzo Stoakes (ARM)" To: "Christoph Lameter (Ampere)" Cc: Linus Torvalds , "David Hildenbrand (Arm)" , Mark Rutland , Yang Shi , Ryan Roberts , dennis@kernel.org, tj@kernel.org, urezki@gmail.com, catalin.marinas@arm.com, will@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, Jason Gunthorpe Subject: Re: [RFC v2 PATCH 0/16] Optimize this_cpu_*() ops for non-x86 (ARM64 for this series) Message-ID: References: <25d1e09b-53e4-7cd5-87db-b58437e4e690@gentwo.org> <4887267b-dc26-4c33-96ca-8dff054a0d1f@kernel.org> <8d6119c7-2216-fcdd-d0b9-cc60ccc8caf3@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: <8d6119c7-2216-fcdd-d0b9-cc60ccc8caf3@gentwo.org> On Tue, Aug 04, 2026 at 02:40:27PM -0700, Christoph Lameter (Ampere) wrote: > On Tue, 4 Aug 2026, Lorenzo Stoakes (ARM) wrote: > > > On Tue, Aug 04, 2026 at 10:01:45AM -0700, Linus Torvalds wrote: > > > So I'm just trying to clarify my stance - I don't hate percpu TLB > > > contents per se. I hate the notion of codifying them. > > > > I do worry that changing per-CPU data structures to support this is exactly > > codifying this (and will encourage other arches to follow suit). > > > > And I really don't think there's any way to implement this without > > fundamentally changing core mm or assumptions that core mm can make. > > Would it be possible to discuss the technical issues instead of throwing > up this and that foggy objection? Lets not get into the complexities of Christoph this is very unhelpful. I and other maintainers have raised _specific_ and _technical_ objections. If you are having comprehension issues it'd be more constructive to ask questions. It's really simple - convince us or the series doesn't go upstream. > > The fundamental problem is that your patchset does > > > > RMV per cpu op > > > > What x86 does and what we can get ARM to do is: > > RMW per cpu op > Why do you think that your solution that requires a complex restart > mechanism is better? > > > These are operations that are key to the performance in critical parts of > memory management and this code is replicated by being inlined thousands > of times in the kernel. I mean this is just silly :) Provide data to back any of this, and no your benchmarks of your approach vs. nothing isn't it, nor do they demonstrate anything about what you claim here. You've been asked for this multiple times now. (And please no hand waving about 'critical parts of mm'. Be specific please.) > > -- Cheers, Lorenzo