From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Jinjiang Tu <tujinjiang@huawei.com>,
akpm@linux-foundation.org, ziy@nvidia.com, luizcap@redhat.com,
willy@infradead.org, linmiaohe@huawei.com,
svetly.todorov@memverge.com, xu.xin16@zte.com.cn,
chengming.zhou@linux.dev, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org
Cc: wangkefeng.wang@huawei.com, sunnanyong@huawei.com
Subject: Re: [PATCH 2/2] fs: stable_page_flags(): use folio_test_*() helpers
Date: Mon, 13 Jul 2026 11:31:47 +0200 [thread overview]
Message-ID: <e0dafac1-739b-495e-880d-879bdd984fcb@kernel.org> (raw)
In-Reply-To: <8b51832b-391d-4497-8135-8a3cdd4e4f57@huawei.com>
On 7/13/26 08:58, Jinjiang Tu wrote:
>
> 在 2026/7/10 19:29, David Hildenbrand (Arm) 写道:
>> On 7/2/26 13:06, Jinjiang Tu wrote:
>>> stable_page_flags() currently accesses folio->flags.f directly. Since
>>> commit 476d87d6a061 ("fs: stable_page_flags(): use snapshot_page()"), we
>>> can replace these raw flag accesses with the existing folio_test_*()
>>> helpers, thereby cleaning up the open‑coded flag handling.
>>>
>>> For KPF_IDLE, set_ps_flags() already handles both 64‑bit and 32‑bit
>>> cases, so the duplicate code in stable_page_flags() that deals with
>>> CONFIG_PAGE_IDLE_FLAG for the 64‑bit case is removed.
>>>
>>> The flag bits that has no folio_test_*() helpers are left unchanged,
>>> including PG_owner_priv_1, PG_arch_*.
>>>
>>> No functional change is intended.
>>>
>>> Signed-off-by: Jinjiang Tu <tujinjiang@huawei.com>
>>> ---
>>> fs/proc/page.c | 94 ++++++++++++++++++++++++++------------------------
>>> 1 file changed, 49 insertions(+), 45 deletions(-)
>>>
>>> diff --git a/fs/proc/page.c b/fs/proc/page.c
>>> index 2717dbb0431b..0dbd46fa84ea 100644
>>> --- a/fs/proc/page.c
>>> +++ b/fs/proc/page.c
>>> @@ -148,8 +148,6 @@ u64 stable_page_flags(const struct page *page)
>>> const struct folio *folio;
>>> struct page_snapshot ps;
>>> unsigned long k;
>>> - unsigned long mapping;
>>> - bool is_anon;
>>> u64 u = 0;
>>> /*
>>> @@ -163,17 +161,14 @@ u64 stable_page_flags(const struct page *page)
>>> folio = &ps.folio_snapshot;
>>> k = folio->flags.f;
>>> - mapping = (unsigned long)folio->mapping;
>>> - is_anon = mapping & FOLIO_MAPPING_ANON;
>>> -
>>> /*
>>> * pseudo flags for the well known (anonymous) memory mapped pages
>>> */
>>> if (folio_mapped(folio))
>>> u |= BIT_ULL(KPF_MMAP);
>>> - if (is_anon) {
>>> + if (folio_test_anon(folio)) {
>>> u |= BIT_ULL(KPF_ANON);
>>> - if ((mapping & FOLIO_MAPPING_FLAGS) == FOLIO_MAPPING_KSM)
>>> + if (folio_test_ksm(folio))
>>> u |= BIT_ULL(KPF_KSM);
>>> }
>> These make sense.
>>
>>> @@ -181,10 +176,12 @@ u64 stable_page_flags(const struct page *page)
>>> * compound pages: export both head/tail info
>>> * they together define a compound page's start/end pos and order
>>> */
>>> - if (ps.idx == 0)
>>> - u |= kpf_copy_bit(k, KPF_COMPOUND_HEAD, PG_head);
>>> - else
>>> + if (ps.idx == 0) {
>>> + if (folio_test_head(folio))
>>> + u |= BIT_ULL(KPF_COMPOUND_HEAD);
>>
>> Once we decouple folios from pages, we will have compound pages that are not
>> folios. PG_head is not folio specific.
>>
>> But then, some of the flags below are used in other context outside of folios.
>>
>> I would focus here only on converting things to use folios that will actually be
>> folio-specific: like the folio_test_anon() above.
>
> Understood, thanks.
>
> In addition to anon, ksm check, The swapcache check is also folio-specific.
>
> #define SWAPCACHE ((1 << PG_swapbacked) | (1 << PG_swapcache))
> if ((k & SWAPCACHE) == SWAPCACHE)
> u |= 1 << KPF_SWAPCACHE;
Indeed. that better also gets cleaned up.
--
Cheers,
David
prev parent reply other threads:[~2026-07-13 9:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260702110614.2176986-1-tujinjiang@huawei.com>
[not found] ` <61157b05-b22a-4bcf-942b-05225837b57b@kernel.org>
2026-07-03 3:00 ` [PATCH 0/2] fs: stable_page_flags(): use folio_test_*() helpers Jinjiang Tu
[not found] ` <20260702110614.2176986-3-tujinjiang@huawei.com>
2026-07-10 3:52 ` [PATCH 2/2] " Jinjiang Tu
2026-07-10 11:29 ` David Hildenbrand (Arm)
2026-07-13 6:58 ` Jinjiang Tu
2026-07-13 9:31 ` David Hildenbrand (Arm) [this message]
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=e0dafac1-739b-495e-880d-879bdd984fcb@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=chengming.zhou@linux.dev \
--cc=linmiaohe@huawei.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luizcap@redhat.com \
--cc=sunnanyong@huawei.com \
--cc=svetly.todorov@memverge.com \
--cc=tujinjiang@huawei.com \
--cc=wangkefeng.wang@huawei.com \
--cc=willy@infradead.org \
--cc=xu.xin16@zte.com.cn \
--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