There's an established convention in the kernel that we treat leaf page
tables (so far at the PTE, PMD level) as containing 'swap entries' should
they be neither empty (i.e. p**_none() evaluating true) nor present
(i.e. p**_present() evaluating true).

However, at the same time we also have helper predicates - is_swap_pte(),
is_swap_pmd() - which are inconsistently used.

This is problematic, as it is logical to assume that should somebody wish
to operate upon a page table swap entry they should first check to see if
it is in fact one.

It also implies that perhaps, in future, we might introduce a non-present,
none page table entry that is not a swap entry.

This series resolves this issue by systematically eliminating all use of
the is_swap_pte() and is swap_pmd() predicates so we retain only the
convention that should a leaf page table entry be neither none nor present
it is a swap entry.

We also have the further issue that 'swap entry' is unfortunately a really
rather overloaded term and in fact refers to both entries for swap and for
other information such as migration entries, page table markers, and device
private entries.

We therefore have the rather 'unique' concept of a 'non-swap' swap entry.

This series therefore introduces the concept of 'software leaf entries', of
type softleaf_t, to eliminate this confusion.

A software leaf entry in this sense is any page table entry which is
non-present, and represented by the softleaf_t type. That is - page table
leaf entries which are software-controlled by the kernel.

This includes 'none' or empty entries, which are simply represented by an
zero leaf entry value.

In order to maintain compatibility as we transition the kernel to this new
type, we simply typedef swp_entry_t to softleaf_t.

We introduce a number of predicates and helpers to interact with software
leaf entries in include/linux/leafops.h which, as it imports swapops.h, can
be treated as a drop-in replacement for swapops.h wherever leaf entry
helpers are used.

Since softleaf_from_[pte, pmd]() treats present entries as they were
empty/none leaf entries, this allows for a great deal of simplification of
code throughout the code base, which this series utilises a great deal.

We additionally change from swap entry to software leaf entry handling
where it makes sense to and eliminate functions from swapops.h where
software leaf entries obviate the need for the functions.


v2:
* Folded all fixpatches into patches they fix.
* Added Vlasta's tag to patch 1 (thanks!)
* Renamed leaf_entry_t to softleaf_t and leafent_xxx() to softleaf_xxx() as
  a result of discussion between Matthew, Jason, David, Gregory & myself to
  make clearer that we abstract the concept of a software page table leaf
  entry.
* Updated all commit messages to reference softleaves.
* Updated the kdoc comment describing softleaf_t to provide more detail.
* Added a description of softleaves to the top of leafops.h.

non-RFC v1:
* As part of efforts to eliminate swp_entry_t usage, remove
  pte_none_mostly() and correct UFFD PTE marker handling.
* Introduce leaf_entry_t - credit to Gregory for naming, and to Jason for
  the concept of simply using a leafent_*() set of functions to interact
  with these entities.
* Replace pte_to_swp_entry_or_zero() with leafent_from_pte() and simply
  categorise pte_none() cases as an empty leaf entry, as per Jason.
* Eliminate get_pte_swap_entry() - as we can simply do this with
  leafent_from_pte() also, as discussed with Jason.
* Put pmd_trans_huge_lock() acquisition/release in pagemap_pmd_range()
  rather than pmd_trans_huge_lock_thp() as per Gregory.
* Eliminate pmd_to_swp_entry() and related and introduce leafent_from_pmd()
  to replace it and further propagate leaf entry usage.
* Remove the confusing and unnecessary is_hugetlb_entry_[migration,
  hwpoison]() functions.
* Replace is_pfn_swap_entry(), pfn_swap_entry_to_page(),
  is_writable_device_private_entry(), is_device_exclusive_entry(),
  is_migration_entry(), is_writable_migration_entry(),
  is_readable_migration_entry(), is_readable_exclusive_migration_entry()
  and pfn_swap_entry_folio() with leafent equivalents.
* Wrapped up the 'safe' behaviour discussed with Jason in
  leafent_from_[pte, pmd]() so these can be used unconditionally which
  simplifies things a lot.
* Further changes that are a consequence of the introduction of leaf
  entries.
https://lore.kernel.org/all/cover.1762171281.git.lorenzo.stoakes@oracle.com/

RFC:
https://lore.kernel.org/all/cover.1761288179.git.lorenzo.stoakes@oracle.com/

Lorenzo Stoakes (16):
  mm: correctly handle UFFD PTE markers
  mm: introduce leaf entry type and use to simplify leaf entry logic
  mm: avoid unnecessary uses of is_swap_pte()
  mm: eliminate is_swap_pte() when softleaf_from_pte() suffices
  mm: use leaf entries in debug pgtable + remove is_swap_pte()
  fs/proc/task_mmu: refactor pagemap_pmd_range()
  mm: avoid unnecessary use of is_swap_pmd()
  mm/huge_memory: refactor copy_huge_pmd() non-present logic
  mm/huge_memory: refactor change_huge_pmd() non-present logic
  mm: replace pmd_to_swp_entry() with softleaf_from_pmd()
  mm: introduce pmd_is_huge() and use where appropriate
  mm: remove remaining is_swap_pmd() users and is_swap_pmd()
  mm: remove non_swap_entry() and use softleaf helpers instead
  mm: remove is_hugetlb_entry_[migration, hwpoisoned]()
  mm: eliminate further swapops predicates
  mm: replace remaining pte_to_swp_entry() with softleaf_from_pte()

 MAINTAINERS                   |   1 +
 arch/s390/mm/gmap_helpers.c   |  20 +-
 arch/s390/mm/pgtable.c        |  12 +-
 fs/proc/task_mmu.c            | 294 +++++++++-------
 fs/userfaultfd.c              |  85 ++---
 include/asm-generic/hugetlb.h |   8 -
 include/linux/huge_mm.h       |  48 ++-
 include/linux/hugetlb.h       |   2 -
 include/linux/leafops.h       | 620 ++++++++++++++++++++++++++++++++++
 include/linux/migrate.h       |   2 +-
 include/linux/mm_inline.h     |   6 +-
 include/linux/mm_types.h      |  25 ++
 include/linux/swapops.h       | 273 +--------------
 include/linux/userfaultfd_k.h |  33 +-
 mm/damon/ops-common.c         |   6 +-
 mm/debug_vm_pgtable.c         |  86 +++--
 mm/filemap.c                  |   8 +-
 mm/hmm.c                      |  36 +-
 mm/huge_memory.c              | 263 +++++++-------
 mm/hugetlb.c                  | 165 ++++-----
 mm/internal.h                 |  20 +-
 mm/khugepaged.c               |  33 +-
 mm/ksm.c                      |   6 +-
 mm/madvise.c                  |  28 +-
 mm/memory-failure.c           |   8 +-
 mm/memory.c                   | 150 ++++----
 mm/mempolicy.c                |  25 +-
 mm/migrate.c                  |  45 +--
 mm/migrate_device.c           |  24 +-
 mm/mincore.c                  |  25 +-
 mm/mprotect.c                 |  59 ++--
 mm/mremap.c                   |  13 +-
 mm/page_table_check.c         |  33 +-
 mm/page_vma_mapped.c          |  65 ++--
 mm/pagewalk.c                 |  15 +-
 mm/rmap.c                     |  17 +-
 mm/shmem.c                    |   7 +-
 mm/swap_state.c               |  12 +-
 mm/swapfile.c                 |  14 +-
 mm/userfaultfd.c              |  53 +--
 40 files changed, 1560 insertions(+), 1085 deletions(-)
 create mode 100644 include/linux/leafops.h

