gh-159860: Pad QSBR thread states to 128 bytes on AArch64 - #159862

Adds _Py_QSBR_CACHE_LINE_SIZE (128 on __aarch64__ / _M_ARM64, 64 elsewhere) and uses it in the three places that hard-code 64:

The change is internal only (Py_BUILD_CORE): no ABI change, and other architectures are unchanged.

What goes wrong today

1. check_periodics() / check_periodics_at_end() run on every JUMP_BACKWARD, after every CALL, and in RESUME. Each time they call _Py_qsbr_quiescent_state(), which does an unconditional _Py_atomic_store_uint64_release(&qsbr->seq, ...).
2. sizeof(struct _qsbr_thread_state) is already 64 (checked with lldb), so _qsbr_pad adds 0 bytes of padding. On 128-byte lines, slots 2k and 2k+1 share a line.
3. Threads created one after another get neighbouring slots. initialize_new_array() pushes the free slots onto a LIFO freelist in index order, and _Py_qsbr_reserve() pops from it. Pool workers therefore end up pairwise on shared lines.

To check that the slot layout is the cause: an idle (detached) thread started after each worker keeps busy threads off neighbouring slots. On unpatched main that alone raises 14-thread scaling from ~6× to 7.9–8.6×.

Why gh-144438 didn't cover it

gh-144438 was found on x86, with 64-byte lines. The problem there was the first array entry sharing a line with some thread's tlbc_index (diagnosis). Its fix uses 64 for both the array alignment and the new tail padding. On x86 a 64-byte _qsbr_pad already gives each thread its own line, so the padding between entries never needed changing. On 128-byte lines it does, and the gh-144438 padding is only half a line. The layout is unchanged since 3.13 (3.13.16), so on a Mac the penalty is the same in every version. This fits why the gh-144438 regression was "not seen on Mac" (comment).

Results

M4 Pro (10P + 4E), macOS 26.7.1, Apple clang 17, ./configure --disable-gil, base main d42178a.

Memory cost (AArch64 only)

Measured on a main build with lldb (sizeof, and mimalloc's mi_good_size(), which PyMem_RawCalloc uses in the free-threaded build):

That is about 64 B per QSBR slot. For comparison, CPython reserves a 16 MiB stack per thread on macOS.

Design notes

• Why 128, and not the compiler's __GCC_DESTRUCTIVE_SIZE:
  • That macro varies by compiler: 64 with Apple clang 17, 128 for Apple targets in upstream clang (llvm/llvm-project#208716), and 256 for generic AArch64 in clang (AArch64.h) and GCC (aarch64.cc).
  • It is documented as ABI-unstable, and MSVC doesn't define it.
  • 256 measures the same as 128 (table above).
  • Go, Rust std, OpenJDK, folly and Blender use 128 (links in the issue).
• Why all of AArch64 and not only __APPLE__: on AArch64 cores with 64-byte lines, this only costs the memory above, and it also covers Windows on ARM. Easy to narrow if preferred.
• x86_64 is not changed: Scaling regression in Tools/ftscalingbench/ftscalingbench.py generator #144438 showed 64 is enough there. (Rust std and folly use 128 on x86_64 because of Intel's adjacent-line prefetcher; I couldn't measure x86.)
• Alternative tried: skip the store when seq is unchanged. It is safe, because only the owner writes seq while attached. It also removes the contention, but it adds a load and a branch to the hottest path: about +50% per call in the C test, and up to ~3% on the 1-thread loop. With the padding it brings nothing extra (10.2–10.3× vs. 10.1–10.3×), so I left it out.

Tests

./python.exe -m test -j12 test_free_threading test_threading test_thread test_queue test_weakref test_gc test_sys test_capi test_concurrent_futures test_threading_local test_itertools test_generators: SUCCESS (79 files, 3256 tests).

• Issue: Free-threading: QSBR thread states false-share on 128-byte cache lines (Apple Silicon), CPU-bound threads reach ~6× on 14 cores where processes reach ~10× #159860

🤖 Generated with Claude Code