Re: Undesirable priority inversion for real-time threads that use timerfd

[Sebastian Andrzej Siewior <sebastian.siewior@linutronix.de>]

On 2016-09-02 17:25:55 [-0700], Joachim Achtzehnter wrote:
> The only downside of this fix is that all timeouts used by low-priority
> threads, presumably even non-real-time threads, will briefly preempt our
> high-priority threads, although hopefully not for long, hence there may be
> some impact on throughput.

_all_ timers which are not marked as irq_safe are deferred here to the
timersoftirq. This is because they take (possible long standing)
sleeping locks.

> A possibly more optimal approach would be to have a separate ktimersoftd
> thread for every priority at which threads wait for timer notifications. We
you don't know this in advance. You are in hardirq context and a hrtimer
expires. You invoke the timerfd callback, need to take a sleeping lock
to figure out who is waiting on this. *That* is the point you learn
about the waiter.

> could potentially build such a facility in user code, as long as there is
> some timer available that is not dependent on ktimersoftd. What about Posix
> timers? Would they have the same issue? Anything else we should be looking
> at?

posix timers have the same issue. Basically all timers which are not
marked as irq_safe are completed in ktimersoftd. If you look at
clock_nanosleep() you will see that it is marked as irqsafe and the wake
up happens in hardirq.

Btw: the situation got better once we got ktimersoftd. Before that it
was a little worse.

> Thanks,
> 
> Joachim

Sebastian