summaryrefslogtreecommitdiff
path: root/arch/x86/crypto/aegis128-aesni-glue.c
diff options
context:
space:
mode:
authorArd Biesheuvel <ard.biesheuvel@linaro.org>2018-07-29 17:52:30 +0300
committerHerbert Xu <herbert@gondor.apana.org.au>2018-08-07 12:26:23 +0300
commitf10dc56c64bb662822475304508c1ce99f194e70 (patch)
tree56cea69b3ba97105e84a7d28ac782000c745b8d6 /arch/x86/crypto/aegis128-aesni-glue.c
parent46d8c4b28652d35dc6cfb5adf7f54e102fc04384 (diff)
downloadlinux-f10dc56c64bb662822475304508c1ce99f194e70.tar.xz
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 7b67ae4d5ce8e2f912377f5fbccb95811a92097f and partially reverts commit 7c50136a8aba8784f07fb66a950cc61a7f3d2ee3. Fixes: 7c50136a8aba ("crypto: arm64/aes-ghash - yield NEON after every ...") Fixes: 7b67ae4d5ce8 ("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>
Diffstat (limited to 'arch/x86/crypto/aegis128-aesni-glue.c')
0 files changed, 0 insertions, 0 deletions