--
2.51.0

On Sat,  8 Nov 2025 17:08:14 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:

> There's an established convention in the kernel that we treat leaf page
> tables (so far at the PTE, PMD level) as containing 'swap entries' should
> they be neither empty (i.e. p**_none() evaluating true) nor present
> (i.e. p**_present() evaluating true).
> 
> However, at the same time we also have helper predicates - is_swap_pte(),
> is_swap_pmd() - which are inconsistently used.
> 
> This is problematic, as it is logical to assume that should somebody wish
> to operate upon a page table swap entry they should first check to see if
> it is in fact one.
> 
> It also implies that perhaps, in future, we might introduce a non-present,
> none page table entry that is not a swap entry.
> 
> This series resolves this issue by systematically eliminating all use of
> the is_swap_pte() and is swap_pmd() predicates so we retain only the
> convention that should a leaf page table entry be neither none nor present
> it is a swap entry.

Thanks, I've updated mm.git's mm-unstable branch to this v2 series.

On Sat, Nov 8, 2025 at 9:09 AM Lorenzo Stoakes
<lorenzo.stoakes@oracle.com> wrote:
>
> There's an established convention in the kernel that we treat leaf page
> tables (so far at the PTE, PMD level) as containing 'swap entries' should
> they be neither empty (i.e. p**_none() evaluating true) nor present
> (i.e. p**_present() evaluating true).
>
> However, at the same time we also have helper predicates - is_swap_pte(),
> is_swap_pmd() - which are inconsistently used.
>
> This is problematic, as it is logical to assume that should somebody wish
> to operate upon a page table swap entry they should first check to see if
> it is in fact one.
>
> It also implies that perhaps, in future, we might introduce a non-present,
> none page table entry that is not a swap entry.
>
> This series resolves this issue by systematically eliminating all use of
> the is_swap_pte() and is swap_pmd() predicates so we retain only the
> convention that should a leaf page table entry be neither none nor present
> it is a swap entry.
>
> We also have the further issue that 'swap entry' is unfortunately a really
> rather overloaded term and in fact refers to both entries for swap and for
> other information such as migration entries, page table markers, and device
> private entries.
>
> We therefore have the rather 'unique' concept of a 'non-swap' swap entry.
>
> This series therefore introduces the concept of 'software leaf entries', of
> type softleaf_t, to eliminate this confusion.
>
> A software leaf entry in this sense is any page table entry which is
> non-present, and represented by the softleaf_t type. That is - page table
> leaf entries which are software-controlled by the kernel.
>
> This includes 'none' or empty entries, which are simply represented by an
> zero leaf entry value.
>
> In order to maintain compatibility as we transition the kernel to this new
> type, we simply typedef swp_entry_t to softleaf_t.

Hi Lorenzo,

Sorry I was late to the party. Can you clarify that you intend to
remove swp_entry_t completely to softleaf_t?
I think for the traditional usage of the swp_entry_t, which is made up
of swap device type and swap device offset. Can we please keep the
swp_entry_t for the traditional swap system usage? The mix type can
stay in softleaf_t in the pte level.

I kind of wish the swap system could still use swp_entry_t. At least I
don't see any complete reason to massively rename all the swap system
code if we already know the entry is the limited meaning of swap entry
(device + offset).

Timing is not great either. We have the swap table phase II on review
now. There is also phase III and phase IV on the backlog pipeline. All
this renaming can create unnecessary conflicts. I am pleading please
reduce the renaming in the swap system code for now until we can
figure out what is the impact to the rest of the swap table series,
which is the heavy lifting for swap right now. I want to draw a line
in the sand that, on the PTE entry side, having multiple meanings, we
can call it softleaft_t whatever. If we know it is the traditional
swap entry meaning. Keep it swp_entry_t for now until we figure out
the real impact.

Does this renaming have any behavior change in the produced machine code?

Chris

