From: David Hildenbrand <david@redhat.com>
To: Kairui Song <ryncsn@gmail.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <willy@infradead.org>,
Hugh Dickins <hughd@google.com>, Chris Li <chrisl@kernel.org>,
Barry Song <baohua@kernel.org>, Baoquan He <bhe@redhat.com>,
Nhat Pham <nphamcs@gmail.com>,
Kemeng Shi <shikemeng@huaweicloud.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Ying Huang <ying.huang@linux.alibaba.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Yosry Ahmed <yosryahmed@google.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Zi Yan <ziy@nvidia.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/9] mm, swap: tidy up swap device and cluster info helpers
Date: Wed, 3 Sep 2025 10:11:05 +0200 [thread overview]
Message-ID: <cd52244b-12f6-43aa-9db2-925348566bed@redhat.com> (raw)
In-Reply-To: <CAMgjq7C+mChdnbcrYEkKyuuRN9-THXwBdFeCVwvW_m-_CWCzvw@mail.gmail.com>
On 02.09.25 17:03, Kairui Song wrote:
> On Tue, Sep 2, 2025 at 10:14 PM David Hildenbrand <david@redhat.com> wrote:
>>
>> On 22.08.25 21:20, Kairui Song wrote:
>>> From: Kairui Song <kasong@tencent.com>
>>>
>>> swp_swap_info is the most commonly used helper for retrieving swap info.
>>> It has an internal check that may lead to a NULL return value, but
>>> almost none of its caller checks the return value, making the internal
>>> check pointless. In fact, most of these callers already ensured the
>>> entry is valid and never expect a NULL value.
>>>
>>> Tidy this up and shorten the name.
>>
>> Shorter != better. But yes, "swp_swap" was a mess.
>>
>>> If the caller can make sure the
>>> swap entry/type is valid and the device is pinned, use the new introduced
>>> swp_info/swp_type_info instead. They have more debug sanity checks and
>>> lower overhead as they are inlined.
>>>
>>> Callers that may expect a NULL value should use
>>> swp_get_info/swp_type_get_info instead.
>>
>> High-level comments:
>>
>> 1) I hate the "swp" vs. "swap". Is that a valuable distinction or could
>> we just convert it to "swap" as we touch it?
>
> Totally agree. I was just blindly following the old style. It's kind
> of confusing indeed.
... and not a lot of space saved :)
>
>>
>> You're converting swap_type_to_swap_info() to swp_type_to_swap_info(),
>> and I am not sure if that is the right direction :)
>>
>>
>> 2) Can we just call it "swap_entry" when we work on a swap entry and
>> "swap_type" when we work on a swap type in the function name?
>>
>> swp_info() is a rather bad function name.
>>
>>
>> 3) I am not sure about "to" -> "get". "to" is much more readable in that
>> context and consistent.
>>
>>
>> 4) swp_info[] vs. swap_info() gah.
>>
>>
>> I would just have done:
>>
>> swap_type_to_info(int type)
>> __swap_type_to_info(int type)
>> swap_entry_to_info(swp_entry_t entry)
>> __swap_entry_to_info(swp_entry_t entry)
>>
>> __ are the expert functions where we don't expect NULL.
>>
>
> Thanks a lot for the suggestions! I also like the idea of using "__"
> to seperate the non-NULL version a lot and implis the caller have to
> careful.
Right, it's the "pro" version :)
>
> My concern was that names will be getting very long in later commits
> following this convention. Which is also the reason I want to shorten
> them here.
>
> A lot of SWAP relate operations will be cluster based, so it will be
> very common to get offset or the swap cluster from a swap entry.
> We will end up having a really long name like
> __swap_entry_to_cluster_offset (convert swap entry to offset inside a
> cluster).
That's a perfectly fine length though :)
>
> Since we already have the swap entry type called `swp_entry_t` and
> helprs like `swp_offset` and 'swp_swap_info' that convert an entry to
> other swap things, so I thought that anything converts swap entry /
> offset to others are named `swp_*`.
Yeah, I think that's just bad historical baggage we should clean up at
some point.
>
> Maybe a bad practise here, we can fix it while at it, or at least no
> longer introduce more confusing names.
>
> I can follow this suggested style, will it be a good idea if we have
> following set of helpers?
>
> For swap cluster and swap device (swap_info_struct):
> swap_type_to_info(int)
> __swap_type_to_info(int)
> swap_entry_to_info(swp_entry_t)
> __swap_entry_to_info(swp_entry_t)
> __swap_offset_to_cluster(struct swap_info_struct *, pgoff_t)
> __swap_entry_to_cluster(swp_entry_t)
Looks great to me, but let's hear other opinions.
>
> And for offsets, we still use:
> swp_offset() (Existing helper)
Yeah, there's also "swp_type" and "swp_offset_pfn". They really only
extract basic properties of the entry, so they are a bit special.
I think we should call them "swap_entry_offset" "swap_entry_type"
"swap_entry_pfn".
Now, that's not something I would expect in your series.
> swp_cluster_offset()
That one could later become swap_entry_cluster_offset()
>
> Now all swp_* helpers are pure arithmetic operations (we just renamed
> swp_swap_info which seems the only exception). Is this better?
I'm already happy once we name+document the new functions properly.
I could probably live with "swp_cluster_offset" for the time being :)
--
Cheers
David / dhildenb
next prev parent reply other threads:[~2025-09-03 8:11 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-22 19:20 [PATCH 0/9] mm, swap: introduce swap table as swap cache (phase I) Kairui Song
2025-08-22 19:20 ` [PATCH 1/9] mm, swap: use unified helper for swap cache look up Kairui Song
2025-08-27 2:47 ` Chris Li
2025-08-27 3:50 ` Chris Li
2025-08-27 13:45 ` Kairui Song
2025-08-27 3:52 ` Baoquan He
2025-08-27 13:46 ` Kairui Song
2025-08-28 3:20 ` Baolin Wang
2025-09-01 23:50 ` Barry Song
2025-09-02 6:12 ` Kairui Song
2025-09-02 6:52 ` Chris Li
2025-09-02 10:06 ` David Hildenbrand
2025-09-02 12:32 ` Chris Li
2025-09-02 13:18 ` David Hildenbrand
2025-09-02 16:38 ` Kairui Song
2025-09-02 10:10 ` David Hildenbrand
2025-09-02 17:13 ` Kairui Song
2025-09-03 8:00 ` David Hildenbrand
2025-09-03 17:41 ` Nhat Pham
2025-09-04 16:05 ` Kairui Song
2025-08-22 19:20 ` [PATCH 2/9] mm, swap: always lock and check the swap cache folio before use Kairui Song
2025-08-27 6:13 ` Chris Li
2025-08-27 13:44 ` Kairui Song
2025-08-30 1:42 ` Chris Li
2025-08-27 7:03 ` Chris Li
2025-08-27 14:35 ` Kairui Song
2025-08-28 3:41 ` Baolin Wang
2025-08-28 18:05 ` Kairui Song
2025-08-30 1:53 ` Chris Li
2025-08-30 15:15 ` Kairui Song
2025-08-30 17:17 ` Chris Li
2025-09-01 18:17 ` Kairui Song
2025-09-01 21:10 ` Chris Li
2025-09-02 5:40 ` Barry Song
2025-09-02 10:18 ` David Hildenbrand
2025-09-02 10:21 ` David Hildenbrand
2025-09-02 12:46 ` Chris Li
2025-09-02 13:27 ` Kairui Song
2025-08-22 19:20 ` [PATCH 3/9] mm, swap: rename and move some swap cluster definition and helpers Kairui Song
2025-08-30 2:31 ` Chris Li
2025-09-02 5:53 ` Barry Song
2025-09-02 10:20 ` David Hildenbrand
2025-09-02 12:50 ` Chris Li
2025-08-22 19:20 ` [PATCH 4/9] mm, swap: tidy up swap device and cluster info helpers Kairui Song
2025-08-27 3:47 ` Baoquan He
2025-08-27 17:44 ` Chris Li
2025-08-27 23:46 ` Baoquan He
2025-08-30 2:38 ` Chris Li
2025-09-02 6:01 ` Barry Song
2025-09-03 9:28 ` David Hildenbrand
2025-09-02 6:02 ` Barry Song
2025-09-02 13:33 ` David Hildenbrand
2025-09-02 15:03 ` Kairui Song
2025-09-03 8:11 ` David Hildenbrand [this message]
2025-08-22 19:20 ` [PATCH 5/9] mm/shmem, swap: remove redundant error handling for replacing folio Kairui Song
2025-08-25 3:02 ` Baolin Wang
2025-08-25 9:45 ` Kairui Song
2025-08-30 2:41 ` Chris Li
2025-09-03 8:25 ` David Hildenbrand
2025-08-22 19:20 ` [PATCH 6/9] mm, swap: use the swap table for the swap cache and switch API Kairui Song
2025-08-30 1:54 ` Baoquan He
2025-08-30 3:40 ` Chris Li
2025-08-30 3:34 ` Chris Li
2025-08-30 16:52 ` Kairui Song
2025-08-31 1:00 ` Chris Li
2025-09-02 11:51 ` Kairui Song
2025-09-02 9:55 ` Barry Song
2025-09-02 11:58 ` Kairui Song
2025-09-02 23:44 ` Barry Song
2025-09-03 2:12 ` Kairui Song
2025-09-03 2:31 ` Barry Song
2025-09-03 11:41 ` David Hildenbrand
2025-09-03 12:54 ` Kairui Song
2025-09-04 9:28 ` David Hildenbrand
2025-08-22 19:20 ` [PATCH 7/9] mm, swap: remove contention workaround for swap cache Kairui Song
2025-08-30 4:07 ` Chris Li
2025-08-30 15:24 ` Kairui Song
2025-08-31 15:54 ` Kairui Song
2025-08-31 20:06 ` Chris Li
2025-08-31 20:04 ` Chris Li
2025-09-02 10:06 ` Barry Song
2025-08-22 19:20 ` [PATCH 8/9] mm, swap: implement dynamic allocation of swap table Kairui Song
2025-08-30 4:17 ` Chris Li
2025-09-02 11:15 ` Barry Song
2025-09-02 13:17 ` Chris Li
2025-09-02 16:57 ` Kairui Song
2025-09-02 23:31 ` Barry Song
2025-09-03 2:13 ` Kairui Song
2025-09-03 12:35 ` Chris Li
2025-09-03 20:52 ` Barry Song
2025-09-04 6:50 ` Chris Li
2025-08-22 19:20 ` [PATCH 9/9] mm, swap: use a single page for swap table when the size fits Kairui Song
2025-08-30 4:23 ` Chris Li
2025-08-26 22:00 ` [PATCH 0/9] mm, swap: introduce swap table as swap cache (phase I) Chris Li
2025-08-30 5:44 ` Chris Li
2025-09-04 16:36 ` Kairui Song
2025-09-04 18:50 ` Chris Li
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=cd52244b-12f6-43aa-9db2-925348566bed@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=bhe@redhat.com \
--cc=chrisl@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=nphamcs@gmail.com \
--cc=ryncsn@gmail.com \
--cc=shikemeng@huaweicloud.com \
--cc=willy@infradead.org \
--cc=ying.huang@linux.alibaba.com \
--cc=yosryahmed@google.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;
as well as URLs for NNTP newsgroup(s).