From: Usama Arif <usama.arif@linux.dev>
To: "Lorenzo Stoakes (Oracle)" <ljs@kernel.org>,
"David Hildenbrand (Arm)" <david@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
willy@infradead.org, linux-mm@kvack.org, fvdl@google.com,
hannes@cmpxchg.org, riel@surriel.com, shakeel.butt@linux.dev,
kas@kernel.org, baohua@kernel.org, dev.jain@arm.com,
baolin.wang@linux.alibaba.com, npache@redhat.com,
Liam.Howlett@oracle.com, ryan.roberts@arm.com,
Vlastimil Babka <vbabka@kernel.org>,
lance.yang@linux.dev, linux-kernel@vger.kernel.org,
kernel-team@meta.com, maddy@linux.ibm.com, mpe@ellerman.id.au,
linuxppc-dev@lists.ozlabs.org, hca@linux.ibm.com,
gor@linux.ibm.com, agordeev@linux.ibm.com,
borntraeger@linux.ibm.com, svens@linux.ibm.com,
linux-s390@vger.kernel.org
Subject: Re: [v3 00/24] mm: thp: lazy PTE page table allocation at PMD split time
Date: Fri, 27 Mar 2026 10:40:10 -0400 [thread overview]
Message-ID: <a5efef0a-8d68-4c8c-b8ae-09a6a33e37cd@linux.dev> (raw)
In-Reply-To: <cf36f821-8285-4b9f-b1fd-e080292f4204@lucifer.local>
On 27/03/2026 12:25, Lorenzo Stoakes (Oracle) wrote:
> On Fri, Mar 27, 2026 at 09:51:31AM +0100, David Hildenbrand (Arm) wrote:
>>>
>>> RFC v2 -> v3: https://lore.kernel.org/all/de0dc7ec-7a8d-4b1a-a419-1d97d2e4d510@linux.dev/
>>
>> Note that we usually go from RFC to v1.
>>
>> I'll put this series on my review backlog, but it will take some time
>> until I get to it (it won't make the next release either way :) ).
>
> Yeah, please update to v1 from RFC because I'm looking at this and wondering
> where v1, v2 was and why I didn't see them...
Ah yeah I included the previous version link in the coverletter [1].
>
> Generally I'd also advise un-RFC'ing a biiiig series IDEALLY be done early in a
> merge window :)
>
> We've pretty much shut the door to new series this cycle, but being so late in
> the window at -rc5 would mean no way for this one anyway.
ack
>
> But in general it's going to be a rebase pain this,
Yeah rebasing from previous version [1] wasnt fun. But yes happy to rebase when
needed!
> and I'd rather not see it
> land in mm-unstable at this point, because that's supposed to be 'what's in the
> next release' and it's stuff like this that leads to 'I am not sure what
> mm-unstable represents any more' being a thing.
>
> I think in an ideal world we'd ONLY see this in mm-new.
ack, I will try and send the next revision on top of mm-new. I do believe
this will apply cleanly on mm-new at the moment as well but ofcourse that can change.
>
> I wonder if we need some process for un-RFC'ing really, where somebody kinda
> asks rather than it being a vibes thing as it is now (or a 'people don't reply
> to my RFC' which yes I'm guilty of :)
>
> Anyway this is more general points and not about you Usama, because - hey - all
> this stuff is pretty unclear generally.
>
No worries and Thanks for reviewing!!
>>
>> --
>> Cheers,
>>
>> David
>
> Cheers, Lorenzo
[1] https://lore.kernel.org/all/20260226113233.3987674-1-usama.arif@linux.dev/
next prev parent reply other threads:[~2026-03-27 14:40 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-27 2:08 [v3 00/24] mm: thp: lazy PTE page table allocation at PMD split time Usama Arif
2026-03-27 2:08 ` [v3 01/24] mm: thp: make split_huge_pmd functions return int for error propagation Usama Arif
2026-03-27 2:08 ` [v3 02/24] mm: thp: propagate split failure from vma_adjust_trans_huge() Usama Arif
2026-03-27 2:08 ` [v3 03/24] mm: thp: handle split failure in copy_huge_pmd() Usama Arif
2026-03-27 2:08 ` [v3 04/24] mm: thp: handle split failure in do_huge_pmd_wp_page() Usama Arif
2026-03-27 2:08 ` [v3 05/24] mm: thp: handle split failure in zap_pmd_range() Usama Arif
2026-03-30 14:13 ` Kiryl Shutsemau
2026-03-30 15:09 ` David Hildenbrand (Arm)
2026-03-27 2:08 ` [v3 06/24] mm: thp: handle split failure in wp_huge_pmd() Usama Arif
2026-03-27 2:08 ` [v3 07/24] mm: thp: retry on split failure in change_pmd_range() Usama Arif
2026-03-30 14:27 ` Kiryl Shutsemau
2026-03-27 2:08 ` [v3 08/24] mm: thp: handle split failure in follow_pmd_mask() Usama Arif
2026-03-27 2:08 ` [v3 09/24] mm: handle walk_page_range() failure from THP split Usama Arif
2026-03-27 2:08 ` [v3 10/24] mm: thp: handle split failure in mremap move_page_tables() Usama Arif
2026-03-27 2:08 ` [v3 11/24] mm: thp: handle split failure in userfaultfd move_pages() Usama Arif
2026-03-27 2:08 ` [v3 12/24] mm: thp: handle split failure in device migration Usama Arif
2026-03-27 2:08 ` [v3 13/24] mm: proc: handle split_huge_pmd failure in pagemap_scan Usama Arif
2026-03-27 2:08 ` [v3 14/24] powerpc/mm: handle split_huge_pmd failure in subpage_prot Usama Arif
2026-03-27 2:08 ` [v3 15/24] fs/dax: handle split_huge_pmd failure in dax_iomap_pmd_fault Usama Arif
2026-03-27 2:08 ` [v3 16/24] mm: huge_mm: Make sure all split_huge_pmd calls are checked Usama Arif
2026-03-30 14:41 ` Kiryl Shutsemau
2026-03-27 2:08 ` [v3 17/24] mm: thp: allocate PTE page tables lazily at split time Usama Arif
2026-03-27 2:09 ` [v3 18/24] mm: thp: remove pgtable_trans_huge_{deposit/withdraw} when not needed Usama Arif
2026-03-27 2:09 ` [v3 19/24] mm: thp: add THP_SPLIT_PMD_FAILED counter Usama Arif
2026-03-27 2:09 ` [v3 20/24] selftests/mm: add THP PMD split test infrastructure Usama Arif
2026-03-27 2:09 ` [v3 21/24] selftests/mm: add partial_mprotect test for change_pmd_range Usama Arif
2026-03-27 2:09 ` [v3 22/24] selftests/mm: add partial_mlock test Usama Arif
2026-03-27 2:09 ` [v3 23/24] selftests/mm: add partial_mremap test for move_page_tables Usama Arif
2026-03-27 2:09 ` [v3 24/24] selftests/mm: add madv_dontneed_partial test Usama Arif
2026-03-27 8:51 ` [v3 00/24] mm: thp: lazy PTE page table allocation at PMD split time David Hildenbrand (Arm)
2026-03-27 9:25 ` Lorenzo Stoakes (Oracle)
2026-03-27 14:40 ` Usama Arif [this message]
2026-03-27 14:34 ` Usama Arif
2026-04-05 23:34 ` Hugh Dickins
2026-04-08 15:06 ` Usama Arif
2026-04-08 19:49 ` Matthew Wilcox
2026-04-09 12:48 ` Usama Arif
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a5efef0a-8d68-4c8c-b8ae-09a6a33e37cd@linux.dev \
--to=usama.arif@linux.dev \
--cc=Liam.Howlett@oracle.com \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=borntraeger@linux.ibm.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=fvdl@google.com \
--cc=gor@linux.ibm.com \
--cc=hannes@cmpxchg.org \
--cc=hca@linux.ibm.com \
--cc=kas@kernel.org \
--cc=kernel-team@meta.com \
--cc=lance.yang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=ljs@kernel.org \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=npache@redhat.com \
--cc=riel@surriel.com \
--cc=ryan.roberts@arm.com \
--cc=shakeel.butt@linux.dev \
--cc=svens@linux.ibm.com \
--cc=vbabka@kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.