From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-bc0f.mail.infomaniak.ch (smtp-bc0f.mail.infomaniak.ch [45.157.188.15]) (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 AC6E3380FD1 for ; Sun, 19 Jul 2026 17:50:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.157.188.15 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784483429; cv=none; b=EEvaEaQK6B5qW7H0ZXcUQsssE0u67ELBhREEk+Fd7x3YNdclOgBZs6eeswzZJkeSAk/BFCKnqkxOG5l/oqnKmcVW46DuU2zMidTfvoD9yOKM/sJj0SqnSiOOv+Fwf0Zmbn6Qs2ihdhklaToUPeR1HSbD2ui9Zk+SgPmahTZGZnk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784483429; c=relaxed/simple; bh=CgK7IvRxf3QPyJpb9n07JBZlc4fYKX+6CAGrsFf+HRs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pzy4nR/Uk7Bo7Ib3/Wy5znxFHw/aFO2J6U70d+zySYwd0fnpWiB2Uet9bRUhF6SaWltucEzRPu2vB7zyV/nfMVF1SQXXDILojroSlHEPADLDtGgHyHTEAGQiXlGA7zXjv44SRrIwQpnoA3iMfhuxkcmeHzh3FOwY8S1Yrc+qlH4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=ik.me; spf=pass smtp.mailfrom=ik.me; dkim=pass (1024-bit key) header.d=ik.me header.i=@ik.me header.b=d94GS9Wq; arc=none smtp.client-ip=45.157.188.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=ik.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ik.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ik.me header.i=@ik.me header.b="d94GS9Wq" Received: from smtp-4-0001.mail.infomaniak.ch (smtp-4-0001.mail.infomaniak.ch [10.7.10.108]) by smtp-4-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4h39fC4wm7zqXq; Sun, 19 Jul 2026 19:30:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ik.me; s=20200325; t=1784482243; bh=CgK7IvRxf3QPyJpb9n07JBZlc4fYKX+6CAGrsFf+HRs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=d94GS9WqCgEI36kwNvebR1DJQ296v1q57+j5IRMA8rsvjsh6+X8GHtI6OVRLX+8+h uHpr5z9GiOjEjF6vBtOEdTChSYJaBxAhVPhfzrQbsTUmQ9DiZv+Yo7TGdJHTlxZKPM LpqlJvE6J6jpggNkiFAToB7BvWl1ieqbpXp5dh3s= Received: from unknown by smtp-4-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4h39f903D7z7NC; Sun, 19 Jul 2026 19:30:40 +0200 (CEST) Date: Sun, 19 Jul 2026 19:30:39 +0200 From: Nadia Chambers To: Kiryl Shutsemau Cc: "David Hildenbrand (Arm)" , lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, x86@kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Lorenzo Stoakes , "Liam R. Howlett" , Mike Rapoport , Matthew Wilcox , Johannes Weiner , Usama Arif Subject: Re: [LSF/MM/BPF TOPIC] 64k (or 16k) base page size on x86 Message-ID: References: <915aafb3-d1ff-4ae9-8751-f78e333a1f5f@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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Feedback-ID: :e0199cdf3b76464:ham:b89b32586f6d122 X-Infomaniak-Routing: alpha On Thu, Feb 19, 2026 at 04:39:34PM +0100, David Hildenbrand (Arm) wrote: >> When discussing per-process page sizes with Ryan and Dev, I mentioned that >> having a larger emulated page size could be interesting for other >> architectures as well. >> That is, we would emulate a 64K page size on Intel for user space as well, >> but let the OS work with 4K pages. >> We'd only allocate+map large folios into user space + pagecache, but still >> allow for page tables etc. to not waste memory. >> So "most" of your allocations in the system would actually be at least 64k, >> reducing zone lock contention etc. Am Do, Feb 19, 2026 um 15:54:56 +0000, Kiryl Shutsemau schrieb: > I am not convinced emulation would help zone lock contention. I expect > contention to be higher if page allocator would see a mix of 4k and 64k > requests. It sounds like constant split/merge under the lock. Presumably because the higher-order allocations would lack the per-CPU special-case handling for order 0? IIRC LLFree is lock-free at all allocation orders, which would likely help the zone lock specifically. I suppose there's a sense I'm hoping my memory isn't out-of-date, but I would still be glad to see the improvement. Extending per-CPU freelists to small nonzero orders z.B. 4 might also help zone locks to allocate 64 KiB case likely around as much as using PAGE_MMUSHIFT == 4. On Thu, Feb 19, 2026 at 04:39:34PM +0100, David Hildenbrand (Arm) wrote: >> It doesn't solve all the problems you wanted to tackle on your list (e.g., >> "struct page" overhead, which will be sorted out by memdescs). Am Do, Feb 19, 2026 um 15:54:56 +0000, Kiryl Shutsemau schrieb: > I don't think we can serve 1G pages out of buddy allocator with 4k > order-0. And without it, I don't see how to get to a viable 1G THPs. memdescs are too recent for me to know about, but there is a comment to make about 1 GiB superpages: doubly exponential decays in availability are going to overwhelm the effects of any reasonable valud of PAGE_MMUSHIFT (your ilog(PG_SIZE/PTE_SIZE) which has no macro for it) long before 1 GiB. Bumping a small constant off the grand total of allocation orders isn't going to be an adequate strategy. ISTR Rik van Riel had code going round to partition RAM into something akin to pre-formed large z.B. 1 GiB superpages that's a far more meaningful approach to 1 GiB superpages than reducing the allocation order for 1 GiB from 18 to 14 or 12. The double exponential makes orders above maybe 2 or 3 require migration or compaction and there's a cut-off above which you're going to need to be either be fresh off a virgin boot or to do something slow bordering on swsusp-style mass eviction. If memdescs, presumably from „memory descriptors“, are something like memory extents, I wholeheartedly endorse moves to more extent-based or extent-like memory management and can quibble about the details later. You can make an argument that scaling may need to take special steps to reduce the TLB entries for the smallest page sizes so they don't outcompete the real datasets when they proliferate. But buddy allocating (LLFree should be used instead) isn't going to be appreciably any better at orders 14 (PAGE_MMUSHIFT == 4) or 12 (PAGE_MMUSHIFT == 6) than 18, as with double exponential decays, it dropped to effectively zero onf. vmtl. 5 or 6, and values of PAGE_SIZE much larger than 64-256 KiB would likely require far more extensive efforts to address regressions driven by bitblitting latency and internal fragmentation than simple things like tail packing the page cache. If you're starting from an MMUPAGE_SIZE/PTE_SIZE of 64 KiB z.B. ppc64, it only really changes the story to cutting 14 to 10 or 8, but the net result of that with PAGE_MMUSHIFT == 4 is a PAGE_SIZE of 1 MiB and for PAGE_MMUSHIFT == 6 of 4 MiB, which are clearly beyond the pale of what'll be tolerable for insb. network latencies for high-performance scenarios. There is a case where those handfuls of buddy bitmap orders makes a difference: if you're trying to split the difference between z.B. the MMUPAGE_SHIFT/ilog2(PTE_SIZE) and PMD_SHIFT. That's not reaching 1 GiB, though. That's the only real benefit possible to offer in the trivial case of the sparse page size spectrum. Dense page size spectra like MIPS, LoongArch, RISC-V Svnapot, and Fujitsu M12 SPARC (I presume IA64 has sadly been completely discontinued at this point) are more of where the benefits an argument can be made for are concentrated. In the desperation of the sparse page size spectrum case z.B. x86 page size growth increment / Sprungweite of 9 or some Apple M5 ARM systems' 11, trimming orders off of it might be worth it even after something in the vein of Rik's large superpage / „huge page“ -sized arenas, but with some devoted to the first superpage size as that's too many orders off from MMUPAGE_SIZE for naïve handling to work well. To be clear, I am in favour of page clustering as per your pte_size, Andrea's hard-page-size, my pgcl (not genuinely distinct from Hugh's except via my being a far lesser coder than he), and Hugh's larpage. My objection is that the rationale you've given isn't sustainable. -- nyc