Re: [PATCH v2 00/16] mm: remove is_swap_[pte, pmd]() + non-swap entries, introduce leaf entries

[Chris Li]

On Mon, Nov 10, 2025 at 3:28 AM Lorenzo Stoakes
<lorenzo.stoakes@xxxxxxxxxx> 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