On Mon, 27 Nov 2023 at 14:46, Mark Rutland <mark.rutland@xxxxxxx> wrote: > > On Mon, Nov 27, 2023 at 01:23:04PM +0100, Ard Biesheuvel wrote: > > From: Ard Biesheuvel <ardb@xxxxxxxxxx> > > > > Some classes of crypto algorithms (such as skciphers or aeads) have > > natural yield points, but SIMD based shashes yield the NEON unit > > manually to avoid causing scheduling blackouts when operating on large > > inputs. > > > > This is no longer necessary now that kernel mode NEON runs with > > preemption enabled, so remove this logic from the crypto assembler code, > > along with the macro that implements the TIF_NEED_RESCHED check. > > > > Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx> > > I definitely want to get rid of all of the voluntary preemption points, but > IIUC for the moment we need to keep these for PREEMPT_NONE and > PREEMPT_VOLUNTARY (and consequently for PREEMPT_DYNAMIC). Once the preemption > rework lands, these should no longer be necessary and can be removed: > > https://lore.kernel.org/lkml/20231107215742.363031-1-ankur.a.arora@xxxxxxxxxx/ > Oh, right - yeah, good point. So until that lands, we could at least simplify cond_yield and go back to the original logic, given that yielding to a pending softirq will no longer be necessary. (The original logic does not deal with softirqs specifically, but relies on the preempt_count() not being equal to PREEMPT_DISABLE_OFFSET to avoid yielding in sofirq context unnecessarily) This also means that only PREEMPT_VOLUNTARY is implicated here - PREEMPT_NONE only has the yield-to-pending-softirq behavior atm.
