I was looking at irq_poll and for missing scheduling points. It raised the question why are there 7 driver still using irq_poll and not moved on to something else like threaded interrupts or kworker. There is: - Infiband can complete direct, irq_poll and kworker. - be2iscsi only irq_poll. - cxlflash only irq_poll. Not sure how IRQs are acked. - ipr direct or irq_poll, can be configured. Now sure how IRQs are acked. - lpfc kworker and/or irq_poll. Not sure all invocations are from interrupts like context [0]. - megaraid irq_poll. Not sure all invocations are from interrupts like context [0]. - mpt3sas irq_poll or io_uring io poll. Not sure all invocations are from interrupts like context [0]. [0] If irq_poll_sched() is not used from an interrupt (as in interrupt service routine, timer handler, tasklet (not encouraging just noticed)) but from task context (as in kworker for instance) then irq-poll handler will not be invoked right away. Instead it will be delayed to random point in time until an interrupt fires or something down the stack performs a pending softirq check. Waking ksoftirqd itself isn't helping much since it will set a NEED_RESCHED bit in the task_struct which local_irq_restore() isn't testing for. So the scheduling event is delayed until spin_unlock() for instance. Is there a reason for the remaining user of irq_poll to keep using it? Sebastian
