From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-8fa8.mail.infomaniak.ch (smtp-8fa8.mail.infomaniak.ch [83.166.143.168]) (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 1103B37F725 for ; Sun, 19 Jul 2026 23:05:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=83.166.143.168 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784502349; cv=none; b=Uc+kxWvZTniNXQbgD1zsMI+veLmFy44dKnMh/6sYUk4r2/FHARSU6GJajsJOy57wfbTCD/ialDbpcHM8VmyRj2YGiHAekciKnE52CQSdlO1qoEzMh0WG1NFwchqD4GixtGYGZNeOxqjBNb4ttKc7XY+Cf3gOQlY56g2ClOfIAaU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784502349; c=relaxed/simple; bh=mPBo6hJUeLj7jcxzrx74mFiZQyq4qQJsY4/vfxq5mZ4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hmRan/z6Z7cfohLOt14rfvMF+cTKdMZjZpYm83Bn64i+pP6veWGaOxd4Ymo5JlRgiQA/DxwjPZuBWaGPP+773SND3RSb5RvnrQEaytj2zFYS/lWljkRGW1Gelwoeaufa3vzZhQHGxOa035iiI4P4q3Jix3bBhc3j/e9oN6dvBoc= 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=ylRpRYNj; arc=none smtp.client-ip=83.166.143.168 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="ylRpRYNj" Received: from smtp-3-0001.mail.infomaniak.ch (unknown [IPv6:2001:1600:4:17::246c]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4h3JyG6B7MzTjN; Mon, 20 Jul 2026 01:00:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ik.me; s=20200325; t=1784502006; bh=aJBl0FdlICAYYYTQiV3xnuCWcw9phxxvhoXrl3+SMO4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ylRpRYNjVv7knoKzC2KLAQeA7Zr2FDlpf2PXLOw1I7QIbpLRcRFLtHfWc5Wq25lMr 1oRhPqNIX0syzyOEQz+J7YD4lfs7L5eyEa3iqD2kVCcs6cJCIyxU35+l4XKPxCIUGv 3T2kVSac6iaj3aAVYse8pVhzfJlsYDqcsSzn5OeI= Received: from unknown by smtp-3-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4h3JyD5cCgzW55; Mon, 20 Jul 2026 01:00:04 +0200 (CEST) Date: Mon, 20 Jul 2026 01:00:03 +0200 From: Nadia Chambers To: Matthew Wilcox Cc: Kiryl Shutsemau , lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, x86@kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , David Hildenbrand , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Lorenzo Stoakes , "Liam R. Howlett" , Mike Rapoport , Johannes Weiner , Usama Arif Subject: Re: [LSF/MM/BPF TOPIC] 64k (or 16k) base page size on x86 Message-ID: References: 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 In-Reply-To: Feedback-ID: :c73c7b77566af2c:ham:b89b32586f6d122 X-Infomaniak-Routing: alpha On Thu, Feb 19, 2026 at 03:08:51PM +0000, Kiryl Shutsemau wrote: >> On x86, page tables are allocated from the buddy allocator and if PG_SIZE >> is greater than 4 KB, we need a way to pack multiple page tables into a >> single page. We could use the slab allocator for this, but it would >> require relocating the page-table metadata out of struct page. Am Do, Feb 19, 2026 um 17:47:22 +0000, Matthew Wilcox schrieb: > Have you looked at the s390/ppc implementations (yes, they're different, > no, that sucks)? slab seems like the wrong approach to me. Yes, they both required fair amounts of debugging. I don't remember what went wrong in s390 early boot. ppc64 mm/slub.c item-within-page indices ended up notably overflowing 16-bit counters. PA-RISC had some issues surrounding a race with setup or teardown of I think accounting data structures for some IO bus among other things. SPARC had an interesting issue because its page order growth increment / Sprungweite was 3 where the PAGE_MMUSHIFT increment used in testing was 2. Something odd happened with SHMLBA on a bunch of architectures and I can't remember whether there were hardware factors involved or if it was just include and config messes leaking PAGE_SIZE. Am Do, Feb 19, 2026 um 17:47:22 +0000, Matthew Wilcox schrieb: > There's a third approach that I've never looked at which is to allocate > the larger size, then just use it for N consecutive entries. Strangely, I think the mechanical assistant did that for MIPS and few or no others. It was simpler in various ways, but I didn't like the space or locking overheads. Given the chance, I'll likely redo it bes. if I ever get to demo MIPS' 1 KiB PageGrain extension running high performance with a near-VAX minimum MMU/TLB mapping granularity. My energies are more likely to be directed elsewhere if anywhere at all from what you're telling me, though. -- nyc