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

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

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