>
> We introduce a number of predicates and helpers to interact with software
> leaf entries in include/linux/leafops.h which, as it imports swapops.h, can
> be treated as a drop-in replacement for swapops.h wherever leaf entry
> helpers are used.
>
> Since softleaf_from_[pte, pmd]() treats present entries as they were
> empty/none leaf entries, this allows for a great deal of simplification of
> code throughout the code base, which this series utilises a great deal.
>
> We additionally change from swap entry to software leaf entry handling
> where it makes sense to and eliminate functions from swapops.h where
> software leaf entries obviate the need for the functions.
>
>
> v2:
> * Folded all fixpatches into patches they fix.
> * Added Vlasta's tag to patch 1 (thanks!)
> * Renamed leaf_entry_t to softleaf_t and leafent_xxx() to softleaf_xxx() as
>   a result of discussion between Matthew, Jason, David, Gregory & myself to
>   make clearer that we abstract the concept of a software page table leaf
>   entry.
> * Updated all commit messages to reference softleaves.
> * Updated the kdoc comment describing softleaf_t to provide more detail.
> * Added a description of softleaves to the top of leafops.h.
>
> non-RFC v1:
> * As part of efforts to eliminate swp_entry_t usage, remove
>   pte_none_mostly() and correct UFFD PTE marker handling.
> * Introduce leaf_entry_t - credit to Gregory for naming, and to Jason for
>   the concept of simply using a leafent_*() set of functions to interact
>   with these entities.
> * Replace pte_to_swp_entry_or_zero() with leafent_from_pte() and simply
>   categorise pte_none() cases as an empty leaf entry, as per Jason.
> * Eliminate get_pte_swap_entry() - as we can simply do this with
>   leafent_from_pte() also, as discussed with Jason.
> * Put pmd_trans_huge_lock() acquisition/release in pagemap_pmd_range()
>   rather than pmd_trans_huge_lock_thp() as per Gregory.
> * Eliminate pmd_to_swp_entry() and related and introduce leafent_from_pmd()
>   to replace it and further propagate leaf entry usage.
> * Remove the confusing and unnecessary is_hugetlb_entry_[migration,
>   hwpoison]() functions.
> * Replace is_pfn_swap_entry(), pfn_swap_entry_to_page(),
>   is_writable_device_private_entry(), is_device_exclusive_entry(),
>   is_migration_entry(), is_writable_migration_entry(),
>   is_readable_migration_entry(), is_readable_exclusive_migration_entry()
>   and pfn_swap_entry_folio() with leafent equivalents.
> * Wrapped up the 'safe' behaviour discussed with Jason in
>   leafent_from_[pte, pmd]() so these can be used unconditionally which
>   simplifies things a lot.
> * Further changes that are a consequence of the introduction of leaf
>   entries.
> https://lore.kernel.org/all/cover.1762171281.git.lorenzo.stoakes@oracle.com/
>
> RFC:
> https://lore.kernel.org/all/cover.1761288179.git.lorenzo.stoakes@oracle.com/
>
> Lorenzo Stoakes (16):
>   mm: correctly handle UFFD PTE markers
>   mm: introduce leaf entry type and use to simplify leaf entry logic
>   mm: avoid unnecessary uses of is_swap_pte()
>   mm: eliminate is_swap_pte() when softleaf_from_pte() suffices
>   mm: use leaf entries in debug pgtable + remove is_swap_pte()
>   fs/proc/task_mmu: refactor pagemap_pmd_range()
>   mm: avoid unnecessary use of is_swap_pmd()
>   mm/huge_memory: refactor copy_huge_pmd() non-present logic
>   mm/huge_memory: refactor change_huge_pmd() non-present logic
>   mm: replace pmd_to_swp_entry() with softleaf_from_pmd()
>   mm: introduce pmd_is_huge() and use where appropriate
>   mm: remove remaining is_swap_pmd() users and is_swap_pmd()
>   mm: remove non_swap_entry() and use softleaf helpers instead
>   mm: remove is_hugetlb_entry_[migration, hwpoisoned]()
>   mm: eliminate further swapops predicates
>   mm: replace remaining pte_to_swp_entry() with softleaf_from_pte()
>
>  MAINTAINERS                   |   1 +
>  arch/s390/mm/gmap_helpers.c   |  20 +-
>  arch/s390/mm/pgtable.c        |  12 +-
>  fs/proc/task_mmu.c            | 294 +++++++++-------
>  fs/userfaultfd.c              |  85 ++---
>  include/asm-generic/hugetlb.h |   8 -
>  include/linux/huge_mm.h       |  48 ++-
>  include/linux/hugetlb.h       |   2 -
>  include/linux/leafops.h       | 620 ++++++++++++++++++++++++++++++++++
>  include/linux/migrate.h       |   2 +-
>  include/linux/mm_inline.h     |   6 +-
>  include/linux/mm_types.h      |  25 ++
>  include/linux/swapops.h       | 273 +--------------
>  include/linux/userfaultfd_k.h |  33 +-
>  mm/damon/ops-common.c         |   6 +-
>  mm/debug_vm_pgtable.c         |  86 +++--
>  mm/filemap.c                  |   8 +-
>  mm/hmm.c                      |  36 +-
>  mm/huge_memory.c              | 263 +++++++-------
>  mm/hugetlb.c                  | 165 ++++-----
>  mm/internal.h                 |  20 +-
>  mm/khugepaged.c               |  33 +-
>  mm/ksm.c                      |   6 +-
>  mm/madvise.c                  |  28 +-
>  mm/memory-failure.c           |   8 +-
>  mm/memory.c                   | 150 ++++----
>  mm/mempolicy.c                |  25 +-
>  mm/migrate.c                  |  45 +--
>  mm/migrate_device.c           |  24 +-
>  mm/mincore.c                  |  25 +-
>  mm/mprotect.c                 |  59 ++--
>  mm/mremap.c                   |  13 +-
>  mm/page_table_check.c         |  33 +-
>  mm/page_vma_mapped.c          |  65 ++--
>  mm/pagewalk.c                 |  15 +-
>  mm/rmap.c                     |  17 +-
>  mm/shmem.c                    |   7 +-
>  mm/swap_state.c               |  12 +-
>  mm/swapfile.c                 |  14 +-
>  mm/userfaultfd.c              |  53 +--
>  40 files changed, 1560 insertions(+), 1085 deletions(-)
>  create mode 100644 include/linux/leafops.h
>
> --
> 2.51.0

On Sun, Nov 09, 2025 at 11:32:09PM -0800, Chris Li wrote:
> Hi Lorenzo,
>
> Sorry I was late to the party. Can you clarify that you intend to
> remove swp_entry_t completely to softleaf_t?
> I think for the traditional usage of the swp_entry_t, which is made up
> of swap device type and swap device offset. Can we please keep the
> swp_entry_t for the traditional swap system usage? The mix type can
> stay in softleaf_t in the pte level.

Ultimately it doesn't really matter - if we do entirely eliminate
swp_entry_t, the type that we are left with for genuine swap entries will
be _identical_ to swp_entry_t. As in bit-by-bit identical.

But I did think perhaps we could maintain this type explicitly for the
_actual_ swap code.

>
> I kind of wish the swap system could still use swp_entry_t. At least I
> don't see any complete reason to massively rename all the swap system
> code if we already know the entry is the limited meaning of swap entry
> (device + offset).

Well the reason would be because we are trying to keep things consistent
and viewing a swap entry as merely being one of the modes of a softleaf.

However I am empathetic to not wanting to create _entirely_ unnecessary
churn here.

I will actively keep you in the loop on follow up series and obviously will
absolutely take your opinion seriously on this.

I think this series overall hugely improves clarity and additionally avoids
a bunch of unnecessary, duplicative logic that previously was required, so
is well worth the slightly-annoying-churn cost here.

But when it comes to the swap code itself I will try to avoid any
unnecessary noise.

One thing we were considering (discussions on previous iteration of series)
was to have a union of different softleaf types - one of which could simply
be swp_entry_t, meaning we get the best of both worlds, or at least
absolutely minimal changes.

>
> Timing is not great either. We have the swap table phase II on review
> now. There is also phase III and phase IV on the backlog pipeline. All
> this renaming can create unnecessary conflicts. I am pleading please
> reduce the renaming in the swap system code for now until we can
> figure out what is the impact to the rest of the swap table series,
> which is the heavy lifting for swap right now. I want to draw a line
> in the sand that, on the PTE entry side, having multiple meanings, we
> can call it softleaft_t whatever. If we know it is the traditional
> swap entry meaning. Keep it swp_entry_t for now until we figure out
> the real impact.

