From: Frederic Weisbecker <frederic@kernel.org>
To: Qais Yousef <qais.yousef@arm.com>
Cc: jun qian <qianjun.kernel@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
peterz@infradead.org, will@kernel.org, luto@kernel.org,
linux-kernel@vger.kernel.org, Yafang Shao <laoar.shao@gmail.com>,
Uladzislau Rezki <urezki@gmail.com>
Subject: Re: [PATCH V7 4/4] softirq: Allow early break the softirq processing loop
Date: Tue, 13 Oct 2020 12:43:57 +0200 [thread overview]
Message-ID: <20201013104357.GB47577@lothringen> (raw)
In-Reply-To: <20201009150139.vatmppe2e3cwtoof@e107158-lin.cambridge.arm.com>
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.
next prev parent reply other threads:[~2020-10-13 10:44 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-15 11:56 [PATCH V7 0/4] Softirq:avoid large sched delay from the pending softirqs qianjun.kernel
2020-09-15 11:56 ` [PATCH V7 1/4] softirq: Use sched_clock() based timeout qianjun.kernel
2020-09-24 8:34 ` Thomas Gleixner
2020-09-15 11:56 ` [PATCH V7 2/4] softirq: Factor loop termination condition qianjun.kernel
2020-09-24 8:36 ` Thomas Gleixner
2020-09-24 12:31 ` Thomas Gleixner
2020-09-15 11:56 ` [PATCH V7 3/4] softirq: Rewrite softirq processing loop qianjun.kernel
2020-09-15 11:56 ` [PATCH V7 4/4] softirq: Allow early break the " qianjun.kernel
2020-09-24 15:37 ` Thomas Gleixner
2020-09-24 23:08 ` Frederic Weisbecker
2020-09-24 23:10 ` Frederic Weisbecker
2020-09-25 22:37 ` Thomas Gleixner
2020-09-25 0:42 ` Frederic Weisbecker
2020-09-25 22:42 ` Thomas Gleixner
2020-09-26 12:22 ` Frederic Weisbecker
2020-09-28 10:51 ` jun qian
2020-09-29 11:44 ` Frederic Weisbecker
2020-10-09 15:01 ` Qais Yousef
2020-10-13 10:43 ` Frederic Weisbecker [this message]
2020-10-13 12:40 ` Qais Yousef
2020-09-26 2:00 ` jun qian
2020-09-27 1:05 ` [softirq] 56c21abbe6: will-it-scale.per_process_ops -9.1% regression kernel test robot
2020-09-28 9:20 ` [PATCH V7 4/4] softirq: Allow early break the softirq processing loop Peter Zijlstra
2020-09-28 11:15 ` jun qian
2020-09-28 9:22 ` Peter Zijlstra
2020-09-28 10:09 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201013104357.GB47577@lothringen \
--to=frederic@kernel.org \
--cc=laoar.shao@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.com \
--cc=qianjun.kernel@gmail.com \
--cc=tglx@linutronix.de \
--cc=urezki@gmail.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox