From: Jason Gunthorpe <jgg@ziepe.ca>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Janosch Frank <frankja@linux.ibm.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
David Hildenbrand <david@redhat.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>, Zi Yan <ziy@nvidia.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Nico Pache <npache@redhat.com>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>, Lance Yang <lance.yang@linux.dev>,
Kemeng Shi <shikemeng@huaweicloud.com>,
Kairui Song <kasong@tencent.com>, Nhat Pham <nphamcs@gmail.com>,
Baoquan He <bhe@redhat.com>, Chris Li <chrisl@kernel.org>,
Peter Xu <peterx@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
Leon Romanovsky <leon@kernel.org>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
Vlastimil Babka <vbabka@suse.cz>, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Jann Horn <jannh@google.com>,
Matthew Brost <matthew.brost@intel.com>,
Joshua Hahn <joshua.hahnjy@gmail.com>,
Rakie Kim <rakie.kim@sk.com>, Byungchul Park <byungchul@sk.com>,
Gregory Price <gourry@gourry.net>,
Ying Huang <ying.huang@linux.alibaba.com>,
Alistair Popple <apopple@nvidia.com>,
Pedro Falcato <pfalcato@suse.de>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Rik van Riel <riel@surriel.com>, Harry Yoo <harry.yoo@oracle.com>,
kvm@vger.kernel.org, linux-s390@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [RFC PATCH 00/12] remove is_swap_[pte, pmd]() + non-swap confusion
Date: Tue, 28 Oct 2025 09:48:17 -0300 [thread overview]
Message-ID: <20251028124817.GH760669@ziepe.ca> (raw)
In-Reply-To: <8d4da271-472b-4a32-9e51-3ff4d8c2e232@lucifer.local>
On Mon, Oct 27, 2025 at 05:33:57PM +0000, Lorenzo Stoakes wrote:
> (Note I never intended this to be an RFC, it was only because of
> series-likely-to-be-dropped causing nasty conflicts this isn't an 'out
> there' series rather a practical submission).
>
> To preface, as I said elsewhere, I intend to do more on this, renaming
> swp_entry_t to probably leaf_entry_t (thanks Gregory!)
>
> The issue is no matter how I do this people will theorise different
> approaches, I'm trying to practically find a way forward that works
> iteratively.
It is why I suggested that swp_entry_t is the name we have (for this
series at least) and lean into it as the proper name for the abstract
idea of a multi-type'd value. Having a following series to rename
"swp_entry_t" to some "leaf entry" will resolve the poor naming.
But for now, "swp_entry_t" does not mean *swap* entry, it means "leaf
entry with a really bad type name".
And swpent_* is the namespace prefix for things dealing with
swp_entry_t.
If done consistently then the switch to leaf entry naming is just a
simple mass rename of swpent/leafent.
> > That suggests functions like this:
> >
> > swpent_is_swap()
> > swpent_is_migration()
> > ..
>
> The _whole point_ of this series is to separate out the idea that you're
> dealing with swap entries so I don't like swpent as a name obviously.
As you say we can't fix everything at once, but if you do the above
and then rename the end state would be
leafent_is_swap()
leafent_is_migration()
..
And that seems like a good end state.
So pick the small steps, either lean into swpent in this series as the
place holder for leafent in the next..
Or this seems like a good idea too:
> We could also just pre-empt and prefix functions with leafent_is_swap() if
> you prefer.
>
> We could even do:
>
> /* TODO: Rename swap_entry_t to leaf_entry_t */
> typedef swap_entry_t leaf_entry_t;
>
> And use the new type right away.
Then the followup series is cleaning away swap_entry_t as a name.
> > /* True if the pte is a swpent_is_swap() */
> > static inline bool swpent_get_swap_pte(pte_t pte, swp_entry_t *entryp)
> > {
> > if (pte_present(pte))
> > return false;
> > *swpent = pte_to_swp_entry(pte);
> > return swpent_is_swap(*swpent);
> > }
>
> I already implement in the series a pte_to_swp_entry_or_zero() function
I saw, but I don't think it is a great name.. It doesn't really give
"zero" it gives a swp_entry_t that doesn't pass any of the
swpent_is_XX() functions. ie a none type.
> that goes one further - checks pte_present() for you, if pte_none() you
> just get an empty swap entry, so this can be:
And I was hoping to see a path to get rid of the pte_none() stuff, or
at least on most arches. It is pretty pointless to check for pte_none
if the arch has a none-pte that already is 0..
So pte_none can be more like:
swpent_is_none(pte_to_swp_entry(pte))
Where pte_to_swp_entry is just some bit maths with no conditionals.
> > I also think it will be more readable to keep all these things under a
> > swpent namespace instead of using unstructured english names.
>
> Nope. Again, the whole point of the series is to avoid referencing
> swap. swpent_xxx() is just eliminating the purpose of the series right?
>
> Yes it sucks that the type name is what it is, but this is an iterative
> process.
Sure, but don't add a bunch of new names with *no namespace*. As above
either accept swpent is a placeholder for leafent in the next series,
or do this:
> But as above, we could pre-empt future changes and prefix with a
> leafent_*() prefix if that works for you?
Which seems like a good idea to me.
> > I'd expect a safe function should be more like
> >
> > *swpent = pte_to_swp_entry_safe(pte);
> > return swpent_is_swap(*swpent);
> >
> > Where "safe" means that if the PTE is None or Present then
> > swpent_is_XX() == false. Ie it returns a 0 swpent and 0 swpent is
> > always nothing.
>
> Not sure it's really 'safe', the name is unfortunate, but you could read
> this as 'always get a valid swap entry to operate on'...
My suggestion was the leaf entry has a type {none, swap, migration, etc}
And this _safe version returns the none type'd leaf entry for a
present pte.
We move toward eliminating the idea of pte_none by saying a
non-present pte is always a leaf_entry and what we call a "none pte"
is a "none leaf entry"
> leaf_entry_t leafent_from_pte()...?
Probably this one?
> > static inline bool get_pte_swap_entry(pte_t pte, swp_entry_t *entryp)
> > {
> > return swpent_is_swap(*swpent = pte_to_swp_entry_safe(pte));
> > }
>
> I absolutely hate that embedded assignment, but this is equivalent to what
> I suggested above, so agreed this is a good suggestion broadly.
>
> >
> > Maybe it doesn't even need an inline at that point?
>
> Don't understand what you mean by that. It's in a header file?
I mean just write it like this in the callers:
swp_entry_t leafent = pte_to_swp_entry_safe(pte);
if (swpent_is_swap(leafent)) {
}
It is basically the same # lines as the helper version.
> > > * is_huge_pmd() - Determines if a PMD contains either a present transparent
> > > huge page entry or a huge non-present entry. This again simplifies a lot
> > > of logic that simply open-coded this.
> >
> > is_huge_or_swpent_pmd() would be nicer, IMHO. I think it is surprising
> > when any of these APIs accept swap entries without being explicit
>
> Again, I'm not going to reference swap in a series intended to eliminate
> this, it defeats the purpose.
>
> And the non-present (or whatever you want to call it) entry _is_ huge. So
> it's just adding more confusion that way IMO.
Then this:
pmd_is_present_or_leafent(pmd)
Jason
next prev parent reply other threads:[~2025-10-28 12:48 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-24 7:41 [RFC PATCH 00/12] remove is_swap_[pte, pmd]() + non-swap confusion Lorenzo Stoakes
2025-10-24 7:41 ` [RFC PATCH 01/12] mm: introduce and use pte_to_swp_entry_or_zero() Lorenzo Stoakes
2025-10-24 7:41 ` [RFC PATCH 02/12] mm: avoid unnecessary uses of is_swap_pte() Lorenzo Stoakes
2025-10-24 7:41 ` [RFC PATCH 03/12] mm: introduce get_pte_swap_entry() and use it Lorenzo Stoakes
2025-10-24 7:41 ` [RFC PATCH 04/12] mm: use get_pte_swap_entry() in debug pgtable + remove is_swap_pte() Lorenzo Stoakes
2025-10-24 7:41 ` [RFC PATCH 05/12] fs/proc/task_mmu: refactor pagemap_pmd_range() Lorenzo Stoakes
2025-10-24 17:32 ` Gregory Price
2025-10-24 18:19 ` Lorenzo Stoakes
2025-10-24 19:12 ` Gregory Price
2025-10-24 20:15 ` Lorenzo Stoakes
2025-10-24 20:37 ` Gregory Price
2025-10-27 15:26 ` Lorenzo Stoakes
2025-10-27 16:11 ` Jason Gunthorpe
2025-10-27 16:15 ` David Hildenbrand
2025-10-27 16:26 ` Lorenzo Stoakes
2025-10-27 16:31 ` David Hildenbrand
2025-10-27 16:38 ` Lorenzo Stoakes
2025-10-27 17:08 ` Alexander Gordeev
2025-10-28 12:52 ` Jason Gunthorpe
2025-10-28 13:09 ` Gregory Price
2025-10-28 17:36 ` Lorenzo Stoakes
2025-10-28 18:23 ` Lorenzo Stoakes
2025-10-27 16:38 ` Gregory Price
2025-10-24 7:41 ` [RFC PATCH 06/12] mm: avoid unnecessary use of is_swap_pmd() Lorenzo Stoakes
2025-10-24 7:41 ` [RFC PATCH 07/12] mm: introduce is_huge_pmd() and use where appropriate Lorenzo Stoakes
2025-10-24 7:41 ` [RFC PATCH 08/12] mm/huge_memory: refactor copy_huge_pmd() non-present logic Lorenzo Stoakes
2025-10-24 7:41 ` [RFC PATCH 09/12] mm/huge_memory: refactor change_huge_pmd() " Lorenzo Stoakes
2025-10-24 18:41 ` Gregory Price
2025-10-24 18:44 ` Lorenzo Stoakes
2025-10-24 19:09 ` Gregory Price
2025-10-24 7:41 ` [RFC PATCH 10/12] mm: remove remaining is_swap_pmd() users and is_swap_pmd() Lorenzo Stoakes
2025-10-24 7:41 ` [RFC PATCH 11/12] mm: rename non_swap_entry() to is_non_present_entry() Lorenzo Stoakes
2025-10-24 19:07 ` Gregory Price
2025-10-24 20:17 ` Lorenzo Stoakes
2025-10-24 7:41 ` [RFC PATCH 12/12] mm: provide is_swap_entry() and use it Lorenzo Stoakes
2025-10-24 20:05 ` [RFC PATCH 00/12] remove is_swap_[pte, pmd]() + non-swap confusion Yosry Ahmed
2025-10-24 20:14 ` Lorenzo Stoakes
2025-10-27 16:09 ` Jason Gunthorpe
2025-10-27 17:33 ` Lorenzo Stoakes
2025-10-28 12:48 ` Jason Gunthorpe [this message]
2025-10-28 18:20 ` Lorenzo Stoakes
2025-10-29 14:10 ` Jason Gunthorpe
2025-10-29 19:09 ` Lorenzo Stoakes
2025-10-29 21:23 ` Gregory Price
2025-10-30 10:21 ` Lorenzo Stoakes
2025-11-02 14:27 ` Lorenzo Stoakes
2025-10-27 23:32 ` Gregory Price
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251028124817.GH760669@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=Liam.Howlett@oracle.com \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=bhe@redhat.com \
--cc=borntraeger@linux.ibm.com \
--cc=byungchul@sk.com \
--cc=chrisl@kernel.org \
--cc=david@redhat.com \
--cc=dev.jain@arm.com \
--cc=frankja@linux.ibm.com \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=gourry@gourry.net \
--cc=harry.yoo@oracle.com \
--cc=hca@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=jannh@google.com \
--cc=joshua.hahnjy@gmail.com \
--cc=kasong@tencent.com \
--cc=kvm@vger.kernel.org \
--cc=lance.yang@linux.dev \
--cc=leon@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=matthew.brost@intel.com \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=npache@redhat.com \
--cc=nphamcs@gmail.com \
--cc=osalvador@suse.de \
--cc=pasha.tatashin@soleen.com \
--cc=peterx@redhat.com \
--cc=pfalcato@suse.de \
--cc=rakie.kim@sk.com \
--cc=riel@surriel.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=shikemeng@huaweicloud.com \
--cc=surenb@google.com \
--cc=svens@linux.ibm.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox