Hi,
am I right in the suspicion that the events delivered
by timer_create and timerfd_create are routed via ksoftirqd
before being delivered to the application? Is there any
special reason for this?
In any case in the scenario
- posixcputmr prio 99
- thread A prio 45 with a timerfd loop or timer sigwait loop
- thread B prio 25
- ksoftirqd prio 1
the thread A does not see the timer events until thread
B is done, which is a classical priority inversion case.
Boosting the priority of ksoftirqd to 40 solves it.
Yes I have found the Steven's posting with "You can change
the priority of ksoftirqd. In fact, we made the default
for ksoftirqd poor, to force you to change it." Of course
after pulling hair for a few hours and finally identifying
the culprit myself.
Would it be possible to somehow smuggle this important piece
of information into timer_create and timerfd_create manpages?
Otherwise everyone trying to use timers having at least
one thread with lower prio than the thread using them will
fall into it sooner or later. An application programmer
should not have to have an intimate knowledge on how
the events are routed between the kernel tasks...
Regards
--
Stano
--
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
