Messages in this thread | | | Date | Thu, 30 Sep 2021 12:56:05 +0200 | From | Sebastian Andrzej Siewior <> | Subject | [RFC] Is lib/irq_poll still considered useful? |
| |
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
| |