I really do empathise, having dealt with multiple conflicts and races in
series, however I don't think it's really sensible to delay one series
based on unmerged follow ups.

So this series will proceed as it is.

However I'm more than happy to help resolve conflicts - if you want to send
me any of these series off list etc. I can rebase to mm-new myself if
that'd be helpful?

>
> Does this renaming have any behavior change in the produced machine code?

It shouldn't result in any meaningful change no.

>
> Chris
>

Cheers, Lorenzo

On Mon, Nov 10, 2025 at 2:18 AM Lorenzo Stoakes
<lorenzo.stoakes@oracle.com> wrote:
>
> On Sun, Nov 09, 2025 at 11:32:09PM -0800, Chris Li wrote:
> > Hi Lorenzo,
> >
> > Sorry I was late to the party. Can you clarify that you intend to
> > remove swp_entry_t completely to softleaf_t?
> > I think for the traditional usage of the swp_entry_t, which is made up
> > of swap device type and swap device offset. Can we please keep the
> > swp_entry_t for the traditional swap system usage? The mix type can
> > stay in softleaf_t in the pte level.
>
> Ultimately it doesn't really matter - if we do entirely eliminate
> swp_entry_t, the type that we are left with for genuine swap entries will
> be _identical_ to swp_entry_t. As in bit-by-bit identical.

In that case you might just as well leave it as swp_entry_t for the
_actual_ swap code.

>
> But I did think perhaps we could maintain this type explicitly for the
> _actual_ swap code.

Exactly. Please do consider impact the actual swap

> > I kind of wish the swap system could still use swp_entry_t. At least I
> > don't see any complete reason to massively rename all the swap system
> > code if we already know the entry is the limited meaning of swap entry
> > (device + offset).
>
> Well the reason would be because we are trying to keep things consistent
> and viewing a swap entry as merely being one of the modes of a softleaf.

Your reason applies to the multi-personality non-present pte entries.
I am fine with those as softleaf. However the reasoning does not apply
to the swap entry where we already know it is for actual swap. The
multi-personality does not apply there. I see no conflict with the
swp_entry type there. I argue that it is even cleaner that the swap
codes only refer to those as swp_entry rather than softleaf because
there is no possibility that the swap entry has multi-personality.

> However I am empathetic to not wanting to create _entirely_ unnecessary
> churn here.
>
> I will actively keep you in the loop on follow up series and obviously will
> absolutely take your opinion seriously on this.

Thank you for your consideration.

>
> I think this series overall hugely improves clarity and additionally avoids
> a bunch of unnecessary, duplicative logic that previously was required, so
> is well worth the slightly-annoying-churn cost here.
>
> But when it comes to the swap code itself I will try to avoid any
> unnecessary noise.

Ack.

> One thing we were considering (discussions on previous iteration of series)
> was to have a union of different softleaf types - one of which could simply
> be swp_entry_t, meaning we get the best of both worlds, or at least
> absolutely minimal changes.

If you have a patch I would take a look and comment on it.

> > Timing is not great either. We have the swap table phase II on review
> > now. There is also phase III and phase IV on the backlog pipeline. All
> > this renaming can create unnecessary conflicts. I am pleading please
> > reduce the renaming in the swap system code for now until we can
> > figure out what is the impact to the rest of the swap table series,
> > which is the heavy lifting for swap right now. I want to draw a line
> > in the sand that, on the PTE entry side, having multiple meanings, we
> > can call it softleaft_t whatever. If we know it is the traditional
> > swap entry meaning. Keep it swp_entry_t for now until we figure out
> > the real impact.
>
> I really do empathise, having dealt with multiple conflicts and races in
> series, however I don't think it's really sensible to delay one series
> based on unmerged follow ups.

If you leave the actual swap entry (single personality) alone, I think
we can deal with the merge conflicts.

> So this series will proceed as it is.

Please clarify the "proceed as it is" regarding the actual swap code.
I hope you mean you are continuing your series, maybe with
modifications also consider my feedback. After all, you just say " But
I did think perhaps we could maintain this type explicitly for the
_actual_ swap code."

> However I'm more than happy to help resolve conflicts - if you want to send
> me any of these series off list etc. I can rebase to mm-new myself if
> that'd be helpful?

As I said above, leaving the actual swap code alone is more helpful
and I consider it cleaner as well. We can also look into incremental
change on your V2 to crave out the swap code.

>
> >
> > Does this renaming have any behavior change in the produced machine code?
>
> It shouldn't result in any meaningful change no.

That is actually the reason to give the swap table change more
priority. Just saying.

Chris

On Mon, Nov 10, 2025 at 03:04:48AM -0800, Chris Li wrote:
> On Mon, Nov 10, 2025 at 2:18 AM Lorenzo Stoakes
> <lorenzo.stoakes@oracle.com> wrote:
> >
> > On Sun, Nov 09, 2025 at 11:32:09PM -0800, Chris Li wrote:
> > > Hi Lorenzo,
> > >
> > > Sorry I was late to the party. Can you clarify that you intend to
> > > remove swp_entry_t completely to softleaf_t?
> > > I think for the traditional usage of the swp_entry_t, which is made up
> > > of swap device type and swap device offset. Can we please keep the
> > > swp_entry_t for the traditional swap system usage? The mix type can
> > > stay in softleaf_t in the pte level.
> >
> > Ultimately it doesn't really matter - if we do entirely eliminate
> > swp_entry_t, the type that we are left with for genuine swap entries will
> > be _identical_ to swp_entry_t. As in bit-by-bit identical.
>
> In that case you might just as well leave it as swp_entry_t for the
> _actual_ swap code.
>
> >
> > But I did think perhaps we could maintain this type explicitly for the
> > _actual_ swap code.
>
> Exactly. Please do consider impact the actual swap
>
> > > I kind of wish the swap system could still use swp_entry_t. At least I
> > > don't see any complete reason to massively rename all the swap system
> > > code if we already know the entry is the limited meaning of swap entry
> > > (device + offset).
> >
> > Well the reason would be because we are trying to keep things consistent
> > and viewing a swap entry as merely being one of the modes of a softleaf.
>
> Your reason applies to the multi-personality non-present pte entries.
> I am fine with those as softleaf. However the reasoning does not apply
> to the swap entry where we already know it is for actual swap. The
> multi-personality does not apply there. I see no conflict with the
> swp_entry type there. I argue that it is even cleaner that the swap
> codes only refer to those as swp_entry rather than softleaf because
> there is no possibility that the swap entry has multi-personality.

