Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers3@gmail.com>
To: Benjamin Warnke <4bwarnke@informatik.uni-hamburg.de>
Cc: linux-crypto@vger.kernel.org
Subject: Re: Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram
Date: Tue, 30 Jan 2018 12:24:39 -0800	[thread overview]
Message-ID: <20180130202439.gjnly72x3ebbtxf4@gmail.com> (raw)
In-Reply-To: <450300D8-6A7C-4D63-971A-AB6279C3B3DD@informatik.uni-hamburg.de>

Hi Benjamin,

On Tue, Jan 30, 2018 at 04:08:57PM +0100, Benjamin Warnke wrote:
> Currently ZRAM uses the compression-algorithms from the crypto-api.
> None of the current compression-algorithms in the crypto-api is designed
> to compress 4KiB chunks of data efficiently.
> This patch adds a new compression-algorithm especially designed for ZRAM,
> to compress small pieces of data more efficiently.
> 

This is some interesting work, and I like the idea of doing transforms
specialized for in-memory data.  However, where can I find more information
about this new compression algorithm?  What does "zbewalgo" even stand for /
mean?  Googling it turns up nothing.

You are going to have to be much more specific what you mean by "efficiently".
Efficiency usually implies speed, yet even by your own numbers LZ4 is much
faster than "zbewalgo", both for compression and decompression.

If the goal is to provide an algorithm more tuned for compression ratio than
speed in comparison to LZ4, then the omission of Zstandard from your benchmarks
is strange, especially given that Zstandard is available in the kernel now.

The proposed "zbewalgo" decompressor also doesn't handle invalid inputs, which
means it cannot be used on untrusted data.  This isn't acceptable without
justification (since people may use it on untrusted data, creating security
vulnerabilities), and it also makes it not really a fair comparison with LZ4
since the LZ4 decompressor does handle invalid inputs, at least in the mode
exposed through the crypto API.

Eric

  parent reply	other threads:[~2018-01-30 20:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-30 15:08 Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram Benjamin Warnke
2018-01-30 17:59 ` Stephan Mueller
2018-01-30 19:50   ` Benjamin Warnke
     [not found]   ` <C1EF6641-08EB-436C-AD2A-F2581A5BE3FE@informatik.uni-hamburg.de>
2018-01-30 21:26     ` Stephan Müller
2018-01-30 21:37       ` Benjamin Warnke
2018-01-31  6:40         ` Benjamin Warnke
2018-01-31  8:36           ` Benjamin Warnke
2018-01-30 20:24 ` Eric Biggers [this message]
2018-01-30 21:27   ` Benjamin Warnke

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=20180130202439.gjnly72x3ebbtxf4@gmail.com \
    --to=ebiggers3@gmail.com \
    --cc=4bwarnke@informatik.uni-hamburg.de \
    --cc=linux-crypto@vger.kernel.org \
    /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