On 8/13/20 11:11 AM, Sebastian Andrzej Siewior wrote:
On 2020-08-13 09:53:57 [+0200], Lars-Peter Clausen wrote:
On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft
interrupt expiry mode by default.
The IIO hrtimer-trigger needs to run in hard interrupt context since it
will end up calling generic_handle_irq() which has the requirement to run
in hard interrupt context.
Explicitly specify that the timer needs to run in hard interrupt context by
using the HRTIMER_MODE_REL_HARD flag.
No, I don't think that this is good. It basically renders threaded-irqs
in context of IIO useless. This also requires that the IRQ-handler in
question runs with IRQs disabled / uses raw_spinlock_t which is in not
good idea either.
It should not affect the IRQ handlers of individual drivers. The hrtimer
triggers acts like an IRQ chip and will call generic_handle_irq() to
multiplex the interrupt handling onto all consumers. As far as I
understand it there is a requirement that generic_handle_irq() is called
in hard irq context, even with PREEMT_RT=y.
If you are running with forced IRQ threads the only thing that will then
happen in the actual hard IRQ context is the launching of the IRQ
threads. Th e IRQ handler of the device driver will run in a threaded IRQ.
Has this change (including the second patch in thread) been tested on RT
in terms of locking and latency?
It has not been tested in terms of latency. But like I said if you are
running with forced IRQ threads the effect should be minimal.
Without this patch there is an correctness issue when PREEMT_RT=y since
generic_handle_irq() runs with interrupts on which breaks its internal
assumptions.
