From: sashiko-bot@kernel.org
To: "Kairui Song" <kasong@tencent.com>
Cc: damon@lists.linux.dev, tj@kernel.org, hannes@cmpxchg.org,
mkoutny@suse.com
Subject: Re: [PATCH v4 13/17] mm/mglru: folio LRU refs based active/inactive number accounting
Date: Thu, 15 Oct 2026 18:34:32 +0000 [thread overview]
Message-ID: <sashiko-outbox-173305@kernel.org> (raw)
In-Reply-To: <20261016-mglru-fg-v4-13-2106750c0bfa@tencent.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] mm: MGLRU tier bits (LRU_REFS_FLAGS) not cleared when updating LRU_GEN_MASK
--
commit 97ee7d2a683879e87f8e211218beb97d5cbbba1b
Author: Kairui Song <kasong@tencent.com>
mm/mglru: folio LRU refs based active/inactive number accounting
This commit updates the active/inactive LRU size tracking to use
per-folio referenced counts instead of the generation window. Folios
are now accounted as active once their references reach LRU_REFS_ACTIVATED.
> diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h
> index 6c9510002754b..41c2e9150c709 100644
> --- a/include/linux/mm_inline.h
> +++ b/include/linux/mm_inline.h
[ ... ]
> @@ -374,7 +373,7 @@ static inline bool lru_gen_add_folio(struct lruvec *lruvec, struct folio *folio,
> struct lru_gen_folio *lrugen = &lruvec->lrugen;
>
> BUILD_BUG_ON(BIT(LRU_GEN_WIDTH - 1) != MAX_NR_GENS);
> - VM_WARN_ON_ONCE_FOLIO(gen != -1, folio);
> + VM_WARN_ON_ONCE_FOLIO(folio_lru_gen(folio) != -1, folio);
>
> if (folio_test_unevictable(folio) || !lrugen->enabled)
> return false;
> @@ -383,10 +382,12 @@ static inline bool lru_gen_add_folio(struct lruvec *lruvec, struct folio *folio,
> gen = lru_gen_from_seq(seq);
> flags = (gen + 1UL) << LRU_GEN_PGOFF;
> /* see the comment on MIN_NR_GENS about PG_active */
> - set_mask_bits(folio_flags(folio, 0), LRU_GEN_MASK | BIT(PG_active), flags);
> + flags = set_mask_bits(folio_flags(folio, 0), LRU_GEN_MASK | BIT(PG_active), flags);
[Severity: Medium]
Should LRU_REFS_FLAGS be included in the mask cleared by set_mask_bits() here?
When a folio is added to a generation and LRU_GEN_MASK is modified, leaving
stale tier bits (LRU_REFS_FLAGS) intact can allow them to persist. This
could inadvertently inflate access counts and distort future eviction tracking.
> + /* use the refs from the atomic snapshot to avoid raced update */
> + refs = lru_get_refs_flags(flags);
>
> lru_gen_update_size(lruvec, folio, -1, gen);
[ ... ]
> @@ -402,24 +403,31 @@ static inline bool lru_gen_add_folio(struct lruvec *lruvec, struct folio *folio,
> static inline bool lru_gen_del_folio(struct lruvec *lruvec, struct folio *folio, bool reclaiming)
> {
> unsigned long flags;
> - int gen = folio_lru_gen(folio);
> + int gen, refs;
> int zone = folio_zonenum(folio);
> int delta = folio_nr_pages(folio);
> enum lru_list lru = folio_is_file_lru(folio) * LRU_INACTIVE_FILE;
> + unsigned long max_seq = READ_ONCE(lruvec->lrugen.max_seq);
>
> + flags = set_mask_bits(folio_flags(folio, 0), LRU_GEN_MASK, 0);
[Severity: Medium]
Could this mask also be missing the LRU_REFS_FLAGS bit clear?
Similar to the addition path above, when isolating a folio and clearing
LRU_GEN_MASK, the tier tracking bits might also need to be explicitly
cleared so they are not improperly carried over.
> + gen = lru_get_gen_flags(flags);
> + refs = lru_get_refs_flags(flags);
> if (gen < 0)
> return false;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261016-mglru-fg-v4-0-2106750c0bfa@tencent.com?part=13
next prev parent reply other threads:[~2026-10-15 18:34 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 18:15 [PATCH v4 00/17] mm/mglru: frequency guided promotion (MGLRU-FG) and flag cleanup Kairui Song via B4 Relay
2026-10-15 18:15 ` [PATCH v4 01/17] mm/memcontrol: allow update of LRU statistic without holding LRU lock Kairui Song via B4 Relay
2026-10-15 18:32 ` sashiko-bot
2026-10-15 18:15 ` [PATCH v4 02/17] mm/mglru: make generation page counters atomic Kairui Song via B4 Relay
2026-10-15 18:37 ` sashiko-bot
2026-10-15 18:15 ` [PATCH v4 03/17] mm/memcg: add folio-based lruvec live helper Kairui Song via B4 Relay
2026-10-15 18:31 ` sashiko-bot
2026-10-15 19:11 ` Harry Yoo
2026-10-16 6:15 ` Kairui Song
2026-10-15 18:15 ` [PATCH v4 04/17] mm/mglru: frequency guided workingset promotion (MGLRU-FG) Kairui Song via B4 Relay
2026-10-15 18:41 ` sashiko-bot
2026-10-15 18:15 ` [PATCH v4 05/17] mm/mglru: make folio lru referenced times count a generic API Kairui Song via B4 Relay
2026-10-15 18:30 ` sashiko-bot
2026-10-15 18:15 ` [PATCH v4 06/17] mm/mglru: move add/del LRU size accounting out of lru_gen_update_size() Kairui Song via B4 Relay
2026-10-15 18:28 ` sashiko-bot
2026-10-15 18:15 ` [PATCH v4 07/17] mm/mglru, gup: mark folios referenced via a fast helper Kairui Song via B4 Relay
2026-10-15 18:27 ` sashiko-bot
2026-10-15 18:15 ` [PATCH v4 08/17] mm/mglru, smaps: convert to LRU refs based operations for MGLRU Kairui Song via B4 Relay
2026-10-15 18:29 ` sashiko-bot
2026-10-15 18:15 ` [PATCH v4 09/17] mm/damon: " Kairui Song via B4 Relay
2026-10-15 18:27 ` sashiko-bot
2026-10-15 18:15 ` [PATCH v4 10/17] mm/khugepaged: " Kairui Song via B4 Relay
2026-10-15 18:29 ` sashiko-bot
2026-10-15 18:16 ` [PATCH v4 11/17] mm/madvise: adapt for " Kairui Song via B4 Relay
2026-10-15 18:25 ` sashiko-bot
2026-10-15 18:16 ` [PATCH v4 12/17] mm/huge_memory: mark folio as accessed more accurately on split Kairui Song via B4 Relay
2026-10-15 18:36 ` sashiko-bot
2026-10-15 18:16 ` [PATCH v4 13/17] mm/mglru: folio LRU refs based active/inactive number accounting Kairui Song via B4 Relay
2026-10-15 18:34 ` sashiko-bot [this message]
2026-10-15 18:16 ` [PATCH v4 14/17] mm/mglru: reparent folios from all generations Kairui Song via B4 Relay
2026-10-15 18:27 ` sashiko-bot
2026-10-15 18:16 ` [PATCH v4 15/17] mm/mglru: make folio_inc_lru_refs lruvec lockless Kairui Song via B4 Relay
2026-10-15 18:29 ` sashiko-bot
2026-10-15 18:16 ` [PATCH v4 16/17] mm/mglru: make folio_test_workingset() work based on folio LRU refs Kairui Song via B4 Relay
2026-10-15 18:35 ` sashiko-bot
2026-10-15 18:16 ` [PATCH v4 17/17] Documentation/mm: multi-gen LRU: update for frequency guided promotion Kairui Song via B4 Relay
2026-10-15 18:27 ` sashiko-bot
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=sashiko-outbox-173305@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=damon@lists.linux.dev \
--cc=hannes@cmpxchg.org \
--cc=kasong@tencent.com \
--cc=mkoutny@suse.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tj@kernel.org \
/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