Bug report
Bug description
On Windows, python -m profiling.sampling run --blocking ... reports a sample-read
error rate of roughly 31–35% when the host CPU is an AMD EPYC 9V45, while the
same command on other CPUs reports about 0.5%. The high rate matches what we see
without --blocking on other machines (about 36–39%), so it looks as if the
blocking (suspend-then-read) path is not effective on that CPU.
Command (wall mode, 1 kHz, 40 s duration cap; the target finishes on its own):
python -m profiling.sampling run --native --opcodes --mode wall --sampling-rate 1khz \
--binary --compression none --output out.bin --blocking --duration 40 target.py
target.py is a CPU-bound, single-threaded workload (many short Python calls)
that runs for about 4 s on the slower CPUs and about 2 s on the EPYC 9V45.
Observed on GitHub-hosted Windows runners (image windows-2025-vs2026,
version 20260922.246.2), same commit, same command, six consecutive runs:
| Runner CPU |
Error rate (3 attempts each where failing) |
Capture length |
| AMD EPYC 9V45 96-Core |
33.20 / 31.48 / 35.29 % |
~2.1 s |
| AMD EPYC 9V45 96-Core |
33.78 / 34.93 / 34.05 % |
~2.1 s |
| AMD EPYC 9V74 80-Core |
0.46 % |
~4.1 s |
| AMD EPYC 7763 64-Core |
0.50 % |
~4.1 s |
| AMD EPYC 7763 64-Core |
0.46 % |
~4.1 s |
| Intel Xeon 6973P-C |
0.71 % |
~4.1 s |
Two other targets profiled in the same jobs without --blocking (but with
--all-threads) stay at about 2 % on every CPU, including the EPYC 9V45.
Locally (AMD Ryzen 5 5600X, Windows 11), 10 runs each of the same target:
--blocking 0.36–0.51 %; without --blocking 36.38–38.79 %. Without blocking,
the dominant read error was Failed to parse initial frame in chain.
We do not have access to an EPYC 9V45 machine to bisect further, and we have not
yet reduced this to a standalone script; happy to run diagnostics on GitHub
runners if that helps.
CPython versions tested on:
3.15 (3.15.0rc1)
Operating systems tested on:
Windows
Bug report
Bug description
On Windows,
python -m profiling.sampling run --blocking ...reports a sample-readerror rate of roughly 31–35% when the host CPU is an AMD EPYC 9V45, while the
same command on other CPUs reports about 0.5%. The high rate matches what we see
without
--blockingon other machines (about 36–39%), so it looks as if theblocking (suspend-then-read) path is not effective on that CPU.
Command (wall mode, 1 kHz, 40 s duration cap; the target finishes on its own):
target.pyis a CPU-bound, single-threaded workload (many short Python calls)that runs for about 4 s on the slower CPUs and about 2 s on the EPYC 9V45.
Observed on GitHub-hosted Windows runners (image
windows-2025-vs2026,version
20260922.246.2), same commit, same command, six consecutive runs:Two other targets profiled in the same jobs without
--blocking(but with--all-threads) stay at about 2 % on every CPU, including the EPYC 9V45.Locally (AMD Ryzen 5 5600X, Windows 11), 10 runs each of the same target:
--blocking0.36–0.51 %; without--blocking36.38–38.79 %. Without blocking,the dominant read error was
Failed to parse initial frame in chain.We do not have access to an EPYC 9V45 machine to bisect further, and we have not
yet reduced this to a standalone script; happy to run diagnostics on GitHub
runners if that helps.
CPython versions tested on:
3.15 (3.15.0rc1)
Operating systems tested on:
Windows