linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC] mm/crypto: add tunable compression algorithm for zswap
Date: Mon, 3 Apr 2017 14:35:30 +0900	[thread overview]
Message-ID: <20170403053530.GA7463@bbox> (raw)
In-Reply-To: <20170401211813.15146-1-vbabka@suse.cz>

On Sat, Apr 01, 2017 at 11:18:13PM +0200, Vlastimil Babka wrote:
> Zswap (and zram) save memory by compressing pages instead of swapping them
> out. This is nice, but with traditional compression algorithms such as LZO,
> one cannot know, how well the data will compress, so the overal savings are
> unpredictable. This is further complicated by the choice of zpool
> implementation for managing the compressed pages. Zbud and z3fold are
> relatively simple, but cannot store more then 2 (zbud) or 3 (z3fold)
> compressed pages in a page. The rest of the page is wasted. Zsmalloc is more
> flexible, but also more complex.
> 
> Clearly things would be much easier if the compression ratio was predictable.
> But why stop at that - what if we could actually *choose* the compression
> ratio? This patch introduces a new compression algorithm that can do just
> that! It's called Tunable COmpression, or TCO for short.

That was totally same I had an idea since long time ago but I don't
have enough to dive into that.
Thanks for raising an issue!

> 
> In this prototype patch, it offers three predefined ratios, but nothing
> prevents more fine-grained settings, except the current crypto API (or my
> limited knowledge of it, but I'm guessing nobody really expected the
> compression ratio to be tunable). So by doing
> 
> echo tco50 > /sys/module/zswap/parameters/compressor
> 
> you get 50% compression ratio, guaranteed! This setting and zbud are just the
> perfect buddies, if you prefer the nice and simple allocator. Zero internal
> fragmentation!
> 
> Or,
> 
> echo tco30 > /sys/module/zswap/parameters/compressor
> 
> is a great match for z3fold, if you want to be smarter and save 50% memory
> over zbud, again with no memory wasted! But why stop at that? If you do
> 
> echo tco10 > /sys/module/zswap/parameters/compressor

It's a great idea but a problem is we have very limited allocators.
In short future, people might want z4fold, z8fold, z10fold and so on.
So, I suggest to make zbud generic so it can cover every zXfold allocators.

> 
> within the next hour, and choose zsmalloc, you will be able to neatly store
> 10 compressed pages within a single page! Yes, 90% savings!
> In the full version of this patch, you'll be able to set any ratio, so you
> can decide exactly how much money to waste on extra RAM instead of compressing
> the data. Let TCO cut down your system's TCO!
> 
> This RFC was not yet tested, but it compiles fine and mostly passes checkpatch
> so it must obviously work.

I did test and found sometime crash happens but it's hard to reproduce.
It seems it's easier to reprocue the problem with tco50.

Even though I stare at the code in detail, I can't find any bugs.
Hmm, If there is an update in your side, let me know it.

Thanks.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      parent reply	other threads:[~2017-04-03  5:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-01 21:18 Vlastimil Babka
2017-04-02 13:56 ` Matthew Wilcox
2017-04-03  5:35 ` Minchan Kim [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170403053530.GA7463@bbox \
    --to=minchan@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox