[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170913103853.ko3iywrihcgtoiuf@angband.pl>
Date: Wed, 13 Sep 2017 12:38:56 +0200
From: Adam Borowski <kilobyte@...band.pl>
To: Minchan Kim <minchan@...nel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Subject: Re: [PATCH 2/2] zram: remove zlib from the list of recommended
algorithms
On Wed, Sep 13, 2017 at 04:12:46PM +0900, Minchan Kim wrote:
> On Tue, Sep 12, 2017 at 02:00:05PM +0900, Sergey Senozhatsky wrote:
> > ZSTD tends to outperform deflate/inflate, thus we remove
> > zlib from the list of recommended algorithms and recommend
> > zstd instead.
>
> I did test with my sample data and compared zstd with deflate.
> zstd's compress ratio is lower a little bit but compression
> speed is much faster 3 times more and decompress speed is too
> 2 times more. With different data, it is different but overall,
> zstd would be better for speed at the cost of a little lower compress
> ratio(about 5%) so I believe it's worth to replace deflate.
Both zlib and zstd have the compression level adjustable, zstd in a far
greater range (from lzo-like at lowest levels to mid-range lzma at the
highest). Thus, any such comparison needs to mention the used level.
Ie, if you selected a setting where speed is same, compression ratio
will be a lot better.
For compressing RAM it's reasonable to keep to fastest levels, and a
non-adjustable level reduces complexity, but if your use case wants high but
slow compression, now is a good time to mention this.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts
⣾⠁⢰⠒⠀⣿⡁ productivity. You can read it, too, you just need the
⢿⡄⠘⠷⠚⠋⠀ right music while doing so. I recommend Skepticism
⠈⠳⣄⠀⠀⠀⠀ (funeral doom metal).
Powered by blists - more mailing lists