[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZmhcepJrkDpJ7mSC@x1n>
Date: Tue, 11 Jun 2024 10:17:30 -0400
From: Peter Xu <peterx@...hat.com>
To: Oscar Salvador <osalvador@...e.de>
Cc: Christophe Leroy <christophe.leroy@...roup.eu>,
Andrew Morton <akpm@...ux-foundation.org>,
Jason Gunthorpe <jgg@...dia.com>,
Michael Ellerman <mpe@...erman.id.au>,
Nicholas Piggin <npiggin@...il.com>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v5 02/18] mm: Define __pte_leaf_size() to also take a PMD
entry
Oscar,
On Tue, Jun 11, 2024 at 11:34:23AM +0200, Oscar Salvador wrote:
> Which means that they would be caught in the following code:
>
> ptl = pmd_huge_lock(pmd, vma);
> if (ptl) {
> - 8MB hugepages will be handled here
> smaps_pmd_entry(pmd, addr, walk);
> spin_unlock(ptl);
> }
> /* pte stuff */
> ...
Just one quick comment: I think there's one challenge though as this is
also not a generic "pmd leaf", but a pgtable page underneath. I think it
means smaps_pmd_entry() won't trivially work here, e.g., it will start to
do this:
if (pmd_present(*pmd)) {
page = vm_normal_page_pmd(vma, addr, *pmd);
Here vm_normal_page_pmd() will only work if pmd_leaf() satisfies its
definition as:
* - It should contain a huge PFN, which points to a huge page larger than
* PAGE_SIZE of the platform. The PFN format isn't important here.
But now it's a pgtable page, containing cont-ptes. Similarly, I think most
pmd_*() helpers will stop working there if we report it as a leaf.
Thanks,
--
Peter Xu
Powered by blists - more mailing lists