[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAPL-u_Pxt-xb7wChDsVntVXZvHGXAMkTAqBC+XgwJSrVpwY8g@mail.gmail.com>
Date: Mon, 14 Oct 2024 16:47:30 -0700
From: Wei Xu <weixugc@...gle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Yu Zhao <yuzhao@...gle.com>, Brian Geffon <bgeffon@...gle.com>,
Jan Alexander Steffens <heftig@...hlinux.org>, Suleiman Souhlal <suleiman@...gle.com>,
Axel Rasmussen <axelrasmussen@...gle.com>, linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] mm/mglru: reset page lru tier bits when activating
On Mon, Oct 14, 2024 at 4:27 PM Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> On Mon, 14 Oct 2024 22:12:31 +0000 Wei Xu <weixugc@...gle.com> wrote:
>
> > folio_activate() calls lru_gen_add_folio() to move the folio to the
> > youngest generation. But unlike folio_update_gen()/folio_inc_gen(),
> > lru_gen_add_folio() doesn't reset the folio lru tier bits
> > (LRU_REFS_MASK | LRU_REFS_FLAGS). Fix this inconsistency in
> > lru_gen_add_folio() when activating a folio.
>
> What are the runtime effects of this flaw?
It can affect how pages get aged via the MGLRU PID controller, though
no bad behaviors clearly related to this have been detected at
runtime. The fix is to address this inconsistency identified via code
inspection.
Powered by blists - more mailing lists