mm: preparatory patches for PMD level swap entries

Add softleaf_to_pmd() as the PMD counterpart to softleaf_to_pte(), completing the symmetry of the softleaf abstraction for page table leaf entries.

The upcoming PMD swap entry support needs to construct PMD entries from swap entries. Converting existing swp_entry_to_pmd() callers to softleaf_to_pmd() in a prep patch keeps the feature patches focused on new functionality rather than mixing refactoring with new code.

Acked-by David Hildenbrand (Arm) <[email protected]>

Reviewed-by Zi Yan <[email protected]>

Signed-off-by Usama Arif <[email protected]>

---

When a swap entry is installed in a page table, the mm must be added to init_mm.mmlist so that swapoff can find and unuse its swap entries. This double-checked locking pattern is currently open-coded in try_to_unmap_one() and copy_nonpresent_pte().

Move it into mm_prepare_for_swap_entries() in mm/internal.h and convert both callers so it can be reused by upcoming PMD-level swap entry code paths that also need to register the mm with swapoff.

copy_nonpresent_pte() previously inserted into &src_mm->mmlist rather than &init_mm.mmlist, but the insertion point is irrelevant, mmlist is a circular list and swapoff walks it entirely from init_mm.mmlist, so only membership matters, not position.

Reviewed-by Dev Jain <[email protected]>

Reviewed-by Zi Yan <[email protected]>

Signed-off-by Usama Arif <[email protected]>

---
 mm/internal.h | 13 +++++++++++++
 mm/memory.c   |  9 +--------
 mm/rmap.c     |  7 +------
 3 files changed, 15 insertions(+), 14 deletions(-)

mm/internal.h +0 -0

index 8e0df3d1c6f9..0e3db9451e5c 100644

migrate_vma_collect_pmd() calls softleaf_to_folio() on a non-present PMD before checking the entry's type. softleaf_to_folio() converts the entry's offset to a PFN, which is only meaningful for migration or device-private entries.

A PMD swap entry's offset is a swap offset, not a PFN, so the lookup would either return a bogus folio pointer or trip pfn_to_page validation on a debug kernel. In the non-device-private path the returned folio is then unused (the OR short-circuits to migrate_vma_collect_skip()), but the lookup itself is already unsafe.

Move the softleaf_to_folio() call inside the device-private branch where the folio is actually needed, mirroring the equivalent change_non_present_huge_pmd() fix.

Reviewed-by Zi Yan <[email protected]>

Signed-off-by Usama Arif <[email protected]>

---
 mm/migrate_device.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

mm/migrate_device.c +0 -4

