aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/drivers/net/dsa/mt7530.h
diff options
context:
space:
mode:
authorJakub Kicinski <kuba@kernel.org>2024-03-20 21:05:44 -0700
committerJakub Kicinski <kuba@kernel.org>2024-03-20 21:05:45 -0700
commit3201de46a2013293abe28caa46aa0387864d7cf7 (patch)
treebb54c5de6214b985d103ec0d400e6b8d9527e10f /drivers/net/dsa/mt7530.h
parentionic: update documentation for XDP support (diff)
parentbpf: report RCU QS in cpumap kthread (diff)
downloadwireguard-linux-3201de46a2013293abe28caa46aa0387864d7cf7.tar.xz
wireguard-linux-3201de46a2013293abe28caa46aa0387864d7cf7.zip
Merge branch 'report-rcu-qs-for-busy-network-kthreads'
Yan Zhai says: ==================== Report RCU QS for busy network kthreads This changeset fixes a common problem for busy networking kthreads. These threads, e.g. NAPI threads, typically will do: * polling a batch of packets * if there are more work, call cond_resched() to allow scheduling * continue to poll more packets when rx queue is not empty We observed this being a problem in production, since it can block RCU tasks from making progress under heavy load. Investigation indicates that just calling cond_resched() is insufficient for RCU tasks to reach quiescent states. This also has the side effect of frequently clearing the TIF_NEED_RESCHED flag on voluntary preempt kernels. As a result, schedule() will not be called in these circumstances, despite schedule() in fact provides required quiescent states. This at least affects NAPI threads, napi_busy_loop, and also cpumap kthread. By reporting RCU QSes in these kthreads periodically before cond_resched, the blocked RCU waiters can correctly progress. Instead of just reporting QS for RCU tasks, these code share the same concern as noted in the commit d28139c4e967 ("rcu: Apply RCU-bh QSes to RCU-sched and RCU-preempt when safe"). So report a consolidated QS for safety. It is worth noting that, although this problem is reproducible in napi_busy_loop, it only shows up when setting the polling interval to as high as 2ms, which is far larger than recommended 50us-100us in the documentation. So napi_busy_loop is left untouched. Lastly, this does not affect RT kernels, which does not enter the scheduler through cond_resched(). Without the mentioned side effect, schedule() will be called time by time, and clear the RCU task holdouts. V4: https://lore.kernel.org/bpf/cover.1710525524.git.yan@cloudflare.com/ V3: https://lore.kernel.org/lkml/20240314145459.7b3aedf1@kernel.org/t/ V2: https://lore.kernel.org/bpf/ZeFPz4D121TgvCje@debian.debian/ V1: https://lore.kernel.org/lkml/Zd4DXTyCf17lcTfq@debian.debian/#t ==================== Link: https://lore.kernel.org/r/cover.1710877680.git.yan@cloudflare.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to '')
0 files changed, 0 insertions, 0 deletions