On Sat, 19 Dec 2020 at 03:05, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > 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. > Any insights here? Is there a ballpark upper bound for the duration of a softirq disabled section? Other reasons why dis/enabling softirq handling is a bad idea?
