On 2021-01-22 14:23:06 [+0100], Sebastien Laveze wrote: > On Fri, 2021-01-22 at 13:30 +0100, Sebastian Andrzej Siewior wrote: > > 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(). > I didn't know there was a difference in the wakeup mechanism when using > clock_nanosleep if the task was RT or not but that makes sense indeed. > (just looking at __hrtimer_init_sleeper) > > So basically, if re-introduced, the ktimersoftd (with a RT priority by > default) would only handle the wakeup of RT tasks ? Other non-RT > POSIX/timerfd users would still be woken-up by ksoftirqd ? On top of my head, yes. There might be a better way. Using one thread at prio 1 would mix the wakeup of all threads with various priorities. This is not a problem for clock_nanosleep() because it can be woken up directly from the hardirq. > Thx, > Seb Sebastian