On 2021-01-18 17:10:15 [+0100], Sebastien Laveze wrote: > Hi, Hi, > In the end, it seems my most viable option at the moment is to move to > clock_nanosleep() but it implies radical changes in my application > architecture as it's not as scalable and flexible as timerfd. > > Any hints on how to "secure" the wake-up latency of timer fds or what > is expected in future works would be greatly appreciated ! Splitting the timer-wakeups back into ktimersoftd would look like helping. But note that all timer wake ups would happen there - even the accumulated case where we have to wake 100 tasks at once. This would then probably ask for split on SCHED_OTHER vs RT tasks like it is done for clock_nanosleep(). > Thanks, > Seb Sebastian
