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 EE57531690A for ; Mon, 23 Feb 2026 05:08:04 +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=1771823287; cv=none; b=GMQPyj4smfjxG43Wsg83Obq4bVV/gM7eNxIbUH+ichdGcNZrs555d4tldi82WPxF+BBLhDJsqn/YJ+DzblEMzZ70qQQCLV1TOMz7hJzcCry/pfJ+Hu+GM4qlR9bjBINNDk3Te3xcLd8lcBT6b/Fb5/e+LklJUeiIDxFDc2UzzBI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771823287; c=relaxed/simple; bh=X5YJ+qY8Jzs48tNoZxM/VEeyS05XWrV6C42ssmVdJ2I=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=akclU/rA0d3SR6H0Z0qreyPvCRLY38+VtBRn97tTxIrQwGD+qENApvgUxoaftg0MgsrKH9GDYH1D+7dR4S7BYJdxMkx4Bqv3RAp4EVDvsUcO7854lHft2LZLBZqwfsX1KG9nNdV7MnpuAXHU55bIKAQb6dQBY1L5fBD7JhVPQYA= 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; 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 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 8DD44339; Sun, 22 Feb 2026 21:07:57 -0800 (PST) Received: from [10.164.19.28] (unknown [10.164.19.28]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 659CF3F7BD; Sun, 22 Feb 2026 21:07:58 -0800 (PST) Message-ID: Date: Mon, 23 Feb 2026 10:37:55 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [LSF/MM/BPF TOPIC] Per-process page size To: Pedro Falcato Cc: lsf-pc@lists.linux-foundation.org, ryan.roberts@arm.com, catalin.marinas@arm.com, will@kernel.org, ardb@kernel.org, willy@infradead.org, hughd@google.com, baolin.wang@linux.alibaba.com, akpm@linux-foundation.org, david@kernel.org, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20260217145026.3880286-1-dev.jain@arm.com> Content-Language: en-US From: Dev Jain In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit >> >> 3. Translation from Linux pagetable to native pagetable >> ------------------------------------------------------- >> Assume the case of a kernel pagesize of 4K and app pagesize of 64K. >> Now that enlightenment is done, it is guaranteed that every single mapping >> in the 4K pagetable (which we call the Linux pagetable) is of granularity >> at least 64K. In the arm64 MM code, we maintain a "native" pagetable per >> mm_struct, which is based off a 64K geometry. Because of the guarantee >> aforementioned, any pagetable operation on the Linux pagetable >> (set_ptes, clear_flush_ptes, modify_prot_start_ptes, etc) is going to happen >> at a granularity of at least 16 PTEs - therefore we can translate this >> operation to modify a single PTE entry in the native pagetable. >> Given that enlightenment may miss corner cases, we insert a warning in the >> architecture code - on being presented with an operation not translatable >> into a native operation, we fallback to the Linux pagetable, thus losing >> the benefits borne out of the pagetable geometry but keeping >> the emulation intact. > I don't understand. What exactly are you trying to do here? Maintain 2 > different paging structures, one for core mm and the other for the arch? As > done in architectures with no radix tree paging structures? The mm->pgd will be the software pagetable. So suppose that do_anonymous_page is doing set_ptes on the PTE table belonging to the software pagetable. We will hook a "native_set_ptes" into set_ptes, which will set the ptes on a different pagetable maintained by arm64 code (probably mm_context_t->native_pgd). > > If so, that's wildly inefficient, unless you're willing to go into reclaimable > page tables on the arm64 side. And that brings extra problems and extra fun :) I didn't understand the reclaimable reference, but yes we need to make this efficient. So for the above example I gave, native_set_ptes knows the virtual address to set - walking the native hierarchy from native_pgd->native_pmd->native_pte (in case of 64K native geometry) is inefficient. So we need to maintain a lookup mechanism from a linux pgtable pointer to the native pgtable pointer. The idea we have currently is to store such lookup in the struct ptdesc of the pagetable page. For 4K Linux pagetable and 64K native pagetable, 512M/2M = 256 Linux PTE tables correspond to different sections of the native PTE table. We will maintain the pointer to the relevant section in the native PTE table, in the struct ptdesc of the pagetable page of the Linux PTE table. The other case is that a single Linux pgtable leaf entry corresponds to multiple native leaf entries - take the case of a Linux PMD table which maps 1G of memory, this corresponds to 2 native PTE tables (2 x 512M). We will have to store a list of pointers here. >