aboutsummaryrefslogtreecommitdiff
path: root/arch/s390/crypto/sha256_s390.c
diff options
context:
space:
mode:
authorEric Biggers <ebiggers@google.com>2018-06-29 17:01:44 -0700
committerHerbert Xu <herbert@gondor.apana.org.au>2018-07-09 00:30:21 +0800
commit8aeef492fe248e0e56d888e2d5432724ac45f80d (patch)
treec75c0f7e1937956859ec7e095cb24f83d10c72bc /arch/s390/crypto/sha256_s390.c
parente47890163a3c2a6ec5a18322d283046d1bdec5e6 (diff)
downloadlinux-8aeef492fe248e0e56d888e2d5432724ac45f80d.tar.gz
crypto: x86/sha-mb - decrease priority of multibuffer algorithms
With all the crypto modules enabled on x86, and with a CPU that supports AVX-2 but not SHA-NI instructions (e.g. Haswell, Broadwell, Skylake), the "multibuffer" implementations of SHA-1, SHA-256, and SHA-512 are the highest priority. However, these implementations only perform well when many hash requests are being submitted concurrently, filling all 8 AVX-2 lanes. Otherwise, they are incredibly slow, as they waste time waiting for more requests to arrive before proceeding to execute each request. For example, here are the speeds I see hashing 4096-byte buffers with a single thread on a Haswell-based processor: generic avx2 mb (multibuffer) ------- -------- ---------------- sha1 602 MB/s 997 MB/s 0.61 MB/s sha256 228 MB/s 412 MB/s 0.61 MB/s sha512 312 MB/s 559 MB/s 0.61 MB/s So, the multibuffer implementation is 500 to 1000 times slower than the other implementations. Note that with smaller buffers or more update()s per digest, the difference would be even greater. I believe the vast majority of people are in the boat where the multibuffer code is much slower, and only a small minority are doing the highly parallel, hashing-intensive, latency-flexible workloads (maybe IPsec on servers?) where the multibuffer code may be beneficial. Yet, people often aren't familiar with all the crypto config options and so the multibuffer code may inadvertently be built into the kernel. Also the multibuffer code apparently hasn't been very well tested, seeing as it was sometimes computing the wrong SHA-256 digest. So, let's make the multibuffer algorithms low priority. Users who want to use them can either request them explicitly by driver name, or use NETLINK_CRYPTO (crypto_user) to increase their priority at runtime. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'arch/s390/crypto/sha256_s390.c')
0 files changed, 0 insertions, 0 deletions