Re: [PATCH V7 4/4] softirq: Allow early break the softirq processing loop

[Frederic Weisbecker]

On Fri, Oct 09, 2020 at 04:01:39PM +0100, Qais Yousef wrote:
> On 09/29/20 13:44, Frederic Weisbecker wrote:
> > > that will delay the net_rx/tx softirq to process, Peter's branch
> > > maybe can slove
> > > the problem
> > > git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git core/softirq
> > 
> > It's probably also the right time for me to resume on this patchset:
> > 
> > https://lwn.net/Articles/779564/
> > 
> > In the long term this will allow us to have per vector threads that can be
> > individually triggered upon high loads, and even soft interruptible by
> > other vectors from irq_exit(). Also if several vectors are on high loads
> > at the same time, this leaves the balance decisions to the scheduler instead
> > of all these workarounds we scratch our heads on for several years now.
> > 
> > Besides, I'm convinced that splitting the softirqs is something we want in
> > the long run anyway.
> 
> So if I understood correctly we'll end up with a kthread for each softirq type
> that can be scheduled individually on any CPU following the 'normal' scheduler
> rules, correct?
> 
> If I got it right, I like that. I certainly think having these softirqs as RT
> threads (like irq threads) makes a lot more sense. At least one would be able
> to use priorities to reason about when it's okay to preempt them or not.
> 
> If I got it wrong, why we can't do that?

We can't do that right away because some softirq vectors may rely on the
fact that they can't be interrupted by other softirq vectors. If they use
per cpu data, they can perfectly assume that it's locally softirq-safe
and not use any lock to protect it, provided the data is stricly per-cpu
of course.

So we'll need to check all the softirq handlers and make sure they don't
do such assumption, or fix the site. I can imagine it as an iterative
pushdown just like we did with the big kernel lock.

Thanks.