On 2020-12-18 08:18:05 [-0800], Alison Chaiken wrote: > > Having a thread to run the tick-timer would avoid that scenario. > > > > Didn't ktimersoftd used to be such a thread? It's still not entirely > clear to me at least why it was removed. Yes, ktimersoftd was such a thread that is why I am suggesting it. It would be probably just a quick duct tape. All of the reasons why it has been introduced disappeared in the previous softirq rework. The NAPI handover works, posixtimer need no additional love and so on (the original motivation to have it). The problem, that Paul reported, should also exist for !RT with the `threadirqs' switch (untested but it is the same code). It is worth noting that in his report the latency was increased because the timer-tick woke the ksoftirqd thread. Rightfully you could say that this would not have happen with the timer thread. However, the usb-storage driver (just to pick an easy to trigger scenario for my case) also wakes the ksoftirqd if a transfer completes. If the ethernet interrupt fires before ksoftirqd completes its task then we have the same situation without the involvement of the timer :) > -- Alison Chaiken > Aurora Innovation Sebastian
