Re: [PATCH v3 0/4] memcg: Misc cleanup and perf improvement for TCP.

[Andrew Morton <akpm@linux-foundation.org>]

On Thu, 29 Oct 2026 19:44:11 +0000 Kuniyuki Iwashima <kuniyu@google.com> wrote:

> On host w/ AMD EPYC 9B45 128-Core Processor (Zen 5 Turin,
> 2 sockets, 512 vCPUs), tcp_rr w/ 20000 flows throughput often
> degrades by ~50%, 32M -> 17M~27M.
> 
> In the bad case, the number of involuntary context switches
> was extremely high by 12x (241733 -> 3093367).
> 
> The root cause was that refill_stock() calls memcg_uncharge()
> or drain_stock() while holding memcg_stock.lock.
> 
> Patch 1~3 are misc cleanup for better asm output and patch 4
> moves heavy operations to out of local_lock(&memcg_stock.lock).
> 
> This series removes the flakiness and gives ~3% gain on the
> 512 vCPU platform.
> 
> In addition, on machine w/ AMD EPYC 7B12 64-Core Processor
> (Zen 2 Rome, 2 sockets, 256 vCPU), tcp_rr w/ 10000 flows achieves
> 36% more throughput with lower latency.
> 
>   tcp_rr (10000 flows, 128 threads, 60s, average of 3 runs):
> 
>   Metric                     |       Baseline |    Patched |    Diff
>   ---------------------------+----------------+------------+--------
>   Throughput (RPS)           |     20,884,499 | 28,453,051 | +36.24%
>   Latency Mean (us)          |         478.46 |     351.07 | -26.63%
>   Latency p50 (us)           |         453.96 |     343.04 | -24.43%
>   Latency p90 (us)           |         669.00 |     479.57 | -28.32%
>   Latency p99 (us)           |         969.38 |     593.92 | -38.73%

Thanks, that all checks out here.  I fed the series into my
LLM-controlled live kernel testing setup.  tl;dr: no correctness issues
but the performance gains on this setup are much more humble.

Gory details for the morbidly interested:


: I tested all four patches before/after on Linux 7.4.0-rc1.
: 
: Correctness testing used a four-vCPU, 8 GiB Debian QEMU/KVM guest
: with KASAN and lockdep. Both kernels passed all 22 memcg/kmem
: selftests, cgroup/socket churn, guest CPU hotplug, socket lifetime
: across migration/cgroup removal, and payload-checked TCP transfers
: under memory pressure. Final socket charges and dying descendants
: reached zero, with no unexpected kernel diagnostics. Traces confirmed
: stock trimming, eviction and fallback coverage.
: 
: Performance testing used 56 guest vCPUs pinned individually to 56
: physical cores of a 64-core Threadripper 3995WX, with 32 GiB and
: KASAN/lockdep disabled. Host and guest each had one socket/NUMA node;
: the guest exposed one thread per core. Neper used 10,000 flows and
: one-byte requests/responses. All 24 runs completed: three 60-second
: runs per kernel/condition, with alternating A/B boot blocks.
: 
: Median throughput changes for the full series:
: 
:     Workers per endpoint     RPS off     RPS on
:                       28      +1.21%     +1.38%
:                      128      +0.14%     +0.72%
: 
: The smaller machine likely explains much of the difference from your
: 36% gain. Your reported systems have two sockets and 256/512 vCPUs.
: Here each endpoint had just 28 vCPUs backed by 28 physical cores;
: 128 workers oversubscribed those CPUs rather than adding parallelism.
: There was no physical inter-socket traffic. These differences can
: reduce shared-counter contention and the lock-held interval behind
: the RPS/charge-fallback/ksoftirqd amplification you described. I
: exercised stock and RPS paths, but did not reproduce your collapse
: or establish comparable amplification. This explanation is plausible,
: not demonstrated by the measurements.
: 
: Three conditions consistently favored B; 128 workers/RPS-off was
: essentially tied. Frequency was uncontrolled, limiting sub-percent
: claims. Both kernels had VM CPU-feature/watchdog diagnostics without
: an unstable-clock message, and softnet drops with RPS off.