Swap is one of the 'personalities', very explicitly. Having it this way hugely
cleans up the code.

I'm not sure I really understand your objection given the type will be
bit-by-bit compatible.

I'll deal with this when I come to this follow-up series.

As I said before I'm empathetic to conflicts, but also - this is something we
all have to live with. I have had to deal with numerous conflict fixups. They're
really not all that bad to fix up.

And again I'm happy to do it for you if it's too egregious.

BUT I'm pretty sure we can just keep using swp_entry_t. In fact unless there's
an absolutely compelling reason not to - this is exactly what I"ll do :)

>
> > However I am empathetic to not wanting to create _entirely_ unnecessary
> > churn here.
> >
> > I will actively keep you in the loop on follow up series and obviously will
> > absolutely take your opinion seriously on this.
>
> Thank you for your consideration.

Of course.

>
> >
> > I think this series overall hugely improves clarity and additionally avoids
> > a bunch of unnecessary, duplicative logic that previously was required, so
> > is well worth the slightly-annoying-churn cost here.
> >
> > But when it comes to the swap code itself I will try to avoid any
> > unnecessary noise.
>
> Ack.
>
> > One thing we were considering (discussions on previous iteration of series)
> > was to have a union of different softleaf types - one of which could simply
> > be swp_entry_t, meaning we get the best of both worlds, or at least
> > absolutely minimal changes.
>
> If you have a patch I would take a look and comment on it.

This will be in a follow-up series, will make sure you're cc'd on these. There
is more work to do :)

>
> > > Timing is not great either. We have the swap table phase II on review
> > > now. There is also phase III and phase IV on the backlog pipeline. All
> > > this renaming can create unnecessary conflicts. I am pleading please
> > > reduce the renaming in the swap system code for now until we can
> > > figure out what is the impact to the rest of the swap table series,
> > > which is the heavy lifting for swap right now. I want to draw a line
> > > in the sand that, on the PTE entry side, having multiple meanings, we
> > > can call it softleaft_t whatever. If we know it is the traditional
> > > swap entry meaning. Keep it swp_entry_t for now until we figure out
> > > the real impact.
> >
> > I really do empathise, having dealt with multiple conflicts and races in
> > series, however I don't think it's really sensible to delay one series
> > based on unmerged follow ups.
>
> If you leave the actual swap entry (single personality) alone, I think
> we can deal with the merge conflicts.

I'm not going to be changing this series other than for review feedback so you
don't need to worry.

>
> > So this series will proceed as it is.
>
> Please clarify the "proceed as it is" regarding the actual swap code.
> I hope you mean you are continuing your series, maybe with
> modifications also consider my feedback. After all, you just say " But
> I did think perhaps we could maintain this type explicitly for the
> _actual_ swap code."

I mean keeping this series as-is, of course modulo changes in response to review
feedback.

To be clear - I have no plans whatsoever to change the actual swap code _in this
series_ beyond what is already here.

And in the follow-up that will do more on this - I will most likely keep the
swp_entry_t as-is in core swap code or at least absolutely minimal changes
there.

And that series you will be cc'd on and welcome of course to push back on
anything you have an issue with :)

>
> > However I'm more than happy to help resolve conflicts - if you want to send
> > me any of these series off list etc. I can rebase to mm-new myself if
> > that'd be helpful?
>
> As I said above, leaving the actual swap code alone is more helpful
> and I consider it cleaner as well. We can also look into incremental
> change on your V2 to crave out the swap code.

Well I welcome review feedback.

I don't think I really touched anything particularly swap-specific that is
problematic, but obviously feel free to review and will absolutely try to
accommodate any reasonable requests!

>
> >
> > >
> > > Does this renaming have any behavior change in the produced machine code?
> >
> > It shouldn't result in any meaningful change no.
>
> That is actually the reason to give the swap table change more
> priority. Just saying.

I'm sorry but this is not a reasonable request. I am being as empathetic and
kind as I can be here, but this series is proceeding without arbitrary delay.

I will do everything I can to accommodate any concerns or issues you may have
here _within reason_ :)

>
> Chris

Cheers, Lorenzo

On Mon, Nov 10, 2025 at 3:28 AM Lorenzo Stoakes
<lorenzo.stoakes@oracle.com> wrote:
> > > > I kind of wish the swap system could still use swp_entry_t. At least I
> > > > don't see any complete reason to massively rename all the swap system
> > > > code if we already know the entry is the limited meaning of swap entry
> > > > (device + offset).
> > >
> > > Well the reason would be because we are trying to keep things consistent
> > > and viewing a swap entry as merely being one of the modes of a softleaf.
> >
> > Your reason applies to the multi-personality non-present pte entries.
> > I am fine with those as softleaf. However the reasoning does not apply
> > to the swap entry where we already know it is for actual swap. The
> > multi-personality does not apply there. I see no conflict with the
> > swp_entry type there. I argue that it is even cleaner that the swap
> > codes only refer to those as swp_entry rather than softleaf because
> > there is no possibility that the swap entry has multi-personality.
>
> Swap is one of the 'personalities', very explicitly. Having it this way hugely
> cleans up the code.
>
> I'm not sure I really understand your objection given the type will be
> bit-by-bit compatible.

Just to clarify. I only object to the blanket replacing all the
swp_entry_t to softleaf_t.
It seems you are not going to change the swp_entry_t for actual swap
usage, we are in alignment then.

BTW, about the name "softleaf_t", it does not reflect the nature of
this type is a not presented pte. If you have someone new to guess
what does  "softleaf_t" mean, I bet none of them would have guessed it
is a PTE  related value. I have considered  "idlepte_t", something
given to the reader by the idea that it is not a valid PTE entry. Just
some food for thought.

> I'll deal with this when I come to this follow-up series.
>
> As I said before I'm empathetic to conflicts, but also - this is something we
> all have to live with. I have had to deal with numerous conflict fixups. They're
> really not all that bad to fix up.
>
> And again I'm happy to do it for you if it's too egregious.
>
> BUT I'm pretty sure we can just keep using swp_entry_t. In fact unless there's
> an absolutely compelling reason not to - this is exactly what I"ll do :)

Good.

> > > So this series will proceed as it is.
> >
> > Please clarify the "proceed as it is" regarding the actual swap code.
> > I hope you mean you are continuing your series, maybe with
> > modifications also consider my feedback. After all, you just say " But
> > I did think perhaps we could maintain this type explicitly for the
> > _actual_ swap code."
>
> I mean keeping this series as-is, of course modulo changes in response to review
> feedback.
>
> To be clear - I have no plans whatsoever to change the actual swap code _in this
> series_ beyond what is already here.
>
> And in the follow-up that will do more on this - I will most likely keep the
> swp_entry_t as-is in core swap code or at least absolutely minimal changes
> there.

