[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKEwX=MxRTupSoYbnr14wTurbBhJ7KipV3YuEofab2JJxsk3cg@mail.gmail.com>
Date: Mon, 29 Jan 2024 16:12:54 -0800
From: Nhat Pham <nphamcs@...il.com>
To: Yosry Ahmed <yosryahmed@...gle.com>
Cc: Chengming Zhou <zhouchengming@...edance.com>, Johannes Weiner <hannes@...xchg.org>,
Andrew Morton <akpm@...ux-foundation.org>, Chris Li <chriscli@...gle.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v2 1/3] mm/zswap: don't return LRU_SKIP if we have dropped
lru lock
On Mon, Jan 29, 2024 at 4:09 PM Yosry Ahmed <yosryahmed@...gle.com> wrote:
>
> On Sun, Jan 28, 2024 at 01:28:49PM +0000, Chengming Zhou wrote:
> > LRU_SKIP can only be returned if we don't ever dropped lru lock, or
> > we need to return LRU_RETRY to restart from the head of lru list.
> >
> > Otherwise, the iteration might continue from a cursor position that
> > was freed while the locks were dropped.
>
> Does this warrant a stable backport?
IUC, the zswap shrinker was merged in 6.8, and we're still in the RC's
for 6.8, right? If this patch goes into 6.8 then no need?
Otherwise, yeah it should go to 6.8 stable IMHO.
>
> >
> > Actually we may need to introduce another LRU_STOP to really terminate
> > the ongoing shrinking scan process, when we encounter a warm page
> > already in the swap cache. The current list_lru implementation
> > doesn't have this function to early break from __list_lru_walk_one.
> >
> > Fixes: b5ba474f3f51 ("zswap: shrink zswap pool based on memory pressure")
> > Acked-by: Johannes Weiner <hannes@...xchg.org>
> > Reviewed-by: Nhat Pham <nphamcs@...il.com>
> > Signed-off-by: Chengming Zhou <zhouchengming@...edance.com>
>
> Acked-by: Yosry Ahmed <yosryahmed@...gle.com>
Powered by blists - more mailing lists