From: Li Qiang <liqiang64@huawei.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Ard Biesheuvel <ardb@kernel.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@st.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: [PATCH 1/1] arm64: Accelerate Adler32 using arm64 SVE instructions.
Date: Mon, 9 Nov 2020 14:29:51 +0800 [thread overview]
Message-ID: <9b6eb382-9965-562b-346e-5afaca1589c7@huawei.com> (raw)
In-Reply-To: <20201105182155.GA2555324@gmail.com>
在 2020/11/6 2:21, Eric Biggers 写道:
> On Thu, Nov 05, 2020 at 05:05:53PM +0800, Li Qiang wrote:
>>
>>
>> 在 2020/11/5 15:51, Ard Biesheuvel 写道:
>>> Note that NEON intrinsics can be compiled for 32-bit ARM as well (with
>>> a bit of care - please refer to lib/raid6/recov_neon_inner.c for an
>>> example of how to deal with intrinsics that are only available on
>>> arm64) and are less error prone, so intrinsics should be preferred if
>>> feasible.
>>>
>>> However, you have still not explained how optimizing Adler32 makes a
>>> difference for a real-world use case. Where is libdeflate used on a
>>> hot path?
>>> .
>>
>> Sorry :(, I have not specifically searched for the use of this algorithm
>> in the kernel.
>>
>> When I used perf to test the performance of the libz library before,
>> I saw that the adler32 algorithm occupies a lot of hot spots.I just
>> saw this algorithm used in the kernel code, so I think optimizing this
>> algorithm may have some positive optimization effects on the kernel.:)
>
> Adler32 performance is important for zlib compression/decompression, which has a
> few use cases in the kernel such as btrfs compression. However, these days
> those few kernel use cases are mostly switching to newer algorithms like lz4 and
> zstd. Also as I mentioned, your patch doesn't actually wire up your code to be
> used by the kernel's implementation of zlib compression/decompression.
>
> I think you'd be much better off contributing to a userspace project, where
> DEFLATE/zlib/gzip support still has a long tail of use cases. The official zlib
> isn't really being maintained and isn't accepting architecture-specific
> optimizations, but there are some performance-oriented forks of zlib (e.g.
> https://chromium.googlesource.com/chromium/src/third_party/zlib/ and
> https://github.com/zlib-ng/zlib-ng), as well as other projects like libdeflate
> (https://github.com/ebiggers/libdeflate). Generally I'm happy to accept
> architecture-specific optimizations in libdeflate, but they need to be testable.
>
> - Eric
> .
>
Thank you for your answers and suggestions. I have not seen these repositories
before. Regarding the SVE implementation of adler32, I will focus on the
repositories you mentioned later.:)
--
Best regards,
Li Qiang
next prev parent reply other threads:[~2020-11-09 6:29 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-03 12:15 [PATCH 0/1] arm64: Accelerate Adler32 using arm64 SVE instructions l00374334
2020-11-03 12:15 ` [PATCH 1/1] " l00374334
2020-11-03 14:34 ` Ard Biesheuvel
2020-11-03 18:00 ` Dave Martin
2020-11-04 9:19 ` Li Qiang
2020-11-04 14:49 ` Dave Martin
2020-11-05 2:32 ` Li Qiang
2020-11-04 17:50 ` Mark Brown
2020-11-04 18:13 ` Dave Martin
2020-11-04 18:49 ` Mark Brown
2020-11-05 17:56 ` Dave Martin
2020-11-04 8:01 ` Li Qiang
2020-11-04 8:04 ` Ard Biesheuvel
2020-11-04 8:14 ` Li Qiang
2020-11-04 17:57 ` Eric Biggers
2020-11-05 2:49 ` Li Qiang
2020-11-05 7:51 ` Ard Biesheuvel
2020-11-05 9:05 ` Li Qiang
2020-11-05 18:21 ` Eric Biggers
2020-11-09 6:29 ` Li Qiang [this message]
2020-11-05 16:53 ` [PATCH 0/1] " Dave Martin
2020-11-09 3:43 ` Li Qiang
2020-11-10 10:46 ` Dave Martin
2020-11-10 13:20 ` Li Qiang
2020-11-10 16:07 ` Dave Martin
2020-11-12 7:20 ` Li Qiang
2020-11-12 11:17 ` Dave Martin
2020-11-14 7:31 ` Li Qiang
2020-11-16 15:56 ` Dave Martin
2020-11-17 12:45 ` Li Qiang
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=9b6eb382-9965-562b-346e-5afaca1589c7@huawei.com \
--to=liqiang64@huawei.com \
--cc=alexandre.torgue@st.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=davem@davemloft.net \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=mcoquelin.stm32@gmail.com \
--cc=will@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