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

Message-ID: <CACSyD1NdYL4whDURJOC7_gqhpuqjbqsOkUacxS78iZm1pZCW9A@mail.gmail.com>
Date:   Fri, 13 Oct 2023 22:02:14 +0800
From:   贺中坤 <hezhongkun.hzk@...edance.com>
To:     Yosry Ahmed <yosryahmed@...gle.com>
Cc:     akpm@...ux-foundation.org, hannes@...xchg.org, nphamcs@...il.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

Thanks for your reply.
> I prefer if this can be done through memory.reclaim when the zswap
> shrinker is in place, as others have suggested. I understand that this
> provides more control by specifying the time at which to start writing
> pages out, which is similar to zram writeback AFAICT, but it is also
> difficult to determine the right value to write here.
>
> I am also not sure how you decide that it is better to writeback cold
> pages in zswap or compress cold pages in the LRUs. The pages in zswap
> are obviously colder, but accessing them after they are written back
> is much more expensive, to the point that it could be better to
> compress more cold memory from the LRUs. This is obviously not
> straightforward and requires a fair amount of tuning to do more good
> than harm.

I do agree.  For some applications, a common value will work,
such as 600s. Besides, this patch provides a more flexible way
to offload compress pages.

>
> That being said, if we decide to move forward with this I have a
> couple of comments:
>
> - I think you should check out how zram implements idle writeback and
> try to make things consistent. Zswap and zram don't really see eye to
> eye, but some consistency would be nice. If you looked at zram's
> implementation you would realize that you also need to update the
> access time when a page is read (unless the load is exclusive).

Thanks for your suggestion，i will fix it and check it again.

>
> - This should be behind a config option. Every word that we add to
> struct zswap_entry reduces the zswap savings by roughly 0.2%. Maybe
> this doesn't sound like much but it adds up. Let's not opt everyone in
> unless they ask for it.
>

Good idea， Thanks.