From: Clark Williams <clrkwllms@kernel.org>
To: wen.yang@linux.dev
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Steven Rostedt <rostedt@goodmis.org>,
linux-rt-devel@lists.linux.dev
Subject: Re: [PATCH 6.6-rt 0/5] net: Backport backlog-NAPI threads to resolve PREEMPT_RT softirq warning in SMP flush
Date: Mon, 19 Oct 2026 08:20:44 -0500 [thread overview]
Message-ID: <atYZLK0gmG8vRHxG@demetrius> (raw)
In-Reply-To: <cover.1792345413.git.wen.yang@linux.dev>
On Mon, Oct 19, 2026 at 02:15:22AM +0800, wen.yang@linux.dev wrote:
> From: Wen Yang <wen.yang@linux.dev>
>
> Backport backlog-NAPI threads to v6.6-rt-next first, as requested by
> Sebastian and Clark, before following up with the v6.1-rt backport.
> The base is 4c4970859022 (Linux 6.6.151-rt78-rc1).
>
> The existing RT workaround, 1f7514c9c75d ("net: Avoid the IPI to free the"),
> redirects deferred skb cleanup to a worker but leaves RPS remote-backlog
> scheduling on the function-call IPI path. In a fresh RT guest this still
> triggers do_softirq_post_smp_call_flush() from idle queue flushing.
>
> The ten earlier NAPI/RPS prerequisites are already present in v6.6, so this
> series reverts the workaround and backports the four upstream changes (all
> in upstream v6.10) in dependency order. Backlog-NAPI threads replace the
> RPS/defer function-call notifications; ordinary scheduler wakeup IPI traffic
> can still occur. Two of the changes were previously backported to ordinary
> 6.6.y and reverted (507692c05636, 5a530c8ead06) only because PREEMPT_RT is
> absent there, not for a functional defect.
>
> Backport notes
> --------------
> Only 3/5 needs context adaptations; they are listed in that patch's commit
> message. The other four apply without context edits. Unlike v6.1, v6.6 keeps
> WRITE_ONCE(napi->list_owner, ...) because the field already exists here.
>
> Verification
> ------------
> Each of the five stages was replayed against the base snapshot and compiled
> for net/core/dev.o and net/core/skbuff.o. The baseline and final RT/RPS
> bzImages were built with byte-identical normalized configs using GCC 9.4.0,
> with no compiler warnings or errors.
>
> Tests use virtme-ng 1.38, x86_64 QEMU/KVM, four vCPUs and 2 GiB memory:
>
> vng --run <bzImage> --cpus 4 --memory 2G \
> --qemu-opts='-machine accel=kvm' --exec 'bash <script>'
>
> The config enables PREEMPT_RT, SMP, SYSFS, NET_NS, VETH, RPS,
> IRQ_TIME_ACCOUNTING and KPROBES, with NR_CPUS=4. Run the inline script below
> in a fresh guest for each image; it prints one column of the table, and the
> columns are joined outside the guest. It covers both mechanisms: the RPS/IPI
> path (ping flood with RPS steered to CPU1) and the defer_list purge path
> (cross-CPU TCP frees traced with kprobes). See its header for details.
>
Wen,
I just pushed v6.6.159-rt82-rc1 up to the linux-stable-rt repository in
v6.6-rt-next, waiting for kernelci.org to pick it up and test it. I'll
let it soak for a bit so people can test it, then we can release it
later this week.
I'm betting the v6.1-rt series is going to be a bit bigger? :)
Clark
--
The United States Coast Guard
Ruining Natural Selection since 1790
next prev parent reply other threads:[~2026-10-19 13:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-18 18:15 [PATCH 6.6-rt 0/5] net: Backport backlog-NAPI threads to resolve PREEMPT_RT softirq warning in SMP flush wen.yang
2026-10-18 18:15 ` [PATCH 6.6-rt 1/5] Revert "net: Avoid the IPI to free the" wen.yang
2026-10-18 18:15 ` [PATCH 6.6-rt 2/5] net: Remove conditional threaded-NAPI wakeup based on task state wen.yang
2026-10-18 18:15 ` [PATCH 6.6-rt 3/5] net: Allow to use SMP threads for backlog NAPI wen.yang
2026-10-18 18:15 ` [PATCH 6.6-rt 4/5] net: Use backlog-NAPI to clean up the defer_list wen.yang
2026-10-18 18:15 ` [PATCH 6.6-rt 5/5] net: Rename rps_lock to backlog_lock wen.yang
2026-10-19 13:20 ` Clark Williams [this message]
2026-10-19 17:18 ` [PATCH 6.6-rt 0/5] net: Backport backlog-NAPI threads to resolve PREEMPT_RT softirq warning in SMP flush Wen Yang
2026-10-19 17:40 ` Clark Williams
2026-10-19 18:50 ` Clark Williams
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=atYZLK0gmG8vRHxG@demetrius \
--to=clrkwllms@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=linux-rt-devel@lists.linux.dev \
--cc=rostedt@goodmis.org \
--cc=wen.yang@linux.dev \
/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