linux-kernel - Re: [PATCH 0/3] Allow ZRAM to use any zpool-compatible backend

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: <CAMJBoFOqG8GYby-MLCgiYgsfntNP2hiX25WibxvUjpkLHvwsUQ@mail.gmail.com>
Date:   Tue, 15 Oct 2019 09:39:35 +0200
From:   Vitaly Wool <vitalywool@...il.com>
To:     Minchan Kim <minchan@...nel.org>
Cc:     Linux-MM <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Dan Streetman <ddstreet@...e.org>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Shakeel Butt <shakeelb@...gle.com>,
        Henry Burns <henrywolfeburns@...il.com>,
        "Theodore Ts'o" <tytso@...nk.org>
Subject: Re: [PATCH 0/3] Allow ZRAM to use any zpool-compatible backend

Hi Minchan,

On Mon, Oct 14, 2019 at 6:41 PM Minchan Kim <minchan@...nel.org> wrote:
>
> On Thu, Oct 10, 2019 at 11:04:14PM +0300, Vitaly Wool wrote:
> > The coming patchset is a new take on the old issue: ZRAM can currently be used only with zsmalloc even though this may not be the optimal combination for some configurations. The previous (unsuccessful) attempt dates back to 2015 [1] and is notable for the heated discussions it has caused.
> >
> > The patchset in [1] had basically the only goal of enabling ZRAM/zbud combo which had a very narrow use case. Things have changed substantially since then, and now, with z3fold used widely as a zswap backend, I, as the z3fold maintainer, am getting requests to re-interate on making it possible to use ZRAM with any zpool-compatible backend, first of all z3fold.
> >
> > The preliminary results for this work have been delivered at Linux Plumbers this year [2]. The talk at LPC, though having attracted limited interest, ended in a consensus to continue the work and pursue the goal of decoupling ZRAM from zsmalloc.
> >
> > The current patchset has been stress tested on arm64 and x86_64 devices, including the Dell laptop I'm writing this message on now, not to mention several QEmu confugirations.
> >
> > [1] https://lkml.org/lkml/2015/9/14/356
> > [2] https://linuxplumbersconf.org/event/4/contributions/551/
>
> Please describe what's the usecase in real world, what's the benefit zsmalloc
> cannot fulfill by desgin and how it's significant.

I'm not entirely sure how to interpret the phrase "the benefit
zsmalloc cannot fulfill by design" but let me explain.
First, there are multi multi core systems where z3fold can provide
better throughput.
Then, there are low end systems with hardware
compression/decompression support which don't need zsmalloc
sophistication and would rather use zbud with ZRAM because the
compression ratio is relatively low.
Finally, there are MMU-less systems targeting IOT and still running
Linux and having a compressed RAM disk is something that would help
these systems operate in a better way (for the benefit of the overall
Linux ecosystem, if you care about that, of course; well, some people
do).

> I really don't want to make fragmentaion of allocator so we should really see
> how zsmalloc cannot achieve things if you are claiming.

I have to say that this point is completely bogus. We do not create
fragmentation by using a better defined and standardized API. In fact,
we aim to increase the number of use cases and test coverage for ZRAM.
With that said, I have hard time seeing how zsmalloc can operate on a
MMU-less system.

> Please tell us how to test it so that we could investigate what's the root
> cause.

I gather you haven't read neither the LPC documents nor my
conversation with Sergey re: these changes, because if you did you
wouldn't have had the type of questions you're asking. Please also see
above.

I feel a bit awkward explaining basic things to you but there may not
be other "root cause" than applicability issue. zsmalloc is a great
allocator but it's not universal and has its limitations. The
(potential) scope for ZRAM is wider than zsmalloc can provide. We are
*helping* _you_ to extend this scope "in real world" (c) and you come
up with bogus objections. Why?

Best regards,
   Vitaly