All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Li Qiang <liqiang64@huawei.com>
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: Thu, 5 Nov 2020 10:21:55 -0800	[thread overview]
Message-ID: <20201105182155.GA2555324@gmail.com> (raw)
In-Reply-To: <5b528637-5cb9-a134-2936-7925afae95c6@huawei.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Li Qiang <liqiang64@huawei.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Will Deacon <will@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Alexandre Torgue <alexandre.torgue@st.com>
Subject: Re: [PATCH 1/1] arm64: Accelerate Adler32 using arm64 SVE instructions.
Date: Thu, 5 Nov 2020 10:21:55 -0800	[thread overview]
Message-ID: <20201105182155.GA2555324@gmail.com> (raw)
In-Reply-To: <5b528637-5cb9-a134-2936-7925afae95c6@huawei.com>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-11-05 18:21 UTC|newest]

Thread overview: 60+ 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 ` l00374334
2020-11-03 12:15 ` [PATCH 1/1] " l00374334
2020-11-03 12:15   ` l00374334
2020-11-03 14:34   ` Ard Biesheuvel
2020-11-03 14:34     ` Ard Biesheuvel
2020-11-03 18:00     ` Dave Martin
2020-11-03 18:00       ` Dave Martin
2020-11-04  9:19       ` Li Qiang
2020-11-04  9:19         ` Li Qiang
2020-11-04 14:49         ` Dave Martin
2020-11-04 14:49           ` Dave Martin
2020-11-05  2:32           ` Li Qiang
2020-11-05  2:32             ` Li Qiang
2020-11-04 17:50       ` Mark Brown
2020-11-04 17:50         ` Mark Brown
2020-11-04 18:13         ` Dave Martin
2020-11-04 18:13           ` Dave Martin
2020-11-04 18:49           ` Mark Brown
2020-11-04 18:49             ` Mark Brown
2020-11-05 17:56             ` Dave Martin
2020-11-05 17:56               ` Dave Martin
2020-11-04  8:01     ` Li Qiang
2020-11-04  8:01       ` Li Qiang
2020-11-04  8:04       ` Ard Biesheuvel
2020-11-04  8:04         ` Ard Biesheuvel
2020-11-04  8:14         ` Li Qiang
2020-11-04  8:14           ` Li Qiang
2020-11-04 17:57   ` Eric Biggers
2020-11-04 17:57     ` Eric Biggers
2020-11-05  2:49     ` Li Qiang
2020-11-05  2:49       ` Li Qiang
2020-11-05  7:51       ` Ard Biesheuvel
2020-11-05  7:51         ` Ard Biesheuvel
2020-11-05  9:05         ` Li Qiang
2020-11-05  9:05           ` Li Qiang
2020-11-05 18:21           ` Eric Biggers [this message]
2020-11-05 18:21             ` Eric Biggers
2020-11-09  6:29             ` Li Qiang
2020-11-09  6:29               ` Li Qiang
2020-11-05 16:53 ` [PATCH 0/1] " Dave Martin
2020-11-05 16:53   ` Dave Martin
2020-11-09  3:43   ` Li Qiang
2020-11-09  3:43     ` Li Qiang
2020-11-10 10:46     ` Dave Martin
2020-11-10 10:46       ` Dave Martin
2020-11-10 13:20       ` Li Qiang
2020-11-10 13:20         ` Li Qiang
2020-11-10 16:07         ` Dave Martin
2020-11-10 16:07           ` Dave Martin
2020-11-12  7:20           ` Li Qiang
2020-11-12  7:20             ` Li Qiang
2020-11-12 11:17             ` Dave Martin
2020-11-12 11:17               ` Dave Martin
2020-11-14  7:31               ` Li Qiang
2020-11-14  7:31                 ` Li Qiang
2020-11-16 15:56                 ` Dave Martin
2020-11-16 15:56                   ` Dave Martin
2020-11-17 12:45                   ` Li Qiang
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=20201105182155.GA2555324@gmail.com \
    --to=ebiggers@kernel.org \
    --cc=alexandre.torgue@st.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=liqiang64@huawei.com \
    --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 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.