* Re: [v2 00/16] mm: PMD-level swap entries for anonymous THPs [not found] <20260602142537.198755-1-usama.arif@linux.dev> @ 2026-06-09 14:29 ` Usama Arif 2026-06-10 12:24 ` David Hildenbrand (Arm) 2026-06-13 19:27 ` Zi Yan 0 siblings, 2 replies; 11+ messages in thread From: Usama Arif @ 2026-06-09 14:29 UTC (permalink / raw) To: Andrew Morton, david, chrisl, kasong, ljs, ziy, Linux Memory Management List Cc: ying.huang, Baoquan He, willy, youngjun.park, hannes, riel, shakeel.butt, alex, kas, baohua, dev.jain, baolin.wang, npache, Liam R. Howlett, ryan.roberts, Vlastimil Babka, lance.yang, linux-kernel, nphamcs, shikemeng, kernel-team On 02/06/2026 15:24, Usama Arif wrote: > When reclaim swaps out a PMD-mapped anonymous THP today, the PMD is > split into 512 PTE-level swap entries via TTU_SPLIT_HUGE_PMD before > unmap. > > This series introduces a PMD-level swap entry. The huge mapping is > preserved across the swap round-trip, and do_huge_pmd_swap_page() > resolves the entire 2 MB region in a single fault on swap-in, > no khugepaged involvement is needed. swap_map metadata is identical > either way (512 single-slot counts), so the PTE split buys nothing > on the swap side, it is purely a page-table representation change. > Hello! Just following up if there were any reviews/comments on this series! I know its a large series but was just checking if there was any feedback? Thanks! Usama ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [v2 00/16] mm: PMD-level swap entries for anonymous THPs 2026-06-09 14:29 ` [v2 00/16] mm: PMD-level swap entries for anonymous THPs Usama Arif @ 2026-06-10 12:24 ` David Hildenbrand (Arm) 2026-06-10 13:01 ` Lance Yang 2026-06-13 19:27 ` Zi Yan 1 sibling, 1 reply; 11+ messages in thread From: David Hildenbrand (Arm) @ 2026-06-10 12:24 UTC (permalink / raw) To: Usama Arif, Andrew Morton, chrisl, kasong, ljs, ziy, Linux Memory Management List Cc: ying.huang, Baoquan He, willy, youngjun.park, hannes, riel, shakeel.butt, alex, kas, baohua, dev.jain, baolin.wang, npache, Liam R. Howlett, ryan.roberts, Vlastimil Babka, lance.yang, linux-kernel, nphamcs, shikemeng, kernel-team On 6/9/26 16:29, Usama Arif wrote: > > > On 02/06/2026 15:24, Usama Arif wrote: >> When reclaim swaps out a PMD-mapped anonymous THP today, the PMD is >> split into 512 PTE-level swap entries via TTU_SPLIT_HUGE_PMD before >> unmap. >> >> This series introduces a PMD-level swap entry. The huge mapping is >> preserved across the swap round-trip, and do_huge_pmd_swap_page() >> resolves the entire 2 MB region in a single fault on swap-in, >> no khugepaged involvement is needed. swap_map metadata is identical >> either way (512 single-slot counts), so the PTE split buys nothing >> on the swap side, it is purely a page-table representation change. >> > > Hello! > > Just following up if there were any reviews/comments on this series! > > I know its a large series but was just checking if there was any > feedback? It shall be reviewed. We just finished the mTHP khugepaged review to get it into 7.2, so we've all been rather busy. (I mean, just take a look at the THP-related flood of patches we are fighting with on a daily basis, it's not funny anymore) This is clearly going to be 7.3 material, so there is plenty of time given that the merge window is about to open soon. -- Cheers, David ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [v2 00/16] mm: PMD-level swap entries for anonymous THPs 2026-06-10 12:24 ` David Hildenbrand (Arm) @ 2026-06-10 13:01 ` Lance Yang 2026-06-10 13:48 ` David Hildenbrand (Arm) 0 siblings, 1 reply; 11+ messages in thread From: Lance Yang @ 2026-06-10 13:01 UTC (permalink / raw) To: David Hildenbrand (Arm), Usama Arif Cc: ying.huang, Baoquan He, willy, youngjun.park, hannes, riel, ljs, shakeel.butt, alex, kas, baohua, dev.jain, baolin.wang, npache, Linux Memory Management List, Andrew Morton, Liam R. Howlett, ryan.roberts, chrisl, Vlastimil Babka, linux-kernel, nphamcs, shikemeng, kernel-team, kasong, ziy On 2026/6/10 20:24, David Hildenbrand (Arm) wrote: > On 6/9/26 16:29, Usama Arif wrote: >> >> >> On 02/06/2026 15:24, Usama Arif wrote: >>> When reclaim swaps out a PMD-mapped anonymous THP today, the PMD is >>> split into 512 PTE-level swap entries via TTU_SPLIT_HUGE_PMD before >>> unmap. >>> >>> This series introduces a PMD-level swap entry. The huge mapping is >>> preserved across the swap round-trip, and do_huge_pmd_swap_page() >>> resolves the entire 2 MB region in a single fault on swap-in, >>> no khugepaged involvement is needed. swap_map metadata is identical >>> either way (512 single-slot counts), so the PTE split buys nothing >>> on the swap side, it is purely a page-table representation change. >>> >> >> Hello! >> >> Just following up if there were any reviews/comments on this series! >> >> I know its a large series but was just checking if there was any >> feedback? > > It shall be reviewed. We just finished the mTHP khugepaged review to get it into > 7.2, so we've all been rather busy. Right, mTHP khugepaged was a rough one. Glad we got it over the line, but yeah, there's just been a lot of THP work lately. pretty nonstop ... > (I mean, just take a look at the THP-related flood of patches we are fighting > with on a daily basis, it's not funny anymore) > > This is clearly going to be 7.3 material, so there is plenty of time given that > the merge window is about to open soon. Usama, I'll try to make this one a priority too. Looks interesting :P Cheers, Lance ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [v2 00/16] mm: PMD-level swap entries for anonymous THPs 2026-06-10 13:01 ` Lance Yang @ 2026-06-10 13:48 ` David Hildenbrand (Arm) 2026-06-10 14:44 ` Usama Arif 0 siblings, 1 reply; 11+ messages in thread From: David Hildenbrand (Arm) @ 2026-06-10 13:48 UTC (permalink / raw) To: Lance Yang, Usama Arif Cc: ying.huang, Baoquan He, willy, youngjun.park, hannes, riel, ljs, shakeel.butt, alex, kas, baohua, dev.jain, baolin.wang, npache, Linux Memory Management List, Andrew Morton, Liam R. Howlett, ryan.roberts, chrisl, Vlastimil Babka, linux-kernel, nphamcs, shikemeng, kernel-team, kasong, ziy On 6/10/26 15:01, Lance Yang wrote: > > > On 2026/6/10 20:24, David Hildenbrand (Arm) wrote: >> On 6/9/26 16:29, Usama Arif wrote: >>> >>> >>> >>> Hello! >>> >>> Just following up if there were any reviews/comments on this series! >>> >>> I know its a large series but was just checking if there was any >>> feedback? >> >> It shall be reviewed. We just finished the mTHP khugepaged review to get it into >> 7.2, so we've all been rather busy. > > Right, mTHP khugepaged was a rough one. Glad we got it over the line, > but yeah, there's just been a lot of THP work lately. pretty nonstop ... > >> (I mean, just take a look at the THP-related flood of patches we are fighting >> with on a daily basis, it's not funny anymore) >> >> This is clearly going to be 7.3 material, so there is plenty of time given that >> the merge window is about to open soon. > > Usama, I'll try to make this one a priority too. Looks interesting :P I have two other bigger series to review, but I should soon get to this as well. -- Cheers, David ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [v2 00/16] mm: PMD-level swap entries for anonymous THPs 2026-06-10 13:48 ` David Hildenbrand (Arm) @ 2026-06-10 14:44 ` Usama Arif 2026-06-13 4:22 ` Lance Yang 0 siblings, 1 reply; 11+ messages in thread From: Usama Arif @ 2026-06-10 14:44 UTC (permalink / raw) To: David Hildenbrand (Arm), Lance Yang Cc: ying.huang, Baoquan He, willy, youngjun.park, hannes, riel, ljs, shakeel.butt, alex, kas, baohua, dev.jain, baolin.wang, npache, Linux Memory Management List, Andrew Morton, Liam R. Howlett, ryan.roberts, chrisl, Vlastimil Babka, linux-kernel, nphamcs, shikemeng, kernel-team, kasong, ziy On 10/06/2026 14:48, David Hildenbrand (Arm) wrote: > On 6/10/26 15:01, Lance Yang wrote: >> >> >> On 2026/6/10 20:24, David Hildenbrand (Arm) wrote: >>> On 6/9/26 16:29, Usama Arif wrote: >>>> >>>> >>>> >>>> Hello! >>>> >>>> Just following up if there were any reviews/comments on this series! >>>> >>>> I know its a large series but was just checking if there was any >>>> feedback? >>> >>> It shall be reviewed. We just finished the mTHP khugepaged review to get it into >>> 7.2, so we've all been rather busy. >> >> Right, mTHP khugepaged was a rough one. Glad we got it over the line, >> but yeah, there's just been a lot of THP work lately. pretty nonstop ... >> Yeah its definitely a lot. I have set a target of leaving review comments on atleast 2 patches from mm per day myself, but even that can sometimes be difficult! I will try and help out more in reviews. >>> (I mean, just take a look at the THP-related flood of patches we are fighting >>> with on a daily basis, it's not funny anymore) >>> >>> This is clearly going to be 7.3 material, so there is plenty of time given that >>> the merge window is about to open soon. >> >> Usama, I'll try to make this one a priority too. Looks interesting :P Thanks Lance! > > I have two other bigger series to review, but I should soon get to this as well. > No worries at all! Thanks for the reviews! and yeah definitely 7.3. I will send this out again when 7.3-rc1 opens (rebased), so that the reviews wont be on outdated code which could cause some confusion. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [v2 00/16] mm: PMD-level swap entries for anonymous THPs 2026-06-10 14:44 ` Usama Arif @ 2026-06-13 4:22 ` Lance Yang 2026-06-13 19:18 ` Usama Arif 0 siblings, 1 reply; 11+ messages in thread From: Lance Yang @ 2026-06-13 4:22 UTC (permalink / raw) To: usama.arif Cc: david, lance.yang, ying.huang, baoquan.he, willy, youngjun.park, hannes, riel, ljs, shakeel.butt, alex, kas, baohua, dev.jain, baolin.wang, npache, linux-mm, akpm, liam, ryan.roberts, chrisl, vbabka, linux-kernel, nphamcs, shikemeng, kernel-team, kasong, ziy On Wed, Jun 10, 2026 at 03:44:32PM +0100, Usama Arif wrote: > > >On 10/06/2026 14:48, David Hildenbrand (Arm) wrote: >> On 6/10/26 15:01, Lance Yang wrote: >>> >>> >>> On 2026/6/10 20:24, David Hildenbrand (Arm) wrote: >>>> On 6/9/26 16:29, Usama Arif wrote: >>>>> >>>>> >>>>> >>>>> Hello! >>>>> >>>>> Just following up if there were any reviews/comments on this series! >>>>> >>>>> I know its a large series but was just checking if there was any >>>>> feedback? >>>> >>>> It shall be reviewed. We just finished the mTHP khugepaged review to get it into >>>> 7.2, so we've all been rather busy. >>> >>> Right, mTHP khugepaged was a rough one. Glad we got it over the line, >>> but yeah, there's just been a lot of THP work lately. pretty nonstop ... >>> > >Yeah its definitely a lot. I have set a target of leaving review comments on >atleast 2 patches from mm per day myself, but even that can sometimes be >difficult! I will try and help out more in reviews. Awesome! >>>> (I mean, just take a look at the THP-related flood of patches we are fighting >>>> with on a daily basis, it's not funny anymore) >>>> >>>> This is clearly going to be 7.3 material, so there is plenty of time given that >>>> the merge window is about to open soon. >>> >>> Usama, I'll try to make this one a priority too. Looks interesting :P > >Thanks Lance! > >> >> I have two other bigger series to review, but I should soon get to this as well. >> > >No worries at all! Thanks for the reviews! and yeah definitely 7.3. > >I will send this out again when 7.3-rc1 opens (rebased), so that the reviews wont be on >outdated code which could cause some confusion. After skimming through the whole series, probably PMD swap entries need one bigger rethink ... Emm ... same tricky bit keeps showing up ... One PMD swap entry is easy to handle while the swapcache still has one PMD-sized folio behind it. Once taht folio got split and reclaimed, the 512 swap slots need per-page handling :) Maybe worth first pinning down the rule here. Is a PMD swap entry supposed to mean "there is, or soon will be, one PMD- sized folio behnid it", or is just a compact page-table encoding for 512 swap slot? Without that rule being very clear, every caller has to guess how much it can assume, and it is easy to miss one ... So I stopped staring at the details for now, because the same issue keeps popping up wearing a slightly different hat :) Anyway, no clever answer from me here, not a swap expect :( Just pointing out the pattern I keep runing into. Thanks, Lance ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [v2 00/16] mm: PMD-level swap entries for anonymous THPs 2026-06-13 4:22 ` Lance Yang @ 2026-06-13 19:18 ` Usama Arif 0 siblings, 0 replies; 11+ messages in thread From: Usama Arif @ 2026-06-13 19:18 UTC (permalink / raw) To: Lance Yang Cc: david, ying.huang, baoquan.he, willy, youngjun.park, hannes, riel, ljs, shakeel.butt, alex, kas, baohua, dev.jain, baolin.wang, npache, linux-mm, akpm, liam, ryan.roberts, chrisl, vbabka, linux-kernel, nphamcs, shikemeng, kernel-team, kasong, ziy On 13/06/2026 05:22, Lance Yang wrote: > > On Wed, Jun 10, 2026 at 03:44:32PM +0100, Usama Arif wrote: >> >> >> On 10/06/2026 14:48, David Hildenbrand (Arm) wrote: >>> On 6/10/26 15:01, Lance Yang wrote: >>>> >>>> >>>> On 2026/6/10 20:24, David Hildenbrand (Arm) wrote: >>>>> On 6/9/26 16:29, Usama Arif wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hello! >>>>>> >>>>>> Just following up if there were any reviews/comments on this series! >>>>>> >>>>>> I know its a large series but was just checking if there was any >>>>>> feedback? >>>>> >>>>> It shall be reviewed. We just finished the mTHP khugepaged review to get it into >>>>> 7.2, so we've all been rather busy. >>>> >>>> Right, mTHP khugepaged was a rough one. Glad we got it over the line, >>>> but yeah, there's just been a lot of THP work lately. pretty nonstop ... >>>> >> >> Yeah its definitely a lot. I have set a target of leaving review comments on >> atleast 2 patches from mm per day myself, but even that can sometimes be >> difficult! I will try and help out more in reviews. > > Awesome! > >>>>> (I mean, just take a look at the THP-related flood of patches we are fighting >>>>> with on a daily basis, it's not funny anymore) >>>>> >>>>> This is clearly going to be 7.3 material, so there is plenty of time given that >>>>> the merge window is about to open soon. >>>> >>>> Usama, I'll try to make this one a priority too. Looks interesting :P >> >> Thanks Lance! >> >>> >>> I have two other bigger series to review, but I should soon get to this as well. >>> >> >> No worries at all! Thanks for the reviews! and yeah definitely 7.3. >> >> I will send this out again when 7.3-rc1 opens (rebased), so that the reviews wont be on >> outdated code which could cause some confusion. > > After skimming through the whole series, probably PMD swap entries need > one bigger rethink ... > > Emm ... same tricky bit keeps showing up ... > > One PMD swap entry is easy to handle while the swapcache still has one > PMD-sized folio behind it. Once taht folio got split and reclaimed, the > 512 swap slots need per-page handling :) > > Maybe worth first pinning down the rule here. > > Is a PMD swap entry supposed to mean "there is, or soon will be, one PMD- > sized folio behnid it", or is just a compact page-table encoding for > 512 swap slot? > > Without that rule being very clear, every caller has to guess how much > it can assume, and it is easy to miss one ... > > So I stopped staring at the details for now, because the same issue keeps > popping up wearing a slightly different hat :) > > Anyway, no clever answer from me here, not a swap expect :( Just pointing > out the pattern I keep runing into. > Thanks for the amazing reviews! For the next revision I’m going to treat a PMD swap entry as just a compact page-table encoding for 512 ordinary swap slots. It does not mean that the swapcache still has, or will soon have, one PMD-sized folio behind it. With that rule, whole-PMD handling is only valid when either: 1. the swapcache still has one PMD-sized folio for the range, or 2. the whole PMD swap range has no cached folios, so the caller can try a PMD-sized swapin and still fall back if that is not possible. If any slot in the range has per-page cache state, the PMD entry has to be split and the existing PTE paths need to handle the individual slots. I an reworking the next revision around that. I added a shared helper to classify the swapcache behind a PMD swap entry as empty, PMD-sized, or split, then used it in the places where this assumption mattered: mincore, UFFDIO_MOVE, swapoff, MADV_WILLNEED, and the PMD swap fault path. UFFDIO_MOVE now checks the whole 512-slot range before moving a PMD swap entry without a cached folio, and falls back to PTE handling if per-page cached folios exist. Thanks! Usama ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [v2 00/16] mm: PMD-level swap entries for anonymous THPs 2026-06-09 14:29 ` [v2 00/16] mm: PMD-level swap entries for anonymous THPs Usama Arif 2026-06-10 12:24 ` David Hildenbrand (Arm) @ 2026-06-13 19:27 ` Zi Yan 2026-06-13 19:34 ` Usama Arif 1 sibling, 1 reply; 11+ messages in thread From: Zi Yan @ 2026-06-13 19:27 UTC (permalink / raw) To: Usama Arif Cc: Andrew Morton, david, chrisl, kasong, ljs, Linux Memory Management List, ying.huang, Baoquan He, willy, youngjun.park, hannes, riel, shakeel.butt, alex, kas, baohua, dev.jain, baolin.wang, npache, Liam R. Howlett, ryan.roberts, Vlastimil Babka, lance.yang, linux-kernel, nphamcs, shikemeng, kernel-team On 9 Jun 2026, at 10:29, Usama Arif wrote: > On 02/06/2026 15:24, Usama Arif wrote: >> When reclaim swaps out a PMD-mapped anonymous THP today, the PMD is >> split into 512 PTE-level swap entries via TTU_SPLIT_HUGE_PMD before >> unmap. >> >> This series introduces a PMD-level swap entry. The huge mapping is >> preserved across the swap round-trip, and do_huge_pmd_swap_page() >> resolves the entire 2 MB region in a single fault on swap-in, >> no khugepaged involvement is needed. swap_map metadata is identical >> either way (512 single-slot counts), so the PTE split buys nothing >> on the swap side, it is purely a page-table representation change. >> > > Hello! > > Just following up if there were any reviews/comments on this series! > > I know its a large series but was just checking if there was any > feedback? Maybe send first 6 clean-up patches separately to get them merged first? -- Best Regards, Yan, Zi ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [v2 00/16] mm: PMD-level swap entries for anonymous THPs 2026-06-13 19:27 ` Zi Yan @ 2026-06-13 19:34 ` Usama Arif 2026-06-13 19:48 ` Usama Arif 2026-06-14 1:48 ` Lance Yang 0 siblings, 2 replies; 11+ messages in thread From: Usama Arif @ 2026-06-13 19:34 UTC (permalink / raw) To: Zi Yan Cc: Andrew Morton, david, chrisl, kasong, ljs, Linux Memory Management List, ying.huang, Baoquan He, willy, youngjun.park, hannes, riel, shakeel.butt, alex, kas, baohua, dev.jain, baolin.wang, npache, Liam R. Howlett, ryan.roberts, Vlastimil Babka, lance.yang, linux-kernel, nphamcs, shikemeng, kernel-team On 13/06/2026 20:27, Zi Yan wrote: > On 9 Jun 2026, at 10:29, Usama Arif wrote: > >> On 02/06/2026 15:24, Usama Arif wrote: >>> When reclaim swaps out a PMD-mapped anonymous THP today, the PMD is >>> split into 512 PTE-level swap entries via TTU_SPLIT_HUGE_PMD before >>> unmap. >>> >>> This series introduces a PMD-level swap entry. The huge mapping is >>> preserved across the swap round-trip, and do_huge_pmd_swap_page() >>> resolves the entire 2 MB region in a single fault on swap-in, >>> no khugepaged involvement is needed. swap_map metadata is identical >>> either way (512 single-slot counts), so the PTE split buys nothing >>> on the swap side, it is purely a page-table representation change. >>> >> >> Hello! >> >> Just following up if there were any reviews/comments on this series! >> >> I know its a large series but was just checking if there was any >> feedback? > > Maybe send first 6 clean-up patches separately to get them merged first? Good idea! Will do that. Thanks! > > -- > Best Regards, > Yan, Zi ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [v2 00/16] mm: PMD-level swap entries for anonymous THPs 2026-06-13 19:34 ` Usama Arif @ 2026-06-13 19:48 ` Usama Arif 2026-06-14 1:48 ` Lance Yang 1 sibling, 0 replies; 11+ messages in thread From: Usama Arif @ 2026-06-13 19:48 UTC (permalink / raw) To: Zi Yan, Andrew Morton, david, Lance Yang Cc: chrisl, kasong, ljs, Linux Memory Management List, ying.huang, Baoquan He, willy, youngjun.park, hannes, riel, shakeel.butt, alex, kas, baohua, dev.jain, baolin.wang, npache, Liam R. Howlett, ryan.roberts, Vlastimil Babka, lance.yang, linux-kernel, nphamcs, shikemeng, kernel-team On 13/06/2026 20:34, Usama Arif wrote: > > > On 13/06/2026 20:27, Zi Yan wrote: >> On 9 Jun 2026, at 10:29, Usama Arif wrote: >> >>> On 02/06/2026 15:24, Usama Arif wrote: >>>> When reclaim swaps out a PMD-mapped anonymous THP today, the PMD is >>>> split into 512 PTE-level swap entries via TTU_SPLIT_HUGE_PMD before >>>> unmap. >>>> >>>> This series introduces a PMD-level swap entry. The huge mapping is >>>> preserved across the swap round-trip, and do_huge_pmd_swap_page() >>>> resolves the entire 2 MB region in a single fault on swap-in, >>>> no khugepaged involvement is needed. swap_map metadata is identical >>>> either way (512 single-slot counts), so the PTE split buys nothing >>>> on the swap side, it is purely a page-table representation change. >>>> >>> >>> Hello! >>> >>> Just following up if there were any reviews/comments on this series! >>> >>> I know its a large series but was just checking if there was any >>> feedback? >> >> Maybe send first 6 clean-up patches separately to get them merged first? > > Good idea! Will do that. Thanks! > So what I will do is once the merge window closes, send the first 6 patches for review, then when they make it into mm-new (so that we get sashiko feedback), send the core patches that I have reworked based on Lances' feedback. [1] [2] [1] https://lore.kernel.org/all/526fdbc0-1944-4328-9ff6-7922d021828d@linux.dev/ [2] https://lore.kernel.org/all/20260612142124.73367-1-lance.yang@linux.dev/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [v2 00/16] mm: PMD-level swap entries for anonymous THPs 2026-06-13 19:34 ` Usama Arif 2026-06-13 19:48 ` Usama Arif @ 2026-06-14 1:48 ` Lance Yang 1 sibling, 0 replies; 11+ messages in thread From: Lance Yang @ 2026-06-14 1:48 UTC (permalink / raw) To: Usama Arif, Zi Yan Cc: Andrew Morton, david, chrisl, kasong, ljs, Linux Memory Management List, ying.huang, Baoquan He, willy, youngjun.park, hannes, riel, shakeel.butt, alex, kas, baohua, dev.jain, baolin.wang, npache, Liam R. Howlett, ryan.roberts, Vlastimil Babka, linux-kernel, nphamcs, shikemeng, kernel-team On 2026/6/14 03:34, Usama Arif wrote: > > > On 13/06/2026 20:27, Zi Yan wrote: >> On 9 Jun 2026, at 10:29, Usama Arif wrote: >> >>> On 02/06/2026 15:24, Usama Arif wrote: >>>> When reclaim swaps out a PMD-mapped anonymous THP today, the PMD is >>>> split into 512 PTE-level swap entries via TTU_SPLIT_HUGE_PMD before >>>> unmap. >>>> >>>> This series introduces a PMD-level swap entry. The huge mapping is >>>> preserved across the swap round-trip, and do_huge_pmd_swap_page() >>>> resolves the entire 2 MB region in a single fault on swap-in, >>>> no khugepaged involvement is needed. swap_map metadata is identical >>>> either way (512 single-slot counts), so the PTE split buys nothing >>>> on the swap side, it is purely a page-table representation change. >>>> >>> >>> Hello! >>> >>> Just following up if there were any reviews/comments on this series! >>> >>> I know its a large series but was just checking if there was any >>> feedback? >> >> Maybe send first 6 clean-up patches separately to get them merged first? > > Good idea! Will do that. Thanks! Yeah, sounds good. Less churn, and the cleanups can land first, and life is easier for everyone :D ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2026-06-14 1:48 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260602142537.198755-1-usama.arif@linux.dev>
2026-06-09 14:29 ` [v2 00/16] mm: PMD-level swap entries for anonymous THPs Usama Arif
2026-06-10 12:24 ` David Hildenbrand (Arm)
2026-06-10 13:01 ` Lance Yang
2026-06-10 13:48 ` David Hildenbrand (Arm)
2026-06-10 14:44 ` Usama Arif
2026-06-13 4:22 ` Lance Yang
2026-06-13 19:18 ` Usama Arif
2026-06-13 19:27 ` Zi Yan
2026-06-13 19:34 ` Usama Arif
2026-06-13 19:48 ` Usama Arif
2026-06-14 1:48 ` Lance Yang
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox