From: Nick Terrell <terrelln@fb.com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Maninder Singh <maninder1.s@samsung.com>,
"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"davem@davemloft.net" <davem@davemloft.net>,
"minchan@kernel.org" <minchan@kernel.org>,
"ngupta@vflare.org" <ngupta@vflare.org>,
Kees Cook <keescook@chromium.org>,
"anton@enomsg.org" <anton@enomsg.org>,
"ccross@android.com" <ccross@android.com>,
"tony.luck@intel.com" <tony.luck@intel.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"colin.king@canonical.com" <colin.king@canonical.com>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"pankaj.m@samsung.com" <pankaj.m@samsung.com>,
"a.sahrawat@samsung.com" <a.sahrawat@samsung.com>,
"v.narang@samsung.com" <v.narang@samsung.com>,
Yann Collet <cyan@fb.com>
Subject: Re: [PATCH 0/1] cover-letter/lz4: Implement lz4 with dynamic offset length.
Date: Wed, 21 Mar 2018 19:56:10 +0000 [thread overview]
Message-ID: <1663C9A3-7DAC-4A11-894C-C99E07BEDAD2@fb.com> (raw)
In-Reply-To: <20180321082628.GB2746@jagdpanzerIV>
On (03/21/18 10:10), Maninder Singh wrote:
> LZ4 specification defines 2 byte offset length for 64 KB data.
> But in case of ZRAM we compress data per page and in most of
> architecture PAGE_SIZE is 4KB. So we can decide offset length based
> on actual offset value. For this we can reserve 1 bit to decide offset
> length (1 byte or 2 byte). 2 byte required only if ofsset is greater than 127,
> else 1 byte is enough.
>
> With this new implementation new offset value can be at MAX 32 KB.
>
> Thus we can save more memory for compressed data.
>
> results checked with new implementation:-
>
> comression size for same input source
> (LZ4_DYN < LZO < LZ4)
>
> LZO
> =======
> orig_data_size: 78917632
> compr_data_size: 15894668
> mem_used_total: 17117184
>
> LZ4
> ========
> orig_data_size: 78917632
> compr_data_size: 16310717
> mem_used_total: 17592320
>
> LZ4_DYN
> =======
> orig_data_size: 78917632
> compr_data_size: 15520506
> mem_used_total: 16748544
This seems like a reasonable extension to the algorithm, and it looks like
LZ4_DYN is about a 5% improvement to compression ratio on your benchmark.
The biggest question I have is if it is worthwhile to maintain a separate
incompatible variant of LZ4 in the kernel without any upstream for a 5%
gain? If we do want to go forward with this, we should perform more
benchmarks.
I commented in the patch, but because the `dynOffset` variable isn't a
compile time static in LZ4_decompress_generic(), I suspect that the patch
causes a regression in decompression speed for both LZ4 and LZ4_DYN. You'll
need to re-run the benchmarks to first show that LZ4 before the patch
performs the same as LZ4 after the patch. Then re-run the LZ4 vs LZ4_DYN
benchmarks.
I would also like to see a benchmark in user-space (with the code), so we
can see the performance of LZ4 before and after the patch, as well as LZ4
vs LZ4_DYN without anything else going on. I expect the extra branches in
the decoding loop to have an impact on speed, and I would like to see how
big the impact is without noise.
CC-ing Yann Collet, the author of LZ4
next prev parent reply other threads:[~2018-03-21 19:56 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20180321044137epcas5p221e7ee4a0b7464eaa00dad8320f0251d@epcas5p2.samsung.com>
2018-03-21 4:40 ` Maninder Singh
[not found] ` <CGME20180321044149epcas5p12cba1afa5fc0f493a47fe20c4a7394bd@epcas5p1.samsung.com>
2018-03-21 4:40 ` [PATCH 1/1] lz4: " Maninder Singh
2018-03-21 7:49 ` Sergey Senozhatsky
2018-03-21 19:59 ` Nick Terrell
[not found] ` <CGME20180321195916epcas4p1e89e1cc5fd242ee8c348f92f1d1740b0@epcms5p1>
2018-03-22 4:28 ` Maninder Singh
2018-03-22 23:09 ` kbuild test robot
2018-03-22 23:32 ` kbuild test robot
[not found] ` <CGME20180321195916epcas4p1e89e1cc5fd242ee8c348f92f1d1740b0@epcms5p8>
2018-03-23 13:21 ` Vaneet Narang
[not found] ` <CGME20180321044149epcas5p12cba1afa5fc0f493a47fe20c4a7394bd@epcms5p5>
2018-04-02 5:51 ` Maninder Singh
2018-04-03 12:26 ` Sergey Senozhatsky
[not found] ` <CGME20180321044149epcas5p12cba1afa5fc0f493a47fe20c4a7394bd@epcms5p7>
2018-04-03 13:43 ` Vaneet Narang
2018-04-04 1:40 ` Sergey Senozhatsky
2018-03-21 6:41 ` [PATCH 0/1] cover-letter/lz4: " Sergey Senozhatsky
2018-03-21 8:26 ` Sergey Senozhatsky
2018-03-21 19:56 ` Nick Terrell [this message]
2018-03-22 2:43 ` Sergey Senozhatsky
[not found] ` <CGME20180321044137epcas5p221e7ee4a0b7464eaa00dad8320f0251d@epcms5p6>
2018-03-23 13:43 ` Vaneet Narang
2018-03-29 10:26 ` Maninder Singh
2018-03-30 5:41 ` Sergey Senozhatsky
[not found] ` <CGME20180321044137epcas5p221e7ee4a0b7464eaa00dad8320f0251d@epcms5p4>
2018-04-16 10:21 ` Maninder Singh
2018-04-16 19:34 ` Yann Collet
2018-04-16 20:01 ` Eric Biggers
[not found] ` <CGME20180321044137epcas5p221e7ee4a0b7464eaa00dad8320f0251d@epcms5p3>
2018-04-02 6:03 ` Maninder Singh
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=1663C9A3-7DAC-4A11-894C-C99E07BEDAD2@fb.com \
--to=terrelln@fb.com \
--cc=a.sahrawat@samsung.com \
--cc=akpm@linux-foundation.org \
--cc=anton@enomsg.org \
--cc=ccross@android.com \
--cc=colin.king@canonical.com \
--cc=cyan@fb.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=keescook@chromium.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maninder1.s@samsung.com \
--cc=minchan@kernel.org \
--cc=ngupta@vflare.org \
--cc=pankaj.m@samsung.com \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=tony.luck@intel.com \
--cc=v.narang@samsung.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
all inboxes | Powered by JetHome®