Ack

> And that series you will be cc'd on and welcome of course to push back on
> anything you have an issue with :)
>
> >
> > > However I'm more than happy to help resolve conflicts - if you want to send
> > > me any of these series off list etc. I can rebase to mm-new myself if
> > > that'd be helpful?
> >
> > As I said above, leaving the actual swap code alone is more helpful
> > and I consider it cleaner as well. We can also look into incremental
> > change on your V2 to crave out the swap code.
>
> Well I welcome review feedback.
>
> I don't think I really touched anything particularly swap-specific that is
> problematic, but obviously feel free to review and will absolutely try to
> accommodate any reasonable requests!
>
> >
> > >
> > > >
> > > > Does this renaming have any behavior change in the produced machine code?
> > >
> > > It shouldn't result in any meaningful change no.
> >
> > That is actually the reason to give the swap table change more
> > priority. Just saying.
>
> I'm sorry but this is not a reasonable request. I am being as empathetic and
> kind as I can be here, but this series is proceeding without arbitrary delay.
>
> I will do everything I can to accommodate any concerns or issues you may have
> here _within reason_ :)

I did not expect you to delay this. It is just expressing the
viewpoint that this is internal clean up for benefit the developers
rather than the end users.

Keep the existing swp_entry_t for the actual core swap usage is within
reasonable request. We already align on that.

Chris

On Tue, Nov 11, 2025 at 01:19:37AM -0800, Chris Li wrote:
> On Mon, Nov 10, 2025 at 3:28 AM Lorenzo Stoakes
> <lorenzo.stoakes@oracle.com> wrote:
> > > > > I kind of wish the swap system could still use swp_entry_t. At least I
> > > > > don't see any complete reason to massively rename all the swap system
> > > > > code if we already know the entry is the limited meaning of swap entry
> > > > > (device + offset).
> > > >
> > > > Well the reason would be because we are trying to keep things consistent
> > > > and viewing a swap entry as merely being one of the modes of a softleaf.
> > >
> > > Your reason applies to the multi-personality non-present pte entries.
> > > I am fine with those as softleaf. However the reasoning does not apply
> > > to the swap entry where we already know it is for actual swap. The
> > > multi-personality does not apply there. I see no conflict with the
> > > swp_entry type there. I argue that it is even cleaner that the swap
> > > codes only refer to those as swp_entry rather than softleaf because
> > > there is no possibility that the swap entry has multi-personality.
> >
> > Swap is one of the 'personalities', very explicitly. Having it this way hugely
> > cleans up the code.
> >
> > I'm not sure I really understand your objection given the type will be
> > bit-by-bit compatible.
>
> Just to clarify. I only object to the blanket replacing all the
> swp_entry_t to softleaf_t.
> It seems you are not going to change the swp_entry_t for actual swap
> usage, we are in alignment then.

Ack yes :)

>
> BTW, about the name "softleaf_t", it does not reflect the nature of
> this type is a not presented pte. If you have someone new to guess
> what does  "softleaf_t" mean, I bet none of them would have guessed it
> is a PTE  related value. I have considered  "idlepte_t", something
> given to the reader by the idea that it is not a valid PTE entry. Just
> some food for thought.

It's not a PTE value, it's an abstracted representation of a leaf entry,
hence leaf, and as relevant to the software interpretation of leaf entries,
hence soft :)

We also encode PMD entries so that'd be totally wrong.

We do make sure any PTE/PMD related stuff is prefixed appropriately
e.g. pte_xxx(), pmd_xxx().

>
> > I'll deal with this when I come to this follow-up series.
> >
> > As I said before I'm empathetic to conflicts, but also - this is something we
> > all have to live with. I have had to deal with numerous conflict fixups. They're
> > really not all that bad to fix up.
> >
> > And again I'm happy to do it for you if it's too egregious.
> >
> > BUT I'm pretty sure we can just keep using swp_entry_t. In fact unless there's
> > an absolutely compelling reason not to - this is exactly what I"ll do :)
>
> Good.
>
> > > > So this series will proceed as it is.
> > >
> > > Please clarify the "proceed as it is" regarding the actual swap code.
> > > I hope you mean you are continuing your series, maybe with
> > > modifications also consider my feedback. After all, you just say " But
> > > I did think perhaps we could maintain this type explicitly for the
> > > _actual_ swap code."
> >
> > I mean keeping this series as-is, of course modulo changes in response to review
> > feedback.
> >
> > To be clear - I have no plans whatsoever to change the actual swap code _in this
> > series_ beyond what is already here.
> >
> > And in the follow-up that will do more on this - I will most likely keep the
> > swp_entry_t as-is in core swap code or at least absolutely minimal changes
> > there.
>
> Ack
>
> > And that series you will be cc'd on and welcome of course to push back on
> > anything you have an issue with :)
> >
> > >
> > > > However I'm more than happy to help resolve conflicts - if you want to send
> > > > me any of these series off list etc. I can rebase to mm-new myself if
> > > > that'd be helpful?
> > >
> > > As I said above, leaving the actual swap code alone is more helpful
> > > and I consider it cleaner as well. We can also look into incremental
> > > change on your V2 to crave out the swap code.
> >
> > Well I welcome review feedback.
> >
> > I don't think I really touched anything particularly swap-specific that is
> > problematic, but obviously feel free to review and will absolutely try to
> > accommodate any reasonable requests!
> >
> > >
> > > >
> > > > >
> > > > > Does this renaming have any behavior change in the produced machine code?
> > > >
> > > > It shouldn't result in any meaningful change no.
> > >
> > > That is actually the reason to give the swap table change more
> > > priority. Just saying.
> >
> > I'm sorry but this is not a reasonable request. I am being as empathetic and
> > kind as I can be here, but this series is proceeding without arbitrary delay.
> >
> > I will do everything I can to accommodate any concerns or issues you may have
> > here _within reason_ :)
>
> I did not expect you to delay this. It is just expressing the
> viewpoint that this is internal clean up for benefit the developers
> rather than the end users.

I don't agree with this interpretation - this directly benefits everybody,
I've seen LOTS of bugs and issues that have arisen from misunderstanding of
internal kernel components or because somebody understandably missed
open-coded stuff or 'implicit' assumptions.

In fact it's an ongoing theme of (understandable) kernel developer
confusion resulting in bugs, instability, performance regressions and the
inability to extend or improve functionality.

