Messages in this thread | | | Date | Wed, 16 Nov 2022 11:37:08 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH v5 3/3] softirq: defer softirq processing to ksoftirqd if CPU is busy with RT |
| |
On Wed, Nov 16, 2022 at 07:59:28AM +0000, John Stultz wrote: > From: Pavankumar Kondeti <pkondeti@codeaurora.org> > > Defer the softirq processing to ksoftirqd if a RT task is > running or queued on the current CPU. This complements the RT > task placement algorithm which tries to find a CPU that is not > currently busy with softirqs. > > Currently NET_TX, NET_RX, BLOCK and IRQ_POLL softirqs are only > deferred as they can potentially run for long time. > > Additionally, this patch stubs out ksoftirqd_running() logic, > in the CONFIG_RT_SOFTIRQ_AWARE_SCHED case, as deferring > potentially long-running softirqs will cause the logic to not > process shorter-running softirqs immediately. By stubbing it out > the potentially long running softirqs are deferred, but the > shorter running ones can still run immediately.
So I'm hating on the new config space, and dubious of the placement logic (I'm thinking much the same gain can be had when actual softirq processing stops quickly when we want to reschedule).
However I still have these here patches (revived from the dead):
https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=core/softirq
That fix some of this same... I think the last time this fell on its face due to regressions and me not having time/energy to chase them down and the author of the hack-of-the-day solution walking off or something like that.
I think this aspect of the whole softirq thing really needs fixing first and not hidden under some obscure CONFIG symbol.
| |