From: peterz@infradead.org
To: Qais Yousef <qais.yousef@arm.com>
Cc: qianjun.kernel@gmail.com, tglx@linutronix.de, will@kernel.org,
luto@kernel.org, linux-kernel@vger.kernel.org,
laoar.shao@gmail.com, urezki@gmail.com,
John Dias <joaodias@google.com>, Wei Wang <wvw@google.com>,
Quentin Perret <qperret@google.com>
Subject: Re: [PATCH V6 1/1] Softirq:avoid large sched delay from the pending softirqs
Date: Mon, 14 Sep 2020 16:14:37 +0200 [thread overview]
Message-ID: <20200914141437.GR1362448@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20200914112735.6ivyy2iqlyqatzn7@e107158-lin.cambridge.arm.com>
On Mon, Sep 14, 2020 at 12:27:35PM +0100, Qais Yousef wrote:
> What does PREEMPT_RT do to deal with softirqs delays?
Makes the lot preemptible, you found the patch below.
> I have tried playing with enabling threadirqs, which AFAIU should make softirqs
> preemptible, right?
Not yet,..
> I realize this patch is still missing from mainline at least:
>
> https://gitlab.com/kalilinux/packages/linux/blob/a17bad0db9da44cd73f594794a58cc5646393b13/debian/patches-rt/softirq-Add-preemptible-softirq.patch
>
> Would this be a heavy handed approach to make available for non PREEMPT_RT
> kernels?
Not sure, I suspect it relies on migrate_disable(), which is
preempt_disable() on !RT and then we're back to square one.
> I only worry about potential NET_RX throughput issues. Which by the way is
> protected with preempt_disable currently in mainline. See netif_rx_ni().
So preempt_disable() isn't necessairily a problem, you just want it to
terminate soonish after need_resched() becomes true. Also, I'm having a
wee problem getting from net_rx_action() to netif_rx_ni()
> I am guessing here, but I suspect this NET_RX softirq is one source of big
> delays when network activity is high.
Well, one approach is to more agressively limit how long softirq
processing can run. Current measures are very soft in that regard.
next prev parent reply other threads:[~2020-09-14 14:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-09 9:09 [PATCH V6 1/1] Softirq:avoid large sched delay from the pending softirqs qianjun.kernel
2020-09-11 15:55 ` peterz
2020-09-12 7:17 ` jun qian
2020-09-11 16:46 ` Qais Yousef
2020-09-11 18:28 ` peterz
2020-09-14 11:27 ` Qais Yousef
2020-09-14 14:14 ` peterz [this message]
2020-09-14 15:28 ` Qais Yousef
[not found] ` <CA+njcd3HFV5Gqtt9qzTAzpnA4-4ngPBQ7T0gwgc0Fm9_VoJLcQ@mail.gmail.com>
2020-09-14 11:41 ` Qais Yousef
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=20200914141437.GR1362448@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=joaodias@google.com \
--cc=laoar.shao@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=qais.yousef@arm.com \
--cc=qianjun.kernel@gmail.com \
--cc=qperret@google.com \
--cc=tglx@linutronix.de \
--cc=urezki@gmail.com \
--cc=will@kernel.org \
--cc=wvw@google.com \
/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