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

[Qais Yousef]

On 10/13/20 12:43, Frederic Weisbecker wrote:
> 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 Frederic. I know what to do in my free cycles now ;-)

FWIW, NAPI seems to have learnt the ability to use kthreads (in case you missed
it)

	https://lwn.net/Articles/833840/
	https://lwn.net/ml/netdev/20201002222514.1159492-1-weiwan@xxxxxxxxxx/

Thanks

--
Qais Yousef