linux-kernel - Re: [External] Re: [RFC PATCH] zswap: add writeback_time

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]

Message-ID: <20231012142203.GB470544@cmpxchg.org>
Date:   Thu, 12 Oct 2023 10:22:03 -0400
From:   Johannes Weiner <hannes@...xchg.org>
To:     贺中坤 <hezhongkun.hzk@...edance.com>
Cc:     Nhat Pham <nphamcs@...il.com>, akpm@...ux-foundation.org,
        yosryahmed@...gle.com, sjenning@...hat.com, ddstreet@...e.org,
        vitaly.wool@...sulko.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [External] Re: [RFC PATCH] zswap: add writeback_time_threshold
 interface to shrink zswap pool

On Thu, Oct 12, 2023 at 10:13:16PM +0800, 贺中坤 wrote:
> Hi Nhat, thanks for your detailed reply.
> 
> > We're currently trying to solve this exact problem. Our approach is to
> > add a shrinker that automatically shrinks the size of the zswap pool:
> >
> > https://lore.kernel.org/lkml/20230919171447.2712746-1-nphamcs@gmail.com/
> >
> > It is triggered on memory-pressure, and can perform reclaim in a
> > workload-specific manner.
> >
> > I'm currently working on v3 of this patch series, but in the meantime,
> > could you take a look and see if it will address your issues as well?
> >
> > Comments and suggestions are always welcome, of course :)
> >
> 
> Thanks, I've seen both patches. But we hope to be able to reclaim memory
> in advance, regardless of memory pressure, like memory.reclaim in memcg,
> so we can offload memory in different tiers.

Can you use memory.reclaim itself for that? With Nhat's shrinker, it
should move the whole pipeline (LRU -> zswap -> swap).

> Thanks for your review，we should update the store time when it was loaded.
> But it confused me, there are two copies of the same page in memory
> (compressed and uncompressed) after faulting in a page from zswap if
> 'zswap_exclusive_loads_enabled' was disabled. I didn't notice any difference
> when turning that option on or off because the frontswap_ops has been removed
> and there is no frontswap_map anymore. Sorry, am I missing something?

In many instances, swapins already free the swap slot through the
generic swap code (see should_try_to_free_swap()). It matters for
shared pages, or for swapcaching read-only data when swap isn't full -
it could be that isn't the case in your tests.