linux-kernel - Re: [PATCH] zram: Add a huge

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:   Tue, 22 Mar 2022 14:13:09 -0700
From:   Minchan Kim <minchan@...nel.org>
To:     Brian Geffon <bgeffon@...gle.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Nitin Gupta <ngupta@...are.org>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-block@...r.kernel.org
Subject: Re: [PATCH] zram: Add a huge_idle writeback mode

On Mon, Mar 21, 2022 at 07:50:37AM -0700, Brian Geffon wrote:
> Today it's only possible to write back as a page, idle, or huge.
> A user might want to writeback pages which are huge and idle first
> as these idle pages do not require decompression and make a good
> first pass for writeback.
> 
> Idle writeback specifically has the advantage that a refault is
> unlikely given that the page has been swapped for some amount of
> time without being refaulted.
> 
> Huge writeback has the advantage that you're guaranteed to get
> the maximum benefit from a single page writeback, that is, you're
> reclaiming one full page of memory. Pages which are compressed in
> zram being written back result in some benefit which is always
> less than a page size because of the fact that it was compressed.
> 
> This change allows for users to write back huge pages which are
> also idle.

Hey Brian,

I really want to add your explanation about the storage endurance
because it's real issue.

So, could't you add up below in the description?

>From your previous reply
"
we're trying to be very sensitive to our devices storage endurance,
for this reason we will have a fairly conservative writeback limit.
Given that, we want to make sure we're maximizing what lands on disk
while still minimizing the refault time. We could take the approach
where we always writeback huge pages but then we may result in very
quick refaults which would be a huge waste of time. So idle writeback
is a must for us and being able to writeback the pages which have
maximum value (huge) would be very useful
"

> 
> Signed-off-by: Brian Geffon <bgeffon@...gle.com>

Other than that, feel free to add my
Acked-by: Minchan Kim <minchan@...nel.org>

Thanks.