Message-ID: <3c0e9dd0-70ac-4588-813b-ffb24d40f067@lucifer.local>
Date: Mon, 10 Nov 2025 11:27:34 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Chris Li <chrisl@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Janosch Frank <frankja@...ux.ibm.com>,
        Claudio Imbrenda <imbrenda@...ux.ibm.com>,
        David Hildenbrand <david@...hat.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Gerald Schaefer <gerald.schaefer@...ux.ibm.com>,
        Heiko Carstens <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>,
        Sven Schnelle <svens@...ux.ibm.com>, Peter Xu <peterx@...hat.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
        Arnd Bergmann <arnd@...db.de>, Zi Yan <ziy@...dia.com>,
        Baolin Wang <baolin.wang@...ux.alibaba.com>,
        "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Nico Pache <npache@...hat.com>, Ryan Roberts <ryan.roberts@....com>,
        Dev Jain <dev.jain@....com>, Barry Song <baohua@...nel.org>,
        Lance Yang <lance.yang@...ux.dev>, Muchun Song <muchun.song@...ux.dev>,
        Oscar Salvador <osalvador@...e.de>, Vlastimil Babka <vbabka@...e.cz>,
        Mike Rapoport <rppt@...nel.org>,
        Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>,
        Matthew Brost <matthew.brost@...el.com>,
        Joshua Hahn <joshua.hahnjy@...il.com>, Rakie Kim <rakie.kim@...com>,
        Byungchul Park <byungchul@...com>, Gregory Price <gourry@...rry.net>,
        Ying Huang <ying.huang@...ux.alibaba.com>,
        Alistair Popple <apopple@...dia.com>,
        Axel Rasmussen <axelrasmussen@...gle.com>,
        Yuanchu Xie <yuanchu@...gle.com>, Wei Xu <weixugc@...gle.com>,
        Kemeng Shi <shikemeng@...weicloud.com>,
        Kairui Song <kasong@...cent.com>, Nhat Pham <nphamcs@...il.com>,
        Baoquan He <bhe@...hat.com>, SeongJae Park <sj@...nel.org>,
        Matthew Wilcox <willy@...radead.org>, Jason Gunthorpe <jgg@...pe.ca>,
        Leon Romanovsky <leon@...nel.org>, Xu Xin <xu.xin16@....com.cn>,
        Chengming Zhou <chengming.zhou@...ux.dev>,
        Jann Horn <jannh@...gle.com>, Miaohe Lin <linmiaohe@...wei.com>,
        Naoya Horiguchi <nao.horiguchi@...il.com>,
        Pedro Falcato <pfalcato@...e.de>,
        Pasha Tatashin <pasha.tatashin@...een.com>,
        Rik van Riel <riel@...riel.com>, Harry Yoo <harry.yoo@...cle.com>,
        Hugh Dickins <hughd@...gle.com>, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, linux-s390@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
        linux-arch@...r.kernel.org, damon@...ts.linux.dev
Subject: Re: [PATCH v2 00/16] mm: remove is_swap_[pte, pmd]() + non-swap
 entries, introduce leaf entries

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@...cle.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

Powered by blists - more mailing lists