arch/x86/mm/pat/set_memory.c | 36 ++++++++++++++++++++++++------------ 1 file changed, 24 insertions(+), 12 deletions(-)
set_memory.c has a call to pagetable_free(), while the allocation sites use get_free_pages(). This causes issues separately allocating ptdescs from struct page. It turns out that we can just use the appropriate generic pagetable apis for allocation/freeing. This helps simplify and standardize the code. In the short term, this helps enable Matthew's work to allocate frozen pagetables[1]. And in the long term, this will help us cleanly split ptdesc allocations from struct page[2]. [1] https://lore.kernel.org/linux-mm/20251113140448.1814860-1-willy@infradead.org/ [2] https://lore.kernel.org/linux-mm/20251020001652.2116669-1-willy@infradead.org/ ------ Based on current mm-new. v6: - Drop the renaming of *page* functions - Use existing page table api instead of creating new apis - Split the pmd and populate_pgd() changes into separate patches - Reword the cover letter to describe the new approach v5 link: https://lore.kernel.org/all/20260211195233.368497-1-vishal.moola@gmail.com/ Vishal Moola (Oracle) (4): x86/mm/pat: Convert pte code to use page table apis x86/mm/pat: Convert pmd code to use page table apis x86/mm/pat: Convert populate_pgd() to use page table apis x86/mm/pat: Convert split_large_page() to use ptdescs arch/x86/mm/pat/set_memory.c | 36 ++++++++++++++++++++++++------------ 1 file changed, 24 insertions(+), 12 deletions(-) -- 2.53.0
On Wed, Feb 18, 2026 at 06:03:50PM -0800, Vishal Moola (Oracle) wrote: > set_memory.c has a call to pagetable_free(), while the allocation sites > use get_free_pages(). This causes issues separately allocating ptdescs > from struct page. > > It turns out that we can just use the appropriate generic pagetable > apis for allocation/freeing. This helps simplify and standardize the > code. > > In the short term, this helps enable Matthew's work to allocate frozen > pagetables[1]. And in the long term, this will help us cleanly split > ptdesc allocations from struct page[2]. > > [1] https://lore.kernel.org/linux-mm/20251113140448.1814860-1-willy@infradead.org/ > [2] https://lore.kernel.org/linux-mm/20251020001652.2116669-1-willy@infradead.org/ > > ------ > > Based on current mm-new. Hi Dave, Do you have any more comments for this series? If not, could you please take this through the x86 tree. Thanks :) > v6: > - Drop the renaming of *page* functions > - Use existing page table api instead of creating new apis > - Split the pmd and populate_pgd() changes into separate patches > - Reword the cover letter to describe the new approach > > v5 link: > https://lore.kernel.org/all/20260211195233.368497-1-vishal.moola@gmail.com/ > > Vishal Moola (Oracle) (4): > x86/mm/pat: Convert pte code to use page table apis > x86/mm/pat: Convert pmd code to use page table apis > x86/mm/pat: Convert populate_pgd() to use page table apis > x86/mm/pat: Convert split_large_page() to use ptdescs > > arch/x86/mm/pat/set_memory.c | 36 ++++++++++++++++++++++++------------ > 1 file changed, 24 insertions(+), 12 deletions(-) > > -- > 2.53.0 >
On 2/27/26 12:07, Vishal Moola (Oracle) wrote: > Do you have any more comments for this series? If not, could you please > take this through the x86 tree. Thanks 🙂 From a 2-second glance, this doesn't have normal comment style and isn't using imperative voice. Quite a few "we's". Looks like it needs some more eyeballs.
On Fri, Feb 27, 2026 at 02:24:33PM -0800, Dave Hansen wrote: > On 2/27/26 12:07, Vishal Moola (Oracle) wrote: > > Do you have any more comments for this series? If not, could you please > > take this through the x86 tree. Thanks 🙂 > > From a 2-second glance, this doesn't have normal comment style and isn't > using imperative voice. Quite a few "we's". Looks like it needs some > more eyeballs. Ok, my mistake on the comment style. I'll fix that. Sorry I'm not the greatest at imperative voice, I'll pass all my comments through AI to convert them all to imperative voice. In regards to more eyeballs, I've realized I didn't cc ALL x86 maintainers. +CC the rest of the x86 maintainers and we'll hope someone else looks at it as well.
On 2/27/26 16:44, Vishal Moola (Oracle) wrote: > On Fri, Feb 27, 2026 at 02:24:33PM -0800, Dave Hansen wrote: >> On 2/27/26 12:07, Vishal Moola (Oracle) wrote: >>> Do you have any more comments for this series? If not, could you please >>> take this through the x86 tree. Thanks 🙂 >> >> From a 2-second glance, this doesn't have normal comment style and isn't >> using imperative voice. Quite a few "we's". Looks like it needs some >> more eyeballs. > > Ok, my mistake on the comment style. I'll fix that. > > Sorry I'm not the greatest at imperative voice, I'll pass all my comments > through AI to convert them all to imperative voice. > > In regards to more eyeballs, I've realized I didn't cc ALL x86 > maintainers. +CC the rest of the x86 maintainers and we'll hope > someone else looks at it as well. I was actually kinda hoping you'd be able to actively go out and find some reviewers other than the maintainers.
On Mon, Mar 02, 2026 at 09:33:31AM -0800, Dave Hansen wrote: > On 2/27/26 16:44, Vishal Moola (Oracle) wrote: > > On Fri, Feb 27, 2026 at 02:24:33PM -0800, Dave Hansen wrote: > >> On 2/27/26 12:07, Vishal Moola (Oracle) wrote: > >>> Do you have any more comments for this series? If not, could you please > >>> take this through the x86 tree. Thanks 🙂 > >> > >> From a 2-second glance, this doesn't have normal comment style and isn't > >> using imperative voice. Quite a few "we's". Looks like it needs some > >> more eyeballs. > > > > Ok, my mistake on the comment style. I'll fix that. > > > > Sorry I'm not the greatest at imperative voice, I'll pass all my comments > > through AI to convert them all to imperative voice. > > > > In regards to more eyeballs, I've realized I didn't cc ALL x86 > > maintainers. +CC the rest of the x86 maintainers and we'll hope > > someone else looks at it as well. > > I was actually kinda hoping you'd be able to actively go out and find > some reviewers other than the maintainers. I'd appreciate if you could give me more guidance on this. Who am I supposed to go, if not the people from ./get_maintainers? I don't know the x86 folks, I interact more with mm. You've been giving valuable feedback to ensure the stylistic choices meet your expectations. I have mentioned I'll have another version *trying* to meet those stylistic expectations. Mike has been very active in reviewing the ptdesc work (thanks!), and he's provided valuable review about the code itself. I don't know about you, but I trust his expertise on the topic of page tables. So, I don't even know what you want from the "more eyeballs." Do you want me to email a bunch of people unfamiliar with x86 and tell them to catch what you (or any other specialized individual) would catch? That doesn't sound productive *to me*. This is on the x86 mailing list. And honestly, this current iteration is simple enough that anyone specialized and interested could have taken a look at it and to provide some feedback. Please do let me know. I'd love to work with you not against you, but that's difficult when you don't provide any guidance/pointers about the issues you have with the patchset (or process?).
On 3/2/26 12:27, Vishal Moola (Oracle) wrote: >> I was actually kinda hoping you'd be able to actively go out and find >> some reviewers other than the maintainers. > I'd appreciate if you could give me more guidance on this. Who am I > supposed to go, if not the people from ./get_maintainers? I don't know > the x86 folks, I interact more with mm. Hi Vishal, I personally look at 'git blame' or 'git log' manually and see who's been mucking around in the file recently. get_maintainers.pl does _some_ of that, but I think it mostly looks at others who modified the sames lines you did. That can be a bit too restrictive. It also couldn't hurt to take a quick look at lore for who's been patching the files that you are, or commenting in threads. The more of that which you can manage to do this now is less of it that I have to do later. Any effort in the area would be much appreciated! Oh, and if you have a friendly LLM, it doesn't hurt to dump your patches in there and ask it. Couldn't hurt.
On Mon, Mar 02, 2026 at 12:55:10PM -0800, Dave Hansen wrote: > On 3/2/26 12:27, Vishal Moola (Oracle) wrote: > >> I was actually kinda hoping you'd be able to actively go out and find > >> some reviewers other than the maintainers. > > I'd appreciate if you could give me more guidance on this. Who am I > > supposed to go, if not the people from ./get_maintainers? I don't know > > the x86 folks, I interact more with mm. > > Hi Vishal, > > I personally look at 'git blame' or 'git log' manually and see who's > been mucking around in the file recently. get_maintainers.pl does _some_ > of that, but I think it mostly looks at others who modified the sames > lines you did. That can be a bit too restrictive. > > It also couldn't hurt to take a quick look at lore for who's been > patching the files that you are, or commenting in threads. > > The more of that which you can manage to do this now is less of it that > I have to do later. Any effort in the area would be much appreciated! Thanks! I'll look around and cc them on future versions. > Oh, and if you have a friendly LLM, it doesn't hurt to dump your patches > in there and ask it. Couldn't hurt.
On Wed, Feb 18, 2026 at 06:03:50PM -0800, Vishal Moola (Oracle) wrote: > set_memory.c has a call to pagetable_free(), while the allocation sites > use get_free_pages(). This causes issues separately allocating ptdescs > from struct page. > > It turns out that we can just use the appropriate generic pagetable > apis for allocation/freeing. This helps simplify and standardize the > code. > > In the short term, this helps enable Matthew's work to allocate frozen > pagetables[1]. And in the long term, this will help us cleanly split > ptdesc allocations from struct page[2]. > > [1] https://lore.kernel.org/linux-mm/20251113140448.1814860-1-willy@infradead.org/ > [2] https://lore.kernel.org/linux-mm/20251020001652.2116669-1-willy@infradead.org/ > > ------ > > Based on current mm-new. > > v6: > - Drop the renaming of *page* functions > - Use existing page table api instead of creating new apis > - Split the pmd and populate_pgd() changes into separate patches > - Reword the cover letter to describe the new approach > > v5 link: > https://lore.kernel.org/all/20260211195233.368497-1-vishal.moola@gmail.com/ > > Vishal Moola (Oracle) (4): > x86/mm/pat: Convert pte code to use page table apis > x86/mm/pat: Convert pmd code to use page table apis > x86/mm/pat: Convert populate_pgd() to use page table apis > x86/mm/pat: Convert split_large_page() to use ptdescs > > arch/x86/mm/pat/set_memory.c | 36 ++++++++++++++++++++++++------------ > 1 file changed, 24 insertions(+), 12 deletions(-) Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> > > -- > 2.53.0 > -- Sincerely yours, Mike.
© 2016 - 2026 Red Hat, Inc.