index aa948db49501..36287e958b2a 100644
@@ -166,11 +166,14 @@ static int migrate_vma_collect_huge_pmd(pmd_t *pmdp, unsigned long start,
 	} else if (!pmd_present(*pmdp)) {
 		const softleaf_t entry = softleaf_from_pmd(*pmdp);
 
-		folio = softleaf_to_folio(entry);
-
 		if (!softleaf_is_device_private(entry) ||
-			!(migrate->flags & MIGRATE_VMA_SELECT_DEVICE_PRIVATE) ||
-			(folio->pgmap->owner != migrate->pgmap_owner)) {

CONFIG_ARCH_ENABLE_THP_MIGRATION started life gating just PMD-level migration entries, but has grown to gate the entire PMD-level softleaf
machinery: migration entries, device-private entries, and soon swap entries.

Rename CONFIG_ARCH_ENABLE_THP_MIGRATION to CONFIG_ARCH_SUPPORTS_PMD _SOFTLEAF to make this clear. This is a pure rename: the set of selecting architectures (x86, arm64, s390, riscv, loongarch, and powerpc on PPC_BOOK3S_64) and the gating semantics are unchanged.

Quoted 4 lines · Usama Arif

CONFIG_ARCH_ENABLE_THP_MIGRATION started life gating just PMD-level migration entries, but has grown to gate the entire PMD-level softleaf
machinery: migration entries, device-private entries, and soon swap entries.

device-private really relies on migration support.

See do_huge_pmd_device_private() where we migrate back to CPU memory.

The whole concept is pased on migration. So that's why it currently makes sense.

So "has grown to" is not quite accurate. It's a different story with swap entries (that can exist even without migration support).

Quoted 4 lines

Rename CONFIG_ARCH_ENABLE_THP_MIGRATION to CONFIG_ARCH_SUPPORTS_PMD _SOFTLEAF to make this clear. This is a pure rename: the set of selecting architectures (x86, arm64, s390, riscv, loongarch, and powerpc on PPC_BOOK3S_64) and the gating semantics are unchanged.

Hm, that makes me wonder what it would take to make this all just be implicitly supported by CONFIG_TRANSPARENT_HUGEPAGE.

Looks like someone would have the courage to touch stuff like arc, mips and sparc64 (+arm and x86, but that's less of a concern :) ).

Quoted 24 lines · David Hildenbrand (Arm)

Quoted 4 lines · Usama Arif

CONFIG_ARCH_ENABLE_THP_MIGRATION started life gating just PMD-level migration entries, but has grown to gate the entire PMD-level softleaf
machinery: migration entries, device-private entries, and soon swap entries.

device-private really relies on migration support.

See do_huge_pmd_device_private() where we migrate back to CPU memory.

The whole concept is pased on migration. So that's why it currently makes sense.

So "has grown to" is not quite accurate. It's a different story with swap entries (that can exist even without migration support).

Quoted 4 lines

Rename CONFIG_ARCH_ENABLE_THP_MIGRATION to CONFIG_ARCH_SUPPORTS_PMD _SOFTLEAF to make this clear. This is a pure rename: the set of selecting architectures (x86, arm64, s390, riscv, loongarch, and powerpc on PPC_BOOK3S_64) and the gating semantics are unchanged.

Hm, that makes me wonder what it would take to make this all just be implicitly supported by CONFIG_TRANSPARENT_HUGEPAGE.

Quoted 2 lines

Looks like someone would have the courage to touch stuff like arc, mips and sparc64 (+arm and x86, but that's less of a concern :) ).

You mean me back in 2018[1]? ;)

At least I got a no go for s390.

Quoted 26 lines · Zi Yan

Quoted 24 lines · David Hildenbrand (Arm)

Quoted 4 lines · Usama Arif

CONFIG_ARCH_ENABLE_THP_MIGRATION started life gating just PMD-level migration entries, but has grown to gate the entire PMD-level softleaf
machinery: migration entries, device-private entries, and soon swap entries.

device-private really relies on migration support.

See do_huge_pmd_device_private() where we migrate back to CPU memory.

The whole concept is pased on migration. So that's why it currently makes sense.

So "has grown to" is not quite accurate. It's a different story with swap entries (that can exist even without migration support).

Quoted 4 lines

Rename CONFIG_ARCH_ENABLE_THP_MIGRATION to CONFIG_ARCH_SUPPORTS_PMD _SOFTLEAF to make this clear. This is a pure rename: the set of selecting architectures (x86, arm64, s390, riscv, loongarch, and powerpc on PPC_BOOK3S_64) and the gating semantics are unchanged.

Hm, that makes me wonder what it would take to make this all just be implicitly supported by CONFIG_TRANSPARENT_HUGEPAGE.

Quoted 6 lines

Quoted 2 lines

Looks like someone would have the courage to touch stuff like arc, mips and sparc64 (+arm and x86, but that's less of a concern :) ).

You mean me back in 2018[1]? ;)

At least I got a no go for s390.

hah! and 8 years later it seems to exist upstream :)

commit 10dd5a0009898ba35eafeb6087e5c83b84742ff1

Author: Gerald Schaefer <[email protected]>
Date:   Tue Jul 29 13:16:19 2025 +0200

s390/mm: Enable THP_SWAP and THP_MIGRATION

After hugetlbfs PTE_MARKER support for s390 introduced region-third and segment table swap entries, it is now possible to also enable THP_SWAP and THP_MIGRATION for s390.

So, with that out of the way, could you revive your patchset?

Quoted 4 lines · Usama Arif

CONFIG_ARCH_ENABLE_THP_MIGRATION started life gating just PMD-level migration entries, but has grown to gate the entire PMD-level softleaf
machinery: migration entries, device-private entries, and soon swap entries.

device-private really relies on migration support.

See do_huge_pmd_device_private() where we migrate back to CPU memory.

The whole concept is pased on migration. So that's why it currently makes sense.

So "has grown to" is not quite accurate. It's a different story with swap entries (that can exist even without migration support).

Quoted 4 lines

Rename CONFIG_ARCH_ENABLE_THP_MIGRATION to CONFIG_ARCH_SUPPORTS_PMD _SOFTLEAF to make this clear. This is a pure rename: the set of selecting architectures (x86, arm64, s390, riscv, loongarch, and powerpc on PPC_BOOK3S_64) and the gating semantics are unchanged.

Hm, that makes me wonder what it would take to make this all just be implicitly supported by CONFIG_TRANSPARENT_HUGEPAGE.

Looks like someone would have the courage to touch stuff like arc, mips and sparc64 (+arm and x86, but that's less of a concern :) ).

So yeah, renaming the config option makes sense. The config space is the wild west.

We have

PGTABLE_HAS_HUGE_LEAVES

and stuff like

HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
HAVE_ARCH_SOFT_DIRTY
ARCH_HAS_GIGANTIC_PAGE
ARCH_HAS_PTE_SPECIAL

We do have a limited number of "SUPPORTS" (which is longer than HAS), but I would either use

ARCH_HAS_PMD_SOFTLEAVES

or

HAVE_ARCH_PMD_SOFTLEAVES

Apart from that LGTM.

--
Cheers,

David

This is the preparatory part of the PMD page table swapin work.

Quoted 1 line · On Tue, 30 Jun 2026 09:34:37 -0700 Usama Arif <[email protected]> wrote:

This is the preparatory part of the PMD page table swapin work.

Thanks.

This comes reasonably reviewed, so I'll queue it in mm-new.

Why?

- Human review coverage and AI review make me believe this isn't the final version at all, but I do believe this is something we want in 7.2, and getting it under test early will help to push it along.

- Getting it in there early means that others will base their work on material which will probably be upstreamed this cycle, so this gives them a more accurate base against which to work.

Sashiko did find a lot to talk about, some of it pre-existing so can people who work on this code please take a look at

	https://sashiko.dev/#/patchset/[email protected]

Quoted 21 lines · Andrew Morton

Quoted 1 line · On Tue, 30 Jun 2026 09:34:37 -0700 Usama Arif <[email protected]> wrote:

This is the preparatory part of the PMD page table swapin work.

Thanks.

This comes reasonably reviewed, so I'll queue it in mm-new.

Why?

- Human review coverage and AI review make me believe this isn't the final version at all, but I do believe this is something we want in 7.2, and getting it under test early will help to push it along.

- Getting it in there early means that others will base their work on material which will probably be upstreamed this cycle, so this gives them a more accurate base against which to work.

Sashiko did find a lot to talk about, some of it pre-existing so can people who work on this code please take a look at

Quoted 3 lines

	https://sashiko.dev/#/patchset/[email protected]

Hm, my understanding was that mm-new is where we take everything submitted for early testing?

Did something change?

Generally anything submitted early in the cycle is expected to land in the cycle unless there's significant adverse review or other reasons it can't be taken.

Quoted 26 lines · On Wed, 1 Jul 2026 09:04:33 +0100 Lorenzo Stoakes <[email protected]> wrote:

Quoted 24 lines · Andrew Morton

Quoted 1 line · On Tue, 30 Jun 2026 09:34:37 -0700 Usama Arif <[email protected]> wrote:

This is the preparatory part of the PMD page table swapin work.

Thanks.

This comes reasonably reviewed, so I'll queue it in mm-new.

Why?

- Human review coverage and AI review make me believe this isn't the final version at all, but I do believe this is something we want in 7.2, and getting it under test early will help to push it along.

- Getting it in there early means that others will base their work on material which will probably be upstreamed this cycle, so this gives them a more accurate base against which to work.

Sashiko did find a lot to talk about, some of it pre-existing so can people who work on this code please take a look at

	https://sashiko.dev/#/patchset/[email protected]

Quoted 4 lines

Hm, my understanding was that mm-new is where we take everything submitted for early testing?

Did something change?

mm-new has always been a few day front-end to mm-unstable. To protect linux-next from brand new material. It serves no other purpose.

Almost. I'll very occasionally use it for short-term not-for-upstream playthings.

Quoted 2 lines

Generally anything submitted early in the cycle is expected to land in the cycle unless there's significant adverse review or other reasons it can't be taken.

Yup. Don't want anything in mm.git which isn't expected to be upstreamed in the next merge window.

Nowadays I'm reluctant to add anything which hasn't had a decent scan from reviewers. If it's something I'd particularly like to get upstreamed I'll very occasionally add it early, to help push it along.

+cc Mike re: CI.

Quoted 33 lines · Andrew Morton

Quoted 30 lines · On Wed, 1 Jul 2026 09:04:33 +0100 Lorenzo Stoakes <[email protected]> wrote:

Quoted 14 lines · Andrew Morton

Quoted 1 line · On Tue, 30 Jun 2026 09:34:37 -0700 Usama Arif <[email protected]> wrote:

This is the preparatory part of the PMD page table swapin work.

Thanks.

This comes reasonably reviewed, so I'll queue it in mm-new.

Why?

- Human review coverage and AI review make me believe this isn't the final version at all, but I do believe this is something we want in 7.2, and getting it under test early will help to push it along.

Quoted 10 lines

- Getting it in there early means that others will base their work on material which will probably be upstreamed this cycle, so this gives them a more accurate base against which to work.

Sashiko did find a lot to talk about, some of it pre-existing so can people who work on this code please take a look at

	https://sashiko.dev/#/patchset/[email protected]

Hm, my understanding was that mm-new is where we take everything submitted for early testing?

Did something change?

Quoted 2 lines

mm-new has always been a few day front-end to mm-unstable. To protect linux-next from brand new material. It serves no other purpose.

Well it only serves a purpose if it gives us better testing.

We have a CI running tests now though, Mike - is that predicated on material being in mm-new or does it just grab the email?

If the CI is just grabbing email I wonder whether there's much purpose in the mm-new branch at all.

Thanks, Lorenzo

Quoted 4 lines · Lorenzo Stoakes

+cc Mike re: CI.

Quoted 1 line · Andrew Morton

On Wed, 1 Jul 2026 09:04:33 +0100 Lorenzo Stoakes <[email protected]> wrote:

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

Hm, my understanding was that mm-new is where we take everything submitted for early testing?

Did something change?

Quoted 7 lines

Quoted 2 lines

mm-new has always been a few day front-end to mm-unstable. To protect linux-next from brand new material. It serves no other purpose.

Well it only serves a purpose if it gives us better testing.

We have a CI running tests now though, Mike - is that predicated on material being in mm-new or does it just grab the email?

CI grabs patches from patchwork and tries to apply them to one of the three
bases: mm-unstable, mm-new or the latest Linus' commit merged into mm.git.

If patches apply, the other bases are not checked.

This patches applied cleanly to mm-unstable and successfully passed (at least once :) )
https://github.com/linux-mm/linux-mm/actions/runs/28544575927/

Quoted 2 lines

If the CI is just grabbing email I wonder whether there's much purpose in the mm-new branch at all.

I can't say that CI I run has a great coverage. I don't know what coverage mm-new has though

Quoted 2 lines

Thanks, Lorenzo

--
Sincerely yours,
Mike.

Quoted 2 lines · Mike Rapoport

I can't say that CI I run has a great coverage. I don't know what coverage mm-new has though

Well we're very grateful for what coverage it has :) and that's nice to have it work with email like that also, makes life simpler.

Mark - are you running tests based on mm-new? I'm not sure where things stand on that?

Quoted 4 lines · Lorenzo Stoakes

Quoted 2 lines · Mike Rapoport

I can't say that CI I run has a great coverage. I don't know what coverage mm-new has though

Quoted 5 lines

Well we're very grateful for what coverage it has :) and that's nice to have it work with email like that also, makes life simpler.

Mark - are you running tests based on mm-new? I'm not sure where things stand on that?

I currently test -next, mainline and stable plus my own stuff.

Quoted 10 lines · Mark Brown

Quoted 5 lines · Lorenzo Stoakes

Well we're very grateful for what coverage it has :) and that's nice to have it work with email like that also, makes life simpler.

Mark - are you running tests based on mm-new? I'm not sure where things stand on that?

I currently test -next, mainline and stable plus my own stuff.

Ack thanks!

I guess in the long run then we can figure out a way to not necessarily even require mm-new at all, and instead let our CI try to handle as much as it can before -> linux-next :)

As that'd be the nicest way and help reduce confusion about branches for mm-next.

Quoted 18 lines · Lorenzo Stoakes

Quoted 10 lines · Mark Brown

Quoted 5 lines · Lorenzo Stoakes

Well we're very grateful for what coverage it has :) and that's nice to have it work with email like that also, makes life simpler.

Mark - are you running tests based on mm-new? I'm not sure where things stand on that?

I currently test -next, mainline and stable plus my own stuff.

Ack thanks!

I guess in the long run then we can figure out a way to not necessarily even require mm-new at all, and instead let our CI try to handle as much as it can before -> linux-next :)

