linux-kernel - Re: [PATCH RFC 1/1] mm/swap: queue reclaimable folio to local rotate batch when !folio_test

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 14 Feb 2024 01:13:17 -0600
From: Yu Zhao <yuzhao@...gle.com>
To: chengming.zhou@...ux.dev
Cc: willy@...radead.org, hannes@...xchg.org, yosryahmed@...gle.com, 
	nphamcs@...il.com, akpm@...ux-foundation.org, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org, Chengming Zhou <zhouchengming@...edance.com>
Subject: Re: [PATCH RFC 1/1] mm/swap: queue reclaimable folio to local rotate
 batch when !folio_test_lru()

On Fri, Feb 9, 2024 at 6:00 AM <chengming.zhou@...ux.dev> wrote:
>
> From: Chengming Zhou <zhouchengming@...edance.com>
>
> All LRU move interfaces have a problem that it has no effect if the
> folio is isolated from LRU (in cpu batch or isolated by shrinker).
> Since it can't move/change folio LRU status when it's isolated, mostly
> just clear the folio flag and do nothing in this case.
>
> In our case, a written back and reclaimable folio won't be rotated to
> the tail of inactive list, since it's still in cpu lru_add batch. It
> may cause the delayed reclaim of this folio and evict other folios.
>
> This patch changes to queue the reclaimable folio to cpu rotate batch
> even when !folio_test_lru(), hoping it will likely be handled after
> the lru_add batch which will put folio on the LRU list first, so
> will be rotated to the tail successfully when handle rotate batch.
>
> Signed-off-by: Chengming Zhou <zhouchengming@...edance.com>

I don't think the analysis is correct. IIRC, writeback from non
reclaim paths doesn't require isolation and the reclaim path doesn't
use struct folio_batch lru_add.

Did you see any performance improvements with this patch? In general,
this kind of patches should have performance numbers to show it really
helps (not just in theory).

My guess is that you are hitting this problem [1].

[1] https://lore.kernel.org/linux-mm/20221116013808.3995280-1-yuzhao@googlecom/