I've repeatedly seen very significant negative impact in every measurable
metric from poorly structured and implemented code throughout my career,
and the exact opposite for the opposite.

So running counter to this, this series directly improves things for the
end user AS WELL as improving internal kernel developer happiness :)

For instance - the mmap 'cleanup' literally resolved a zero-day securiy
flaw.

I think it's very unfortunate that we overload the term 'cleanup' to both
describe 'fundamentally changing how parts of a subsystem operation' and
'typo fixes'. But anyway. I shall stop going on ;)

>
> Keep the existing swp_entry_t for the actual core swap usage is within
> reasonable request. We already align on that.

Yup, but within reason. I'm not going to duplicate pte_to_swp_entry() just
to satisfy this, and the swap code touches some softleaf stuff (e.g. not
processing non-swap stuff), but the idea is to keep it to a sensible
minimum.

Everything will be bit-for-bit compatible and have zero impact on the swap
implemenetation.

But yes intent is the _vast majority_ of the swap code stays exactly as it
is.

Future changes are really going to be focused on actually softleaf stuff
generally.

I hope to stop having leafops.h include swapops.h and then have swap stuff
include both and have the types be different _from C type safety
perspective_ but still bit-for-bit compatible so we just have a
satisfy-the-compiler conversion funtion that'll be a nop in generated
binary.

But all that's for future series :)

>
> Chris

Thanks, Lorenzo

On Mon, 10 Nov 2025, Lorenzo Stoakes wrote:
> On Mon, Nov 10, 2025 at 03:04:48AM -0800, Chris Li wrote:
> >
> > That is actually the reason to give the swap table change more
> > priority. Just saying.
> 
> I'm sorry but this is not a reasonable request. I am being as empathetic and
> kind as I can be here, but this series is proceeding without arbitrary delay.
> 
> I will do everything I can to accommodate any concerns or issues you may have
> here _within reason_ :)

But Lorenzo, have you even tested your series properly yet, with
swapping and folio migration and huge pages and tmpfs under load?
Please do.

I haven't had time to bisect yet, maybe there's nothing more needed
than a one-liner fix somewhere; but from my experience it is not yet
ready for inclusion in mm and next - it stops testing other folks' work.

I haven't tried today's v3, but from the cover letter of differences,
it didn't look like much of importance is fixed since v2: which
(after a profusion of "Bad swap offet entry 3ffffffffffff" messages,
not seen with v1, and probably not really serious) soon hits an Oops
or a BUG or something (as v1 did) - I don't have any logs or notes
to give yet, just forewarning before pursuing later in the day.

If you think v3 has fixed real crashes under load, please say so:
otherwise, I doubt it's worth Andrew hurrying to replace v2 by v3.

(Or have I got something bad in my build, and will have to apologize?
Or am I blaming your series - seems most likely - when it's actually
something else which came into mm in the last week?)

Hugh

On Tue, Nov 11, 2025 at 8:09 AM Hugh Dickins <hughd@google.com> wrote:
> On Mon, 10 Nov 2025, Lorenzo Stoakes wrote:
> > On Mon, Nov 10, 2025 at 03:04:48AM -0800, Chris Li wrote:
> > >
> > > That is actually the reason to give the swap table change more
> > > priority. Just saying.
> >
> > I'm sorry but this is not a reasonable request. I am being as empathetic and
> > kind as I can be here, but this series is proceeding without arbitrary delay.
> >
> > I will do everything I can to accommodate any concerns or issues you may have
> > here _within reason_ :)
>
> But Lorenzo, have you even tested your series properly yet, with
> swapping and folio migration and huge pages and tmpfs under load?
> Please do.
>
> I haven't had time to bisect yet, maybe there's nothing more needed
> than a one-liner fix somewhere; but from my experience it is not yet
> ready for inclusion in mm and next - it stops testing other folks' work.
>
> I haven't tried today's v3, but from the cover letter of differences,
> it didn't look like much of importance is fixed since v2: which
> (after a profusion of "Bad swap offet entry 3ffffffffffff" messages,

I also noticed the 0x3fff... issue in V2:
https://lore.kernel.org/all/CAMgjq7AP383YfU3L5ZxJ9U3x-vRPnEkEUtmnPdXD29HiNC8OrA@mail.gmail.com/

The issue is caused by removing the pte_none check, that could result
in issues like this, so that check has to stay I think, at least for
the swap part.

It seems V3 has fixed it, I can have a try later.

I also hope we can keep the swap entry part untouched, Overloading
swap entry for things like migration looks odd indeed, but setting and
getting a PTE as swap entry seems clean and easy to understand.
Existing usage of swap entries is quite logically consistent and
stable, we might need to do some cleanup for swap but having a
standalone type and define is very helpful.

On Tue, Nov 11, 2025 at 12:16:51PM +0800, Kairui Song wrote:
> On Tue, Nov 11, 2025 at 8:09 AM Hugh Dickins <hughd@google.com> wrote:
> > On Mon, 10 Nov 2025, Lorenzo Stoakes wrote:
> > > On Mon, Nov 10, 2025 at 03:04:48AM -0800, Chris Li wrote:
> > > >
> > > > That is actually the reason to give the swap table change more
> > > > priority. Just saying.
> > >
> > > I'm sorry but this is not a reasonable request. I am being as empathetic and
> > > kind as I can be here, but this series is proceeding without arbitrary delay.
> > >
> > > I will do everything I can to accommodate any concerns or issues you may have
> > > here _within reason_ :)
> >
> > But Lorenzo, have you even tested your series properly yet, with
> > swapping and folio migration and huge pages and tmpfs under load?
> > Please do.
> >
> > I haven't had time to bisect yet, maybe there's nothing more needed
> > than a one-liner fix somewhere; but from my experience it is not yet
> > ready for inclusion in mm and next - it stops testing other folks' work.
> >
> > I haven't tried today's v3, but from the cover letter of differences,
> > it didn't look like much of importance is fixed since v2: which
> > (after a profusion of "Bad swap offet entry 3ffffffffffff" messages,
>
> I also noticed the 0x3fff... issue in V2:
> https://lore.kernel.org/all/CAMgjq7AP383YfU3L5ZxJ9U3x-vRPnEkEUtmnPdXD29HiNC8OrA@mail.gmail.com/
>
> The issue is caused by removing the pte_none check, that could result
> in issues like this, so that check has to stay I think, at least for
> the swap part.
>
> It seems V3 has fixed it, I can have a try later.

It does fix it, it was not only the pte_none() thing, also the swap logic has a
totally insane 'let's pretend a PTE none entry is a swap entry' function. Ahem.

I think somewhat forgiveable to miss that :)