Quoted 2 lines

As that'd be the nicest way and help reduce confusion about branches for mm-next.

If we go the for-test route, we'd still have a branch where people/bots/tools can do more elaborate tests when throwing stuff together. I still consider that reasonable, but we'll have to see if we really need that.

--
Cheers,

David

Quoted 36 lines · Lorenzo Stoakes

+cc Mike re: CI.

Quoted 33 lines · Andrew Morton

Quoted 30 lines · On Wed, 1 Jul 2026 09:04:33 +0100 Lorenzo Stoakes <[email protected]> wrote:

Quoted 14 lines · Andrew Morton

Quoted 1 line · On Tue, 30 Jun 2026 09:34:37 -0700 Usama Arif <[email protected]> wrote:

This is the preparatory part of the PMD page table swapin work.

Thanks.

This comes reasonably reviewed, so I'll queue it in mm-new.

Why?

- Human review coverage and AI review make me believe this isn't the final version at all, but I do believe this is something we want in 7.2, and getting it under test early will help to push it along.

Quoted 10 lines

- Getting it in there early means that others will base their work on material which will probably be upstreamed this cycle, so this gives them a more accurate base against which to work.

Sashiko did find a lot to talk about, some of it pre-existing so can people who work on this code please take a look at

	https://sashiko.dev/#/patchset/[email protected]

