Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [PATCH 3/3] softirq: don't yield if only expedited handlers are pending | Date | Fri, 03 Mar 2023 15:17:17 +0100 |
| |
Jakub!
On Thu, Dec 22 2022 at 14:12, Jakub Kicinski wrote: > This leads to a situation where we go thru the softirq loop twice. > First round we have pending = NET (from the NIC IRQ/NAPI), and > the second iteration has pending = TASKLET (the socket tasklet).
...
> diff --git a/kernel/softirq.c b/kernel/softirq.c > index ad200d386ec1..4ac59ffb0d55 100644 > --- a/kernel/softirq.c > +++ b/kernel/softirq.c > @@ -601,7 +601,7 @@ asmlinkage __visible void __softirq_entry __do_softirq(void) > > if (time_is_before_eq_jiffies(end) || !--max_restart) > limit = SOFTIRQ_OVERLOAD_TIME; > - else if (need_resched()) > + else if (need_resched() && pending & ~SOFTIRQ_NOW_MASK) > limit = SOFTIRQ_DEFER_TIME; > else > goto restart;
While this is the least of my softirq worries on PREEMPT_RT, Peter is right about real-time tasks being deferred on a PREEMPT_RT=n kernel. That's a real issue for low-latency audio which John Stultz is trying to resolve. Especially as the above check can go in circles.
I fear we need to go back to the drawing board and come up with a real solution which takes these contradicting aspects into account. Let me stare at Peters and Johns patches for a while.
Thanks
tglx
| |