Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
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


      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