Message-ID: <CACePvbUvQu+So7OoUbJTMLODz8YDAOgWaM8A-RXFj2U_Qc-dng@mail.gmail.com>
Date: Mon, 10 Nov 2025 03:04:48 -0800
From: Chris Li <chrisl@...nel.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
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 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.

> 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

Powered by blists - more mailing lists