From: Jakub Kicinski <kuba@kernel.org>
To: peterz@infradead.org, tglx@linutronix.de
Cc: jstultz@google.com, edumazet@google.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>
Subject: [PATCH 3/3] softirq: don't yield if only expedited handlers are pending
Date: Thu, 22 Dec 2022 14:12:44 -0800 [thread overview]
Message-ID: <20221222221244.1290833-4-kuba@kernel.org> (raw)
In-Reply-To: <20221222221244.1290833-1-kuba@kernel.org>
In networking we try to keep Tx packet queues small, so we limit
how many bytes a socket may packetize and queue up. Tx completions
(from NAPI) notify the sockets when packets have left the system
(NIC Tx completion) and the socket schedules a tasklet to queue
the next batch of frames.
This leads to a situation where we go thru the softirq loop twice.
First round we have pending = NET (from the NIC IRQ/NAPI), and
the second iteration has pending = TASKLET (the socket tasklet).
On two web workloads I looked at this condition accounts for 10%
and 23% of all ksoftirqd wake ups respectively. We run NAPI
which wakes some process up, we hit need_resched() and wake up
ksoftirqd just to run the TSQ (TCP small queues) tasklet.
Tweak the need_resched() condition to be ignored if all pending
softIRQs are "non-deferred". The tasklet would run relatively
soon, anyway, but once ksoftirqd is woken we're risking stalls.
I did not see any negative impact on the latency in an RR test
on a loaded machine with this change applied.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
kernel/softirq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/softirq.c b/kernel/softirq.c
index ad200d386ec1..4ac59ffb0d55 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -601,7 +601,7 @@ asmlinkage __visible void __softirq_entry __do_softirq(void)
if (time_is_before_eq_jiffies(end) || !--max_restart)
limit = SOFTIRQ_OVERLOAD_TIME;
- else if (need_resched())
+ else if (need_resched() && pending & ~SOFTIRQ_NOW_MASK)
limit = SOFTIRQ_DEFER_TIME;
else
goto restart;
--
2.38.1
next prev parent reply other threads:[~2022-12-22 22:13 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-22 22:12 [PATCH 0/3] softirq: uncontroversial change Jakub Kicinski
2022-12-22 22:12 ` [PATCH 1/3] softirq: rename ksoftirqd_running() -> ksoftirqd_should_handle() Jakub Kicinski
2022-12-22 22:12 ` [PATCH 2/3] softirq: avoid spurious stalls due to need_resched() Jakub Kicinski
2023-01-31 22:32 ` Jakub Kicinski
2023-03-03 13:30 ` Thomas Gleixner
2023-03-03 15:18 ` Thomas Gleixner
2023-03-03 21:31 ` Jakub Kicinski
2023-03-03 22:37 ` Paul E. McKenney
2023-03-03 23:25 ` Dave Taht
2023-03-04 1:14 ` Paul E. McKenney
2023-03-03 23:36 ` Paul E. McKenney
2023-03-03 23:44 ` Jakub Kicinski
2023-03-04 1:25 ` Paul E. McKenney
2023-03-04 1:39 ` Jakub Kicinski
2023-03-04 3:11 ` Paul E. McKenney
2023-03-04 20:48 ` Paul E. McKenney
2023-03-05 20:43 ` Thomas Gleixner
2023-03-05 22:42 ` Paul E. McKenney
2023-03-05 23:00 ` Frederic Weisbecker
2023-03-06 4:30 ` Paul E. McKenney
2023-03-06 11:22 ` Frederic Weisbecker
2023-03-06 9:13 ` David Laight
2023-03-06 11:57 ` Frederic Weisbecker
2023-03-06 14:57 ` Paul E. McKenney
2023-03-07 0:51 ` Jakub Kicinski
2022-12-22 22:12 ` Jakub Kicinski [this message]
2023-01-09 9:44 ` [PATCH 3/3] softirq: don't yield if only expedited handlers are pending Peter Zijlstra
2023-01-09 10:16 ` Eric Dumazet
2023-01-09 19:12 ` Jakub Kicinski
2023-03-03 11:41 ` Thomas Gleixner
2023-03-03 14:17 ` Thomas Gleixner
2023-04-20 17:24 ` [PATCH 0/3] softirq: uncontroversial change Paolo Abeni
2023-04-20 17:41 ` Eric Dumazet
2023-04-20 20:23 ` Paolo Abeni
2023-04-21 2:48 ` Jason Xing
2023-04-21 9:33 ` Paolo Abeni
2023-04-21 9:46 ` Jason Xing
2023-05-09 19:56 ` [tip: irq/core] Revert "softirq: Let ksoftirqd do its job" tip-bot2 for Paolo Abeni
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=20221222221244.1290833-4-kuba@kernel.org \
--to=kuba@kernel.org \
--cc=edumazet@google.com \
--cc=jstultz@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.