On Fri, Nov 25, 2022 at 09:59:17AM +0100, Ard Biesheuvel wrote: > On arm64, this is implemented in an assembler macro 'cond_yield' so we > don't need to preserve/restore the SIMD state state at all if the > yield is not going to result in a call to schedule(). For example, the > SHA3 code keeps 400 bytes of state in registers, which we don't want > to save and reload unless needed. (5f6cb2e617681 'crypto: > arm64/sha512-ce - simplify NEON yield') That sounds like the optimal approach. There is a cost to unnecessary kernel_fpu_begin()/end() calls - increasing their usage in the x86 sha512 driver added 929 us during one boot. The cond_yield check is just a few memory reads and conditional branches. I see that is built on the asm-offsets.c technique mentioned by Dave Hansen in the x86 aria driver thread. > Note that it is only used in shash implementations, given that they > are the only ones that may receive unbounded inputs. Although typical usage probably doesn't stress this, the length of the additional associated data presented to aead implementations is unconstrained as well. At least in x86, they can end up processing multiple megabytes in one chunk like the hash functions (if the associated data is a big buffer described by a sg list created with sg_init_one()).
