Subject: Re: [PATCH 3/3] softirq: don't yield if only expedited handlers are pending

From: Thomas Gleixner <[email-masked]>
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