All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hui Zhu <hui.zhu@linux.dev>
To: "Liam R. Howlett" <liam@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@kernel.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Vlastimil Babka <vbabka@kernel.org>,
	Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>, Yu Zhao <yuzhao@google.com>,
	Kairui Song <kasong@tencent.com>, Barry Song <baohua@kernel.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Hui Zhu <zhuhui@kylinos.cn>,
	stable@vger.kernel.org
Subject: Re: [PATCH v3] mm/mglru: fix a no-op lru_gen_clear_refs() call in lru_lazyfree()
Date: Thu, 12 Nov 2026 09:57:35 +0800	[thread overview]
Message-ID: <5e2733ee-7a25-430f-bdda-f89fc5856e5d@linux.dev> (raw)
In-Reply-To: <4xqyzrl4lbxwbky22lc5k5mcvusudg75z6hspjokfoghp3dny3@rjuukqzxiuyv>

2026/11/12 01:21, Liam R. Howlett:

> On 26/11/09 10:16AM, Hui Zhu wrote:
>> From: Hui Zhu <zhuhui@kylinos.cn>
>>
>> lru_lazyfree() calls lru_gen_clear_refs() after lruvec_del_folio(), but
>> lru_gen_del_folio() has already cleared LRU_GEN_MASK, so folio_lru_gen()
>> returns -1 and lru_gen_clear_refs() exits at its "gen < 0" check without
>> clearing the refs or PG_workingset.
>>
>> A MADV_FREE folio therefore keeps the state it had before madvise(2),
>> even though madvise_free_pte_range() has already cleared the accessed and
>> dirty bits of its PTEs.  lru_gen_folio_seq() places it one generation
>> younger, and PG_workingset puts it in the last tier, so sort_folio()
>> promotes and protects it instead of evicting it and charges it to
>> lrugen->protected[], which read_ctrl_pos() uses to balance anon against
>> file reclaim.  __folio_inc_gen() clears the refs but not PG_workingset,
>> so this repeats every time the folio reaches the oldest generation.  If
>> the folio is redirtied first, ttu_anon_lazyfree_folio() keeps it and
>> lru_gen_eviction() packs the stale state into the shadow entry, so a
>> later refault is promoted to the youngest generation.
>>
>> Call lru_gen_clear_refs() while the folio is still on the generation
>> list, as deactivate_file_folio() and folio_deactivate() already do.  Its
>> return value only says whether the folio is in the oldest generation,
>> which lru_lazyfree() does not need because it re-adds the folio below.
>> Keep folio_clear_referenced() unconditional: the classic LRU needs it,
>> and it also covers the folios that lru_gen_clear_refs() skips.
>>
>> Fixes: cc8ec7be78ff ("mm/mglru: optimize deactivation")
>> Cc: stable@vger.kernel.org
>> Suggested-by: Barry Song <baohua@kernel.org>
>> Signed-off-by: Hui Zhu <zhuhui@kylinos.cn>
>> Reviewed-by: Barry Song <baohua@kernel.org>
> One nit..
>
> Reviewed-by: Liam R. Howlett (Google) <liam@infradead.org>
>
>> ---
>> Changelog:
>> v3:
>> Add Cc: stable@vger.kernel.org and pick up Barry's Reviewed-by.
>> No code change compared to v2.
>> Per the thread discussion, the __lru_gen_clear_refs() refactor will be
>> sent as a separate cleanup after this fix lands.
>> v2:
>> Call lru_gen_clear_refs() before lruvec_del_folio() instead of
>> open-coding the flag clears; drop the lru_gen_enabled() branch and
>> the comment (Barry Song).
>>
>>   mm/folio.c | 6 ++----
>>   1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/mm/folio.c b/mm/folio.c
>> index 35e242b48870b..ea3adb6a89d75 100644
>> --- a/mm/folio.c
>> +++ b/mm/folio.c
>> @@ -597,12 +597,10 @@ static void lru_lazyfree(struct lruvec *lruvec, struct folio *folio)
>>   	    folio_test_swapcache(folio) || folio_test_unevictable(folio))
>>   		return;
>>   
>> +	lru_gen_clear_refs(folio);
> Since you're not checking the return here, you could use
> folio_set_lru_refs(folio, 0);
> folio_clear_workingset(folio);

Thanks for the review.

That is exactly the shape we agreed on for the follow-up cleanup in
this thread, Barry's __lru_gen_clear_refs() draft. I would still keep
v3 as it is, for two reasons.

folio_set_lru_refs() is only defined under CONFIG_LRU_GEN, so the
open-coded version needs a new stub in mm_inline.h. That turns this
one-spot fix into the header change we planned for the cleanup patch.

The two calls are also unconditional, so on the classic LRU every
lazyfree folio would lose PG_workingset too, which upstream never did
before cc8ec7be78ff. Barry and Kairui just agreed to take this patch
as a clean backport for stable, so that CLRU behaviour change should
go into the cleanup patch with its own justification.

lru_gen_clear_refs() is self-gated on gen >= 0, so the call is a
no-op for folios that are not on a generation list, and the return
value it computes shares the cacheline lruvec_del_folio() touches
right after. I will send the cleanup, with the open-coded clearing
and the stub in one place, once this lands.

Best,
Hui

>
>>   	lruvec_del_folio(lruvec, folio);
>>   	folio_clear_active(folio);
>> -	if (lru_gen_enabled())
>> -		lru_gen_clear_refs(folio);
>> -	else
>> -		folio_clear_referenced(folio);
>> +	folio_clear_referenced(folio);
>>   	/*
>>   	 * Lazyfree folios are clean anonymous folios.  They have
>>   	 * the swapbacked flag cleared, to distinguish them from normal
>> -- 
>> 2.43.0
>>


      reply	other threads:[~2026-11-12  1:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-09  2:16 [PATCH v3] mm/mglru: fix a no-op lru_gen_clear_refs() call in lru_lazyfree() Hui Zhu
2026-11-09  4:51 ` Andrew Morton
2026-11-09  5:08   ` Barry Song
2026-11-11  1:48     ` Bo Zhang
2026-11-11 15:45 ` Kairui Song
2026-11-11 17:21 ` Liam R. Howlett
2026-11-12  1:57   ` Hui Zhu [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=5e2733ee-7a25-430f-bdda-f89fc5856e5d@linux.dev \
    --to=hui.zhu@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=david@kernel.org \
    --cc=kasong@tencent.com \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=rppt@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    --cc=yuzhao@google.com \
    --cc=zhuhui@kylinos.cn \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.