Re: [RFC] mm/crypto: add tunable compression algorithm for zswap

[Minchan Kim]

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.