Hm, my understanding was that mm-new is where we take everything submitted for early testing?

Did something change?

Quoted 7 lines

Quoted 2 lines

mm-new has always been a few day front-end to mm-unstable. To protect linux-next from brand new material. It serves no other purpose.

Well it only serves a purpose if it gives us better testing.

We have a CI running tests now though, Mike - is that predicated on material being in mm-new or does it just grab the email?

CI grabs patches from patchwork and tries to apply them to one of the three
bases: mm-unstable, mm-new or the latest Linus' commit merged into mm.git.

If patches apply, the other bases are not checked.

This patches applied cleanly to mm-unstable and successfully passed (at least once :) )
https://github.com/linux-mm/linux-mm/actions/runs/28544575927/

Quoted 6 lines · On Thu, 2 Jul 2026 16:08:03 +0300 Mike Rapoport <[email protected]> wrote:

CI grabs patches from patchwork and tries to apply them to one of the three
bases: mm-unstable, mm-new or the latest Linus' commit merged into mm.git.

If patches apply, the other bases are not checked.

Quoted 3 lines

This patches applied cleanly to mm-unstable and successfully passed (at least once :) )
https://github.com/linux-mm/linux-mm/actions/runs/28544575927/

Awesome!

I found the CI script (mm-ci) on the GitHub organization. Is the repo open to contributions?

If so, between GitHub PR and patches to linux-mm@ what is more preferred?

Seems it is not running DAMON specific tests, and I want to add DAMON kunit test to the test set as a first step (DAMO selftest is bit flaky on some systems), if people don't mind.

I or someone else may also want to add more tests like Cc list checking [1] in future.

[1] https://lore.kernel.org/[email protected]

Thanks,
SJ

Hi SJ,

Quoted 7 lines · SJ Park

Quoted 6 lines · On Thu, 2 Jul 2026 16:08:03 +0300 Mike Rapoport <[email protected]> wrote:

CI grabs patches from patchwork and tries to apply them to one of the three
bases: mm-unstable, mm-new or the latest Linus' commit merged into mm.git.

If patches apply, the other bases are not checked.

Quoted 8 lines

Quoted 3 lines

This patches applied cleanly to mm-unstable and successfully passed (at least once :) )
https://github.com/linux-mm/linux-mm/actions/runs/28544575927/

Awesome!

I found the CI script (mm-ci) on the GitHub organization. Is the repo open to contributions?

Yes :)

Quoted 2 lines

If so, between GitHub PR and patches to linux-mm@ what is more preferred?

The way it works, all testing update should go to mm-ci. There is a bot that takes them from there and generates PRs inn linux-mm that include patches and the CI files.

Quoted 4 lines

