linux-kernel - Re: [PATCH 1/2] zswap: implement a second chance algorithm for dynamic zswap shrinker

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] [day] [month] [year] [list]

Message-ID: <CAKEwX=OTSD37qznj9dquA=VKHxGBkdu2d=cYZRwTshsjwtGcBA@mail.gmail.com>
Date: Tue, 30 Jul 2024 15:04:34 -0700
From: Nhat Pham <nphamcs@...il.com>
To: Yosry Ahmed <yosryahmed@...gle.com>
Cc: Johannes Weiner <hannes@...xchg.org>, akpm@...ux-foundation.org, linux-mm@...ck.org, 
	kernel-team@...a.com, linux-kernel@...r.kernel.org, flintglass@...il.com, 
	Chengming Zhou <chengming.zhou@...ux.dev>, Shakeel Butt <shakeel.butt@...ux.dev>
Subject: Re: [PATCH 1/2] zswap: implement a second chance algorithm for
 dynamic zswap shrinker

On Tue, Jul 30, 2024 at 11:46 AM Yosry Ahmed <yosryahmed@...gle.com> wrote:
>
> I also think it's important to clarify that there are two mechanisms
> that control the writeback rate with this patch, the reference bit
> proportional slowdown (protecting against writeback of recently
> swapped out pages), and nr_swapins protection (feedback from swapins
> of recently written back pages).

Regarding this - perhaps I wasn't being clear, but I did include both
in the changelog. The latter is this paragraph:

"We will still maintain the count of swapins, which is consumed and
subtracted from the lru size in zswap_shrinker_count(), to further
penalize past overshrinking that led to disk swapins. The idea is that
had we considered this many more pages in the LRU active/protected, they
would not have been written back and we would not have had to swapped
them in."

I also replicate this comment in the nr_swapin explanation - see
struct zswap_lruvec_state.

Same goes with the second chance algorithm - I did briefly explain it
in shrink_memcg_cb(), as well as the changelog.

>
> Maybe we can move things around to make it more obvious how these
> mechanisms work hand in hand, or have a comment somewhere describing
> the writeback mechanism.

Hmm let me add some documentation for this near
zswap_shrinker_{scan|count}() definitions: