From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 03D03286410 for ; Mon, 23 Feb 2026 15:18:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771859936; cv=none; b=XcnigzxRyWbNqujHzIW8NjrXsjQ9Xa8+NQ7Cw6doW9v9l+gDhW4b9GwcJEujQD/Xn5kbXsvDCnJ6qOKjanOCE3fRRs4UUMF0LS/NH+9SDLSHKwbMyNG6Gtx6XQvquD6o5e9ldToKeqRrDqCyGzNVSafbo++Xc9KBM+Ua7yZ07ZY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771859936; c=relaxed/simple; bh=4tSOBFLGt4+9UrDhI/sEHrVcOiuonNBKY1RtZ7k3N5U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dwvwR9pyNLfmoiODTEJOhPRn9KdL0MXiRirXEbyObA7Me3d5x4+dw4P7t7kC8byI6qL4xiHL/U1QsXQiVD/VjP4Kce7UBilYB6zVg1zPkyDSDrqPa+nx7M5nacHUYCkeYHF5N9cE/j2vDD+P+0aLdUnPJSq4IZ/DTdHhISD9hmc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=gA3K3dpb; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="gA3K3dpb" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=J1Pyr+PuAUEvSin3Lid3+3iEaebJRuWaK1nzHUHfvJU=; b=gA3K3dpbvNeInnLOTbSUFfNzCk vPBhNWwpfU9pwz3ungRZAi+0kDBTW7+HlajkgAuzelgB35eHW4qJMZ/XT7NMJwhh6i4aEEG86hLDC wphXKrrK/pCSZ3FGitimdei46DCTcVXjuaJJ3B1dINPRgs4o89lseU5XRUeOW2FNXUk5XiRw0iy0k 3qAYDbQOJU/9hWwa0Lev89Ab88AFMCS50dPGzo/vizsHkxdlae4U83TaISx8Jmbf/oGOcIMmV2K+v i/VqdKip2dCvMGB9HwAtFHPgXybj/HsfEiIfN6AXECswAAQSzFa7ImnmQGi1fV2dmaXf4purfk2Yf EQcUmUng==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1vuXhq-0000000Ef0a-351E; Mon, 23 Feb 2026 15:18:42 +0000 Date: Mon, 23 Feb 2026 15:18:42 +0000 From: Matthew Wilcox To: Dev Jain Cc: Pedro Falcato , lsf-pc@lists.linux-foundation.org, ryan.roberts@arm.com, catalin.marinas@arm.com, will@kernel.org, ardb@kernel.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 Subject: Re: [LSF/MM/BPF TOPIC] Per-process page size Message-ID: References: <20260217145026.3880286-1-dev.jain@arm.com> 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 Mon, Feb 23, 2026 at 10:37:55AM +0530, Dev Jain wrote: > I didn't understand the reclaimable reference, but yes we need to make this efficient. this goes over 80 columns so much and so often, it's painful to read. so i didn't. > 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. > > > >