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 -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
