Re: timerfd performances

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [RT Stable]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux