On Thu, Apr 16 2020 at 15:59, Sebastian Andrzej Siewior wrote: > any comments from the timer department?
Yes. > On 2019-11-27 18:37:19 [+0100], To Eric Dumazet wrote: >> On 2019-11-27 09:11:40 [-0800], Eric Dumazet wrote: >> > Resent in non HTML mode :/ >> don't worry, mutt handles both :) >> >> > Long story short, why hrtimer are not by default using threaded mode >> > in threadirqs mode ? >> >> Because it is only documented to thread only interrupts. Not sure if we >> want change this. >> In RT we expire most of the hrtimers in softirq context for other >> reasons. A subset of them still expire in hardirq context. >> >> > Idea of having some (but not all of them) hard irq handlers' now being >> > run from BH mode, >> > is rather scary. >> >> As I explained in my previous email: All IRQ-handlers fire in >> threaded-mode if enabled. Only the hrtimer is not affected by this >> change. >> >> > Also, hrtimers got the SOFT thing only in 4.16, while the GRO patch >> > went in linux-3.19 >> > >> > What would be the plan for stable trees ? >> No idea yet. We could let __napi_schedule_irqoff() behave like >> __napi_schedule(). It's not really a timer departement problem. It's an interrupt problem. With force threaded interrupts we don't call the handler with interrupts disabled. What sounded a good idea long ago, is actually bad. See https://lore.kernel.org/r/87eegdzzez....@nanos.tec.linutronix.de Any leftover issues on a RT kernel are a different story, but for !RT this is the proper fix. I'll spin up a proper patch and tag it for stable... Thanks, tglx
