On Fri, Dec 18, 2020 at 06:01:01PM +0100, Ard Biesheuvel wrote: > > Questions: > - what did I miss or break horribly? > - does any of this matter for RT? AIUI, RT runs softirqs from a dedicated > kthread, so I don't think it cares. > - what would be a reasonable upper bound to keep softirqs disabled? I suppose > 100s of cycles or less is overkill, but I'm not sure how to derive a better > answer. > - could we do the same on x86, now that kernel_fpu_begin/end is no longer > expensive? If this approach works not only would it allow us to support the synchronous users better, it would also allow us to remove loads of cruft in the Crypto API that exist solely to support these SIMD code paths. So I eagerly await the assessment of the scheduler/RT folks on this approach. Thanks, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