Seems it is not running DAMON specific tests, and I want to add DAMON kunit test to the test set as a first step (DAMO selftest is bit flaky on some systems), if people don't mind.

Patches are welcome :)

If DAMON selftest is flaky let's keep it out for now please, otherwise it would cause too much noise.

Quoted 5 lines

I or someone else may also want to add more tests like Cc list checking [1] in future.

[1] https://lore.kernel.org/[email protected]

Yeah, I think it would be helpful.

Quoted 1 line · On Tue, 30 Jun 2026 09:34:37 -0700 Usama Arif <[email protected]> wrote:

This is the preparatory part of the PMD page table swapin work.

Thanks.

This comes reasonably reviewed, so I'll queue it in mm-new.

Why?

- Human review coverage and AI review make me believe this isn't the final version at all, but I do believe this is something we want in 7.2, and getting it under test early will help to push it along.

- Getting it in there early means that others will base their work on material which will probably be upstreamed this cycle, so this gives them a more accurate base against which to work.

Sashiko did find a lot to talk about, some of it pre-existing so can people who work on this code please take a look at

	https://sashiko.dev/#/patchset/[email protected]

Quoted 1 line · On Tue, 30 Jun 2026 09:34:37 -0700 Usama Arif <[email protected]> wrote:

This is the preparatory part of the PMD page table swapin work.

Thanks.

This comes reasonably reviewed, so I'll queue it in mm-new.

Why?

- Human review coverage and AI review make me believe this isn't the final version at all, but I do believe this is something we want in 7.2, and getting it under test early will help to push it along.

- Getting it in there early means that others will base their work on material which will probably be upstreamed this cycle, so this gives them a more accurate base against which to work.

Sashiko did find a lot to talk about, some of it pre-existing so can people who work on this code please take a look at

	https://sashiko.dev/#/patchset/[email protected]

This is the preparatory part of the PMD page table swapin work. The full PMD swap entry series has been split into two parts:

1. this preparatory series, which contains the first 6 patches. Zi [1] and Lance [2] suggested to separate this out from the core series.
2. the PMD swap entry core series, which depends on this one. I will send this once the preparatory series is merged in mm-new as v3 as the combined is currently at v2 [1].
I have not marked this prep series as v3, as its not really adding support for PMD swap entries.

This series does not introduce PMD swap entries and does not install any new page-table entry type. It only cleans up existing PMD softleaf helpers and call sites so the follow-up PMD swap entry series can be smaller and easier to review.

It should be safe to merge independently.

This is the preparatory part of the PMD page table swapin work. The full PMD swap entry series has been split into two parts:

1. this preparatory series, which contains the first 6 patches. Zi [1] and Lance [2] suggested to separate this out from the core series.
2. the PMD swap entry core series, which depends on this one. I will send this once the preparatory series is merged in mm-new as v3 as the combined is currently at v2 [1].
I have not marked this prep series as v3, as its not really adding support for PMD swap entries.

This series does not introduce PMD swap entries and does not install any new page-table entry type. It only cleans up existing PMD softleaf helpers and call sites so the follow-up PMD swap entry series can be smaller and easier to review.

Quoted 11 lines · On Tue, 30 Jun 2026 09:34:37 -0700 Usama Arif <[email protected]> wrote:

This is the preparatory part of the PMD page table swapin work. The full PMD swap entry series has been split into two parts:

1. this preparatory series, which contains the first 6 patches. Zi [1] and Lance [2] suggested to separate this out from the core series.
2. the PMD swap entry core series, which depends on this one. I will send this once the preparatory series is merged in mm-new as v3 as the combined is currently at v2 [1].
I have not marked this prep series as v3, as its not really adding support for PMD swap entries.

Quoted 5 lines

This series does not introduce PMD swap entries and does not install any new page-table entry type. It only cleans up existing PMD softleaf helpers and call sites so the follow-up PMD swap entry series can be smaller and easier to review.

Hi Andrew,

The series only needs 2 small changes:

Removing a comment:
https://lore.kernel.org/all/[email protected]/

and s/CONFIG_ARCH_SUPPORTS_PMD/CONFIG_ARCH_HAS_PMD_SOFTLEAVES/ in the last patch:
https://lore.kernel.org/all/[email protected]/

I am always torn between sending a fixlet on the existing series or a new revision.
Just wanted to check what is easiest for you and your preference in situations like above?