]> git.baikalelectronics.ru Git - kernel.git/commit
crypto: arm64 - revert NEON yield for fast AEAD implementations
authorArd Biesheuvel <ard.biesheuvel@linaro.org>
Sun, 29 Jul 2018 14:52:30 +0000 (16:52 +0200)
committerHerbert Xu <herbert@gondor.apana.org.au>
Tue, 7 Aug 2018 09:26:23 +0000 (17:26 +0800)
commit685f06aa057de13491902d9fd624e21beb52c983
tree56cea69b3ba97105e84a7d28ac782000c745b8d6
parenta12b093282c688a8ef5294eef1e21d526f7c970e
crypto: arm64 - revert NEON yield for fast AEAD implementations

As it turns out, checking the TIF_NEED_RESCHED flag after each
iteration results in a significant performance regression (~10%)
when running fast algorithms (i.e., ones that use special instructions
and operate in the < 4 cycles per byte range) on in-order cores with
comparatively slow memory accesses such as the Cortex-A53.

Given the speed of these ciphers, and the fact that the page based
nature of the AEAD scatterwalk API guarantees that the core NEON
transform is never invoked with more than a single page's worth of
input, we can estimate the worst case duration of any resulting
scheduling blackout: on a 1 GHz Cortex-A53 running with 64k pages,
processing a page's worth of input at 4 cycles per byte results in
a delay of ~250 us, which is a reasonable upper bound.

So let's remove the yield checks from the fused AES-CCM and AES-GCM
routines entirely.

This reverts commit 98e170fefa7635ec7c3a0d7704842f8a352b9026 and
partially reverts commit 1bb22f91f5b9cc7163e747d53dc26c6b70975bf4.

Fixes: 1bb22f91f5b9 ("crypto: arm64/aes-ghash - yield NEON after every ...")
Fixes: 98e170fefa76 ("crypto: arm64/aes-ccm - yield NEON after every ...")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
arch/arm64/crypto/aes-ce-ccm-core.S
arch/arm64/crypto/ghash-ce-core.S