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