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 8BADB322527 for ; Thu, 6 Aug 2026 17:32:16 +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=1786037537; cv=none; b=mYgeY1F9lItba4FUy7ofGSxCum5w+xv3rIA2ZndUso1w06Ex3DDLs2XRDMW3MJMkU7STydTWrtWef1R30cg7qk0xPvJDAGcb1FTOJai9xalfWSvkpjH8fo7G9gawXgNfLVFYcnQqxUzO5Lj4GZ4QREerSAg7k1KWzS/9vkwKcbY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786037537; c=relaxed/simple; bh=7J5Tb1/e7+0o2iMfnVQiLZsqKhQzq+Tx+/PZqWQZOR4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ikNYI+dJPCwo5VbqBosoTZgafDbn3AAdXV8GR+AQo69nj2Q38frgbeGCR6DCKaeqvwynx0NRiKmahI3hFe7jxybgRlWZRIx4Qk9K3aNDwuO/eQ0bOriJQyGXEGO0Zpyw5u/pXNy7eKYFHnoPTl3uoRC+X7eV3naSXsD5dpKPWt4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HqKGBGIc; 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="HqKGBGIc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA1B81F000E9; Thu, 6 Aug 2026 17:32:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786037536; bh=7J5Tb1/e7+0o2iMfnVQiLZsqKhQzq+Tx+/PZqWQZOR4=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=HqKGBGIcEZ/+U514vL1iPOo9QBRMCr2ok62HCPSwILHjFBf/AR08b6mSqHDEjaeFN KutUxL79UxG002+LReaU0p1yGFhFC7M+yh/1MiQaeXZdBlS7PYjI0H9tHz+pQiATs5 4NoJXbGzZ7yUsQOYaynFGTV4ABINw+XLGwBubFYe2XKsem9mQPQWlIPZT1GdujLy5t 7sHUYsGGPpe20Hy4TMB7iE0OeCoue33lT9XHHBFBGyEYLevj+gtt3a0KpySvREVXv9 EayAToVMPG7VDJ1NUebZQUOCdl8yYL3evrEWKLlclZumx0v+dIeuzQS1yy4ri8AhTN P9P8EQTM+ATwg== Date: Thu, 6 Aug 2026 18:31:57 +0100 From: "Lorenzo Stoakes (ARM)" To: Will Deacon Cc: Linus Torvalds , "Christoph Lameter (Ampere)" , "David Hildenbrand (Arm)" , Mark Rutland , Yang Shi , Ryan Roberts , dennis@kernel.org, tj@kernel.org, urezki@gmail.com, catalin.marinas@arm.com, 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> 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: On Thu, Aug 06, 2026 at 06:15:35PM +0100, Will Deacon wrote: > So the nice thing about having two implementations (i.e. the per-cpu > page-tables *and* the preemption stuff from Mark) is that we can pitch > them against each other to help us make a decision. Yes exactly :) This point has been put to the submitters a number of times so I hope that an additional repetition from an arm64 maintainer helps underline it. > > However, I don't see how anybody could argue that Mark's series isn't > cleaner and easier to maintain. I completely agree. > I've seen it described as "hacky" but I > can't tell whether or not that's supposed to be a criticism. If we Allow me to translate: 'I want to ignore this' :) Similarly the comment about mm maintainers wanting maintainable not-broken code being a 'foggy' position. Translation: 'I want to ignore this'. Since maintainers decide what gets merged the translation gets flipped if the submitters fail to address the feedback. Let's hope sanity prevails. > seriously want to consider the per-cpu page-table approach on arm64, the > numbers need to be _really_ good and across a variety of hardware, not > just the stuff with a memory system made of baling twine. That extends > to the kernel text replication efforts too. Thanks, and equally so for the core mm changes that are required by the page table approach (that requirement being attested to by the diffstat). > > Will -- Cheers, Lorenzo