Message-ID: <7d4c26e9-2fc2-4a59-bd34-984bf7df4dd7@lucifer.local>
Date: Wed, 5 Nov 2025 17:33:47 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Wei Yang <richard.weiyang@...il.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>, Chris Li <chrisl@...nel.org>,
        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 00/16] mm: remove is_swap_[pte, pmd]() + non-swap
 entries, introduce leaf entries

On Wed, Nov 05, 2025 at 02:41:40AM +0000, Wei Yang wrote:
> On Mon, Nov 03, 2025 at 12:31:41PM +0000, Lorenzo Stoakes wrote:
> >There's an established convention in the kernel that we treat leaf page
> >tables (so far at the PTE, PMD level) as containing 'swap entries' should
> >they be neither empty (i.e. p**_none() evaluating true) nor present
> >(i.e. p**_present() evaluating true).
> >
> >However, at the same time we also have helper predicates - is_swap_pte(),
> >is_swap_pmd() - which are inconsistently used.
> >
> >This is problematic, as it is logical to assume that should somebody wish
> >to operate upon a page table swap entry they should first check to see if
> >it is in fact one.
> >
> >It also implies that perhaps, in future, we might introduce a non-present,
> >none page table entry that is not a swap entry.
> >
> >This series resolves this issue by systematically eliminating all use of
> >the is_swap_pte() and is swap_pmd() predicates so we retain only the
> >convention that should a leaf page table entry be neither none nor present
> >it is a swap entry.
> >
> >We also have the further issue that 'swap entry' is unfortunately a really
> >rather overloaded term and in fact refers to both entries for swap and for
> >other information such as migration entries, page table markers, and device
> >private entries.
> >
> >We therefore have the rather 'unique' concept of a 'non-swap' swap entry.
> >
> >This series therefore introduces the concept of 'leaf entries' to eliminate
> >this confusion.
> >
> >A leaf entry in this sense is any page table entry which is non-present,
> >and represented by the leaf_entry_t type.
> >
> >This includes 'none' or empty entries, which are simply represented by an
> >zero leaf entry value.
> >
> >In order to maintain compatibility as we transition the kernel to this new
> >type, we simply typedef swp_entry_t to leaf_entry_t.
> >
> >We introduce a number of predicates and helpers to interact with leaf
> >entries in include/linux/leafops.h which, as it imports swapops.h, can be
> >treated as a drop-in replacement for swapops.h wherever leaf entry helpers
> >are used.
> >
> >Since leafent_from_[pte, pmd]() treats present entries as they were
> >empty/none leaf entries, this allows for a great deal of simplification of
> >code throughout the code base, which this series utilises a great deal.
> >
> >We additionally change from swap entry to leaf entry handling where it
> >makes sense to and eliminate functions from swapops.h where leaf entries
> >obviate the need for the functions.
> >
>
> Hi, Lorenzo
>
> Thanks for the effort on cleanup this, which helps me clearing the confusing
> on checking swap entry.

Thank you :) much appreciated!

Hope it's useful, my ultimate initial aim was to address my own confusion and
frustration (stemming out of a debate about use of the is_swap_pte() predicate
on a review), I'm glad that via review and also thinking 'hmm we should address
this also' etc. this his developed into something that hopefully makes life
easier for everybody!

>
>
> --
> Wei Yang
> Help you, Help me

Cheers, Lorenzo

Powered by blists - more mailing lists