On Tue, Feb 23, 2021 at 09:27:44PM -0800, Yury Norov wrote:

On Tue, Dec 08, 2020 at 10:35:50AM +0000, Will Deacon wrote:

quoted

On Mon, Dec 07, 2020 at 05:59:16PM -0800, Yury Norov wrote:

quoted

(CC: Alexey Klimov)

On Mon, Dec 7, 2020 at 3:25 AM Will Deacon [off-list ref] wrote:

quoted

On Sat, Dec 05, 2020 at 08:54:06AM -0800, Yury Norov wrote:

quoted

ARM64 doesn't implement find_first_{zero}_bit in arch code and doesn't
enable it in config. It leads to using find_next_bit() which is less
efficient:

[...]

quoted

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1515f6f153a0..2b90ef1f548e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig

@@ -106,6 +106,7 @@ config ARM64
      select GENERIC_CPU_AUTOPROBE
      select GENERIC_CPU_VULNERABILITIES
      select GENERIC_EARLY_IOREMAP
+     select GENERIC_FIND_FIRST_BIT

Does this actually make any measurable difference? The disassembly with
or without this is _very_ similar for me (clang 11).

Will

On A-53 find_first_bit() is almost twice faster than find_next_bit(),
according to
lib/find_bit_benchmark. (Thanks to Alexey for testing.)

I guess it's more compiler dependent than anything else, and it's a pity
that find_next_bit() isn't implemented in terms of the generic
find_first_bit() tbh, but if the numbers are as you suggest then I don't
have a problem selecting this on arm64.

Ping?

Not sure what happened to this. Maybe resend at -rc1?

Will

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