From: wen.yang@linux.dev
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org, linux-kernel@vger.kernel.org,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Wen Yang <wen.yang@linux.dev>
Subject: [PATCH 6.1 2/3] net: Remove conditional threaded-NAPI wakeup based on task state.
Date: Mon, 19 Jan 2026 00:40:32 +0800 [thread overview]
Message-ID: <e2e05047bca5eedd98eca0afefafe0802abf0e05.1768754220.git.wen.yang@linux.dev> (raw)
In-Reply-To: <cover.1768754220.git.wen.yang@linux.dev>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
commit 56364c910691f6d10ba88c964c9041b9ab777bd6 upstream.
A NAPI thread is scheduled by first setting NAPI_STATE_SCHED bit. If
successful (the bit was not yet set) then the NAPI_STATE_SCHED_THREADED
is set but only if thread's state is not TASK_INTERRUPTIBLE (is
TASK_RUNNING) followed by task wakeup.
If the task is idle (TASK_INTERRUPTIBLE) then the
NAPI_STATE_SCHED_THREADED bit is not set. The thread is no relying on
the bit but always leaving the wait-loop after returning from schedule()
because there must have been a wakeup.
The smpboot-threads implementation for per-CPU threads requires an
explicit condition and does not support "if we get out of schedule()
then there must be something to do".
Removing this optimisation simplifies the following integration.
Set NAPI_STATE_SCHED_THREADED unconditionally on wakeup and rely on it
in the wait path by removing the `woken' condition.
Acked-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Wen Yang <wen.yang@linux.dev>
---
net/core/dev.c | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index e35f41e75bdd..83475b8b3e9d 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4447,13 +4447,7 @@ static inline void ____napi_schedule(struct softnet_data *sd,
*/
thread = READ_ONCE(napi->thread);
if (thread) {
- /* Avoid doing set_bit() if the thread is in
- * INTERRUPTIBLE state, cause napi_thread_wait()
- * makes sure to proceed with napi polling
- * if the thread is explicitly woken from here.
- */
- if (READ_ONCE(thread->__state) != TASK_INTERRUPTIBLE)
- set_bit(NAPI_STATE_SCHED_THREADED, &napi->state);
+ set_bit(NAPI_STATE_SCHED_THREADED, &napi->state);
wake_up_process(thread);
return;
}
@@ -6672,8 +6666,6 @@ static int napi_poll(struct napi_struct *n, struct list_head *repoll)
static int napi_thread_wait(struct napi_struct *napi)
{
- bool woken = false;
-
set_current_state(TASK_INTERRUPTIBLE);
while (!kthread_should_stop()) {
@@ -6682,15 +6674,13 @@ static int napi_thread_wait(struct napi_struct *napi)
* Testing SCHED bit is not enough because SCHED bit might be
* set by some other busy poll thread or by napi_disable().
*/
- if (test_bit(NAPI_STATE_SCHED_THREADED, &napi->state) || woken) {
+ if (test_bit(NAPI_STATE_SCHED_THREADED, &napi->state)) {
WARN_ON(!list_empty(&napi->poll_list));
__set_current_state(TASK_RUNNING);
return 0;
}
schedule();
- /* woken being true indicates this thread owns this napi. */
- woken = true;
set_current_state(TASK_INTERRUPTIBLE);
}
__set_current_state(TASK_RUNNING);
--
2.25.1
next prev parent reply other threads:[~2026-01-18 16:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-18 16:40 [PATCH 6.1 0/3] net: Backlog NAPI threading for PREEMPT_RT wen.yang
2026-01-18 16:40 ` [PATCH 6.1 1/3] net: napi_schedule_rps() cleanup wen.yang
2026-01-18 16:40 ` wen.yang [this message]
2026-01-18 16:40 ` [PATCH 6.1 3/3] net: Allow to use SMP threads for backlog NAPI wen.yang
2026-02-03 15:52 ` [PATCH 6.1 0/3] net: Backlog NAPI threading for PREEMPT_RT Greg Kroah-Hartman
-- strict thread matches above, loose matches on Subject: below --
2026-01-18 16:15 [PATCH 6.6 " wen.yang
2026-01-18 16:15 ` [PATCH 6.6 2/3] net: Remove conditional threaded-NAPI wakeup based on task state wen.yang
2026-01-18 16:17 ` [PATCH 6.1 " wen.yang
2026-01-18 16:28 ` wen.yang
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=e2e05047bca5eedd98eca0afefafe0802abf0e05.1768754220.git.wen.yang@linux.dev \
--to=wen.yang@linux.dev \
--cc=bigeasy@linutronix.de \
--cc=gregkh@linuxfoundation.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stable@vger.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