>
> I also hope we can keep the swap entry part untouched, Overloading
> swap entry for things like migration looks odd indeed, but setting and
> getting a PTE as swap entry seems clean and easy to understand.

Not completely untouched, as swap logic interacts inevitably with soft leaves -
you might have a softleaf in the page table entry.

But I do intend to keep swp_entry_t for actual swap stuff as discussed with
Chris.

> Existing usage of swap entries is quite logically consistent and
> stable, we might need to do some cleanup for swap but having a
> standalone type and define is very helpful.

I'm not sure how incredibly consistent or beautiful it is looking at the swap
code :) but I don't desire to churn for the sake of it and have no intent other
than doing the minimum there.

Thanks, Lorenzo

On Mon, 10 Nov 2025 15:38:55 -0800 (PST) Hugh Dickins <hughd@google.com> wrote:

> > I'm sorry but this is not a reasonable request. I am being as empathetic and
> > kind as I can be here, but this series is proceeding without arbitrary delay.
> > 
> > I will do everything I can to accommodate any concerns or issues you may have
> > here _within reason_ :)
> 
> But Lorenzo, have you even tested your series properly yet, with
> swapping and folio migration and huge pages and tmpfs under load?
> Please do.
> 
> I haven't had time to bisect yet, maybe there's nothing more needed
> than a one-liner fix somewhere; but from my experience it is not yet
> ready for inclusion in mm and next - it stops testing other folks' work.
> 
> I haven't tried today's v3, but from the cover letter of differences,
> it didn't look like much of importance is fixed since v2: which
> (after a profusion of "Bad swap offet entry 3ffffffffffff" messages,
> not seen with v1, and probably not really serious) soon hits an Oops
> or a BUG or something (as v1 did) - I don't have any logs or notes
> to give yet, just forewarning before pursuing later in the day.
> 
> If you think v3 has fixed real crashes under load, please say so:
> otherwise, I doubt it's worth Andrew hurrying to replace v2 by v3.

Oh.  Thanks.  I'll move the v3 series into mm-new for now.

On Mon, 10 Nov 2025, Andrew Morton wrote:
> On Mon, 10 Nov 2025 15:38:55 -0800 (PST) Hugh Dickins <hughd@google.com> wrote:
> 
> > > I'm sorry but this is not a reasonable request. I am being as empathetic and
> > > kind as I can be here, but this series is proceeding without arbitrary delay.
> > > 
> > > I will do everything I can to accommodate any concerns or issues you may have
> > > here _within reason_ :)
> > 
> > But Lorenzo, have you even tested your series properly yet, with
> > swapping and folio migration and huge pages and tmpfs under load?
> > Please do.
> > 
> > I haven't had time to bisect yet, maybe there's nothing more needed
> > than a one-liner fix somewhere; but from my experience it is not yet
> > ready for inclusion in mm and next - it stops testing other folks' work.
> > 
> > I haven't tried today's v3, but from the cover letter of differences,
> > it didn't look like much of importance is fixed since v2: which
> > (after a profusion of "Bad swap offet entry 3ffffffffffff" messages,
> > not seen with v1, and probably not really serious) soon hits an Oops
> > or a BUG or something (as v1 did) - I don't have any logs or notes
> > to give yet, just forewarning before pursuing later in the day.
> > 
> > If you think v3 has fixed real crashes under load, please say so:
> > otherwise, I doubt it's worth Andrew hurrying to replace v2 by v3.
> 
> Oh.  Thanks.  I'll move the v3 series into mm-new for now.

Lorenzo, I can happily apologize: the v3 series in mm-everything-
2025-11-11-01-20 is a big improvement over v2 and v1, it is showing
none of the bad behaviours I saw with those.  I've not searched or
compared for what actually fixed those symptoms (though have now
spotted mails from Shivank and Kairui regarding 3ffffffffffff),
I'm content now to move on to unrelated work...

Thanks,
Hugh

Andrew - in light of the below can we put this back in mm-unstable please?
I'd like the bots to be on this and obviously hoping for inclusion in 6.19
:)

On Mon, Nov 10, 2025 at 08:07:34PM -0800, Hugh Dickins wrote:
> On Mon, 10 Nov 2025, Andrew Morton wrote:
> > On Mon, 10 Nov 2025 15:38:55 -0800 (PST) Hugh Dickins <hughd@google.com> wrote:
> >
> > > > I'm sorry but this is not a reasonable request. I am being as empathetic and
> > > > kind as I can be here, but this series is proceeding without arbitrary delay.
> > > >
> > > > I will do everything I can to accommodate any concerns or issues you may have
> > > > here _within reason_ :)
> > >
> > > But Lorenzo, have you even tested your series properly yet, with
> > > swapping and folio migration and huge pages and tmpfs under load?
> > > Please do.

I did a whole bunch of testing, of course it's never enough in practice :)

> > >
> > > I haven't had time to bisect yet, maybe there's nothing more needed
> > > than a one-liner fix somewhere; but from my experience it is not yet
> > > ready for inclusion in mm and next - it stops testing other folks' work.
> > >
> > > I haven't tried today's v3, but from the cover letter of differences,
> > > it didn't look like much of importance is fixed since v2: which
> > > (after a profusion of "Bad swap offet entry 3ffffffffffff" messages,
> > > not seen with v1, and probably not really serious) soon hits an Oops
> > > or a BUG or something (as v1 did) - I don't have any logs or notes
> > > to give yet, just forewarning before pursuing later in the day.
> > >
> > > If you think v3 has fixed real crashes under load, please say so:
> > > otherwise, I doubt it's worth Andrew hurrying to replace v2 by v3.
> >
> > Oh.  Thanks.  I'll move the v3 series into mm-new for now.
>
> Lorenzo, I can happily apologize: the v3 series in mm-everything-
> 2025-11-11-01-20 is a big improvement over v2 and v1, it is showing
> none of the bad behaviours I saw with those.  I've not searched or
> compared for what actually fixed those symptoms (though have now
> spotted mails from Shivank and Kairui regarding 3ffffffffffff),
> I'm content now to move on to unrelated work...

Thanks yeah there were a couple oversights, one due to shenanigans around
how zero swap entries are represented, and another due to some frankly
insane code in the swap implementation.

I feel this change is very necessary for us to a. have clearer
understanding of this logic, and b. to be able to build upon it sensibly in
future.

This change is selfish also in that I intend to add huge guard markers in
future, and a previous attempt building upon the mass of confusion and
horror that was 'non-swap swap' felt borderline unworkable :)

>
> Thanks,
> Hugh

Cheers, Lorenzo