From: "Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>
To: Gao Xiang <hsiangkao@aol.com>
Cc: Chris Mason <clm@fb.com>,
gregkh@linuxfoundation.org, Kees Cook <keescook@chromium.org>,
Kernel Team <Kernel-team@fb.com>,
Adam Borowski <kilobyte@angband.pl>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
mingo@kernel.org, Nick Terrell <nickrterrell@gmail.com>,
Norbert Lange <nolange79@gmail.com>, Petr Malat <oss@malat.biz>,
Patrick Williams <patrick@stwcx.xyz>,
Patrick Williams <patrickw3@fb.com>,
rmikey@fb.com, Sedat Dilek <sedat.dilek@gmail.com>,
Nick Terrell <terrelln@fb.com>,
x86@kernel.org
Subject: Re: Kernel compression benchmarks
Date: Wed, 01 Jul 2020 13:32:52 -0400 [thread overview]
Message-ID: <1593624505.w282woxb43.none@localhost> (raw)
In-Reply-To: <20200701153028.GA30962@hsiangkao-HP-ZHAN-66-Pro-G1>
Excerpts from Gao Xiang's message of July 1, 2020 11:50 am:
> Anyway, I think LZMA (xz) is still useful and which is more
> friendly to fixed-sized output compression than Zstd yet (But
> yeah, I'm not familar with all ZSTD internals. I will dig
> into that if I've more extra time).
Yes, I agree. If you look at the graphs, LZMA2 (xz/7zip) still produces
smaller results, even compared to zstd maximum settings, so definitely
LZMA2 should be kept, at least for now. I am only suggesting removing
LZMA, since it has no benefits over xz and zstd combination (bigger than
xz, slower than zstd).
>> - modern compressors (xz, lz4, zstd) decompress about as fast for each
>> compression level, only requiring more memory
>
> lz4 has fixed sliding window (dictionary, 64k), so it won't
> require more memory among different compression level when
> decompressing.
Yes, this is true. I tried to simplify among all compressors, but I
think I simplified too much. Thanks for clarifying.
Cheers,
Alex.
next prev parent reply other threads:[~2020-07-01 17:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1588791882.08g1378g67.none.ref@localhost>
2020-07-01 14:35 ` Kernel compression benchmarks Alex Xu (Hello71)
2020-07-01 15:50 ` Gao Xiang
2020-07-01 17:32 ` Alex Xu (Hello71) [this message]
2020-07-02 15:18 ` Kees Cook
2020-07-03 8:15 ` Sedat Dilek
2020-07-03 16:06 ` Kees Cook
2020-07-03 17:36 ` Norbert Lange
2020-07-06 15:05 ` Nick Terrell
2020-07-26 16:43 Jan Ziak
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=1593624505.w282woxb43.none@localhost \
--to=alex_y_xu@yahoo.ca \
--cc=Kernel-team@fb.com \
--cc=clm@fb.com \
--cc=gregkh@linuxfoundation.org \
--cc=hsiangkao@aol.com \
--cc=keescook@chromium.org \
--cc=kilobyte@angband.pl \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=nickrterrell@gmail.com \
--cc=nolange79@gmail.com \
--cc=oss@malat.biz \
--cc=patrick@stwcx.xyz \
--cc=patrickw3@fb.com \
--cc=rmikey@fb.com \
--cc=sedat.dilek@gmail.com \
--cc=terrelln@fb.com \
--cc=x86@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;
as well as URLs for NNTP newsgroup(s).