public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Subject: Re: [RFC][PATCH 0/4] zram: add zlib compression bckend support
Date: Mon, 23 May 2016 14:53:30 +0900	[thread overview]
Message-ID: <20160523055330.GC6266@bbox> (raw)
In-Reply-To: <1439474123-11279-1-git-send-email-sergey.senozhatsky@gmail.com>

Hello Sergey,

I talked with Joonsoo today and he has no time to support it at the moment
and I can't wait zlib support for zram until crypto work is merged.
So, I want to merge your work.
If you have an interest, still, could you mind resending the work
rebased on recent zram?

Thanks.

On Thu, Aug 13, 2015 at 10:55:19PM +0900, Sergey Senozhatsky wrote:
> Hello,
> 
> RFC
> 
> I'll just post this series as a separate thread, I guess, sorry if it makes
> any inconvenience. Joonsoo will resend his patch series, so discussions
> will `relocate' anyway.
> 
> This patchset uses a different, let's say traditional, zram/zcomp approach.
> it defines a new zlib compression backend same way as lzo ad lz4 are defined.
> 
> The key difference is that zlib requires zstream for both compression and
> decompression. zram has stream-less decompression path for lzo and lz4, and
> it works perfectly fast. In order to support zlib we need decompression
> path to *optionally require* zstream. I want to make ZCOMP_NEED_READ_ZSTRM
> flag (backend requires zstream for decompression) backend dependent; so we
> still will have fastest lzo/lz4 possible.
> 
> This is one of the reasons I didn't implement it using crypto api -- crypto
> api requires tfm for compression and decompression. Which implies that read
> now either
> a) has to share idle streams list with write path, thus reads and writes will
> become slower
> b) has to define its own idle stream list. but it does
>    1) limit the number of concurrently executed read operations (to the number
>       of stremas in the list)
>    2) increase memory usage by the module (each streams occupies pages for
>       workspace buffers, etc.)
> 
> For the time being, crypto API does not provide stream-less decompression
> functions, to the best of my knowledge.
> 
> 
> I, frankly, tempted to rewrite zram to use crypto several times. But each
> time I couldn't find a real reason. Yes, it *in theory* will give people
> HUGE possibilities to select compression algorithms. But the question
> is -- zram has been around for quite some years, so does anybody need this
> flexibility? I can easily picture people selecting between
> 
>        ratio                         speed                       alg
>   OK compression ratio             very fast                   LZO/LZ4
> and
>   very good comp ratio      eh... but good comp ratio           zlib
> 
> 
> But anything in the middle is just anything in the middle, IMHO. I can't
> convince myself that people really want to have
>       "eh... comp ration" + "eh.. speed"
> comp algorithm, for example.
> 
> 
> From https://code.google.com/p/lz4/ it seems that lzo+lz4+zlib is quite a
> good package.
> 
> And zram obviously was missing the `other side' algorithm -- zlib, when IO speed
> is not SO important.
> 
> 
> 
> I did some zlib backend testing. A copy paste from patch 0003:
> 
> 
> Copy dir with the linux kernel to a zram device (du -sh 2.3G) and check
> memory usage stats.
> 
> mm_stat fields:
>         orig_data_size
>         compr_data_size
>         mem_used_total
>         mem_limit
>         mem_used_max
>         zero_pages
>         num_migrated
> 
> zlib
> cat /sys/block/zram0/mm_stat
> 2522685440 1210486447 1230729216        0 1230729216     5461        0
> 
> lzo
> cat /sys/block/zram0/mm_stat
> 2525872128 1713351248 1738387456        0 1738387456     4682        0
> 
> ZLIB uses 484+MiB less memory in the test.
> 
> 
> 
> Sergey Senozhatsky (4):
>   zram: introduce zcomp_backend flags callback
>   zram: extend zcomp_backend decompress callback
>   zram: add zlib backend
>   zram: enable zlib backend support
> 
>  drivers/block/zram/Kconfig      |  14 ++++-
>  drivers/block/zram/Makefile     |   1 +
>  drivers/block/zram/zcomp.c      |  30 +++++++++-
>  drivers/block/zram/zcomp.h      |  12 +++-
>  drivers/block/zram/zcomp_lz4.c  |   8 ++-
>  drivers/block/zram/zcomp_lzo.c  |   8 ++-
>  drivers/block/zram/zcomp_zlib.c | 120 ++++++++++++++++++++++++++++++++++++++++
>  drivers/block/zram/zcomp_zlib.h |  17 ++++++
>  drivers/block/zram/zram_drv.c   |  23 ++++++--
>  9 files changed, 222 insertions(+), 11 deletions(-)
>  create mode 100644 drivers/block/zram/zcomp_zlib.c
>  create mode 100644 drivers/block/zram/zcomp_zlib.h
> 
> -- 
> 2.5.0
> 

  parent reply	other threads:[~2016-05-23  5:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-13 13:55 [RFC][PATCH 0/4] zram: add zlib compression bckend support Sergey Senozhatsky
2015-08-13 13:55 ` [RFC][PATCH 1/4] zram: introduce zcomp_backend flags callback Sergey Senozhatsky
2015-08-13 13:55 ` [RFC][PATCH 2/4] zram: extend zcomp_backend decompress callback Sergey Senozhatsky
2015-08-13 13:55 ` [RFC][PATCH 3/4] zram: add zlib backend Sergey Senozhatsky
2015-08-13 13:55 ` [RFC][PATCH 4/4] zram: enable zlib backend support Sergey Senozhatsky
2016-05-23  5:53 ` Minchan Kim [this message]
2016-05-23 14:59   ` [RFC][PATCH 0/4] zram: add zlib compression bckend support Sergey Senozhatsky

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=20160523055330.GC6266@bbox \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sergey.senozhatsky@gmail.com \
    /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