From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: Kairui Song <ryncsn@gmail.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Barry Song <baohua@kernel.org>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
Baoquan He <baoquan.he@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Muchun Song <muchun.song@linux.dev>, Chris Li <chrisl@kernel.org>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>, Yu Zhao <yuzhao@google.com>,
Zi Yan <ziy@nvidia.com>, Qi Zheng <qi.zheng@linux.dev>,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/7] mm/mglru: introduce helpers for manipulating gen and refs flags
Date: Wed, 19 Aug 2026 17:46:38 +0800 [thread overview]
Message-ID: <e143d790-fa3f-4b68-84e7-91199d8dbb54@linux.alibaba.com> (raw)
In-Reply-To: <CAMgjq7A1nK5EiRvN-o1Lg_Q2+Ek7oj4Fnm1qAy5A=ULfLz+t+w@mail.gmail.com>
On 8/19/26 5:37 PM, Kairui Song wrote:
> On Wed, Aug 19, 2026 at 5:03 PM Baolin Wang
> <baolin.wang@linux.alibaba.com> wrote:
>> On 8/18/26 1:38 PM, Kairui Song via B4 Relay wrote:
>>> From: Kairui Song <kasong@tencent.com>
>>>
>>> Instead of doing bit ops on folio->flags.f, introduce helpers for
>>> adjusting folio's refs and gen info, make the code easier to debug and
>>> understand.
>>>
>>> No functional change is intended: some combined atomic operations are
>>> split into two, which only creates harmless transient states.
>>>
>>> Signed-off-by: Kairui Song <kasong@tencent.com>
>>> ---
>>
>> Thanks for the cleanups. One comment below.
>>
>
> Thanks for the review!
>
>>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>>> index 94f9c3ff5416..32d9354a754f 100644
>>> --- a/include/linux/mmzone.h
>>> +++ b/include/linux/mmzone.h
>>> @@ -496,7 +496,9 @@ enum lruvec_flags {
>>> #ifndef __GENERATING_BOUNDS_H
>>>
>>> #define LRU_GEN_MASK ((BIT(LRU_GEN_WIDTH) - 1) << LRU_GEN_PGOFF)
>>> +#define LRU_GEN_MAX (BIT(LRU_GEN_WIDTH - 1) - 1)
>>
>> There are still many places using MAX_NR_GENS to compare gen counters,
>> so I'm concerned that introducing a new macro would make the use of the
>> max gen counter even more confusing.
>
> I think I'd like to get rid of all LRU_GEN_MASK and LRU_REFS_MASK
> users, MAX_NR_GENS is fine I think? Manipulating the bitmask looks a
> bit hard to follow for me since:
>
> set_mask_bits(&folio->flags.f, LRU_REFS_FLAGS, BIT(PG_workingset));
> set_mask_bits(&folio->flags.f, LRU_REFS_MASK, BIT(PG_referenced));
> set_mask_bits(&folio->flags.f, LRU_REFS_FLAGS, <number>);
> set_mask_bits(&folio->flags.f, LRU_REFS_FLAGS, BIT(PG_active));
> set_mask_bits(&folio->flags.f, LRU_REFS_MASK, <number>);
> new_flags = old_flags & ~(LRU_GEN_MASK | LRU_REFS_FLAGS);
> new_flags |= ((gen + 1UL) << LRU_GEN_PGOFF) | BIT(PG_workingset);
>
> Things like this are everywhere and I found it really hard to follow
> what is actually going on. And adding more operations to refs/gen
> looks ugly and painful to do, and, it's impossible to add any sanity
> check. With proper gen and refs helpers, we can ensure every time
> gen/refs is modified, the value is valid (in debug builds).
I agree LRU_GEN_MASK and LRU_REFS_MASK can be cleaned up further.
>
> Mean while, a "% MAX_NR_GENS" or "/ MIN_NR_GEN" seems not hard to understand.
>
> Oh and this LRU_GEN_MAX is only used for sanity check for now.
But my point is that people may not know when to use LRU_GEN_MAX vs.
MAX_NR_GENS, since they seem to have the same semantics.
next prev parent reply other threads:[~2026-08-19 9:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-18 5:38 [PATCH 0/7] mm/mglru: clean up folio counters and flag usage Kairui Song via B4 Relay
2026-08-18 5:38 ` [PATCH 1/7] mm/memcontrol: make lru_zone_size atomic and simplify sanity check Kairui Song via B4 Relay
2026-08-19 2:05 ` Ridong Chen
2026-08-18 5:38 ` [PATCH 2/7] mm/mglru: introduce helpers for manipulating gen and refs flags Kairui Song via B4 Relay
2026-08-19 9:03 ` Baolin Wang
2026-08-19 9:37 ` Kairui Song
2026-08-19 9:46 ` Baolin Wang [this message]
2026-08-19 9:49 ` Kairui Song
2026-08-18 5:38 ` [PATCH 3/7] mm/migrate: copy the referenced state via folio_migrate_refs() Kairui Song via B4 Relay
2026-08-19 10:12 ` Baoquan He
2026-08-18 5:38 ` [PATCH 4/7] mm/mglru: move max_seq read into walk_update_folio Kairui Song via B4 Relay
2026-08-19 9:18 ` Baolin Wang
2026-08-18 5:38 ` [PATCH 5/7] mm/mglru: use explicit tier range in read_ctrl_pos() Kairui Song via B4 Relay
2026-08-19 9:25 ` Baolin Wang
2026-08-19 10:16 ` Baoquan He
2026-08-18 5:38 ` [PATCH 6/7] mm/mglru: fix potential generation folio number leak Kairui Song via B4 Relay
2026-08-18 5:38 ` [PATCH 7/7] mm/mglru: improve code readability and harden folio_inc_gen Kairui Song via B4 Relay
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=e143d790-fa3f-4b68-84e7-91199d8dbb54@linux.alibaba.com \
--to=baolin.wang@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=baoquan.he@linux.dev \
--cc=cgroups@vger.kernel.org \
--cc=chrisl@kernel.org \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=qi.zheng@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=ryncsn@gmail.com \
--cc=shakeel.butt@linux.dev \
--cc=vbabka@kernel.org \
--cc=weixugc@google.com \
--cc=yuanchu@google.com \
--cc=yuzhao@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