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:32 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.