lkml.org 
[lkml]   [2020]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH V7 4/4] softirq: Allow early break the softirq processing loop
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@google.com/

Thanks

--
Qais Yousef

\
 
 \ /
  Last update: 2020-10-13 14:40    [W:0.088 / U:0.668 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site