fscrypt: use unbound workqueue for decryption
authorEric Biggers <ebiggers@google.com>
Fri, 20 Apr 2018 23:30:02 +0000 (16:30 -0700)
committerJaegeuk Kim <jaegeuk@kernel.org>
Thu, 28 Jun 2018 03:24:46 +0000 (20:24 -0700)
commitfc30ddc3b0395261e0392f93aba9033cd1f96b68
treed701795e9d96ed8b53ceac7473c844d26ea9e96e
parent787f7faccfcc778c97411777b2fe5d84ea9bd1ca
fscrypt: use unbound workqueue for decryption

Improve fscrypt read performance by switching the decryption workqueue
from bound to unbound.  With the bound workqueue, when multiple bios
completed on the same CPU, they were decrypted on that same CPU.  But
with the unbound queue, they are now decrypted in parallel on any CPU.

Although fscrypt read performance can be tough to measure due to the
many sources of variation, this change is most beneficial when
decryption is slow, e.g. on CPUs without AES instructions.  For example,
I timed tarring up encrypted directories on f2fs.  On x86 with AES-NI
instructions disabled, the unbound workqueue improved performance by
about 25-35%, using 1 to NUM_CPUs jobs with 4 or 8 CPUs available.  But
with AES-NI enabled, performance was unchanged to within ~2%.

I also did the same test on a quad-core ARM CPU using xts-speck128-neon
encryption.  There performance was usually about 10% better with the
unbound workqueue, bringing it closer to the unencrypted speed.

The unbound workqueue may be worse in some cases due to worse locality,
but I think it's still the better default.  dm-crypt uses an unbound
workqueue by default too, so this change makes fscrypt match.

Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
fs/crypto/crypto.c