Repository navigation
fix(mux): pin glibc's heap in the ts_schedule bench - #6727
Conversation
Quest-Claim: 399f71e16f2cca7b
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A padded slot at the bench's 100 Mb/s lays out about 300 KB, where glibc adapts between mmap and the heap and trims the heap's top. Which mode a process settles on depends on its heap history, not the schedule: on the ARM runners Nightly's build of an unchanged schedule faulted fresh pages every slot, reading 5x slower than the previous night. The bench now holds both thresholds so every slot reuses the heap. Drop the temporary ARM diagnostic workflow and the finished quest. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 18 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
kixelated
left a comment
There was a problem hiding this comment.
Automated review by review (OpenAI)
Reviewed commit: ae16f42
No actionable bugs found. Pinning allocator policy within this benchmark is a focused way to remove heap-history sensitivity without changing production scheduling or every benchmark's baseline. Both benchmark groups apply the policy before measurement, and the libc dependency matches the Linux/glibc compile guard.
Verification: static review of the patch, benchmark and surrounding harness configuration. I did not run benchmarks or independently reproduce the reported allocation-mode slowdown. Confirmation on the scheduled paired Nightly run remains outstanding.
|
Landing: CI green, OpenAI review of ae16f42 found nothing actionable, no open threads, and (Written by Claude Opus 5.5) |
# Conflicts: # quest/m0/nightly/README.md
|
Dropped from the queue for a (Written by Claude Opus 5.5) |
Finishes
quest/m0/nightly/ts-schedule.md.What happened
Nightly's first paired run (run 40090959108) read
ts_schedule/{1/1, 1/16, 4/1}400 to 460% slower than 4381af6. The schedule did not get slower:--syncremoval (moq-dev/moq#6554), dead in the bench. A counting allocator shows a byte-identical allocation sequence at both commits.ubuntu-24.04-armrunner type, each commit's bench built by itself measures within 2% of the other (92.5 vs 94.1 µs for 1/1).rust-sharedbuild), the slowdown reproduces on today'smain: 564 µs vs 92 µs.mmapevery slot buffer (GLIBC_TUNABLES=glibc.malloc.mmap_threshold=131072) gives 660 µs on that runner for both commits, the same as the slow reading.The cause: at the bench's 100 Mb/s, a padded slot lays out about 300 KB, right where glibc switches between
mmapand the heap and trims the heap's top. The mode a process lands in depends on its heap history, not on the schedule. In the slow mode, every slot faults in fresh pages. The cases with the fewest small allocations per slot (1/1, 1/16, 4/1) are the ones that flipped.Fix
The bench calls
malloptbefore measuring to pinM_MMAP_THRESHOLD(32 MiB) andM_TRIM_THRESHOLD(max), so every slot reuses the heap. This only applies on Linux glibc (libcis a dev-dependency gated to that target). Locally, forcing themmapmode makes the old bench 755 µs and the fixed one 106 µs, about its normal cost.Choices made
bench/run.shwould protect every Criterion target, but it would also shift every trend line. That is a call for bench CI calibration.Slot::layoutas it is. Writing into a caller's buffer would avoid the allocation, but the exporter needs an owned payload per frame anyway.Checks
just rs lint-changed/test-changedfor moq-mux: pass, 10328 tests.quest check: pass.taplo: pass.just check's flake module fails building thegithub-runnerimage because the local sandbox refusesunshare. That is unrelated to this diff.I added a temporary ARM diagnostic workflow to get the runner numbers above and removed it in the final commit. The squashed diff does not include it.
Public API: none. Wire: none.
(Written by Claude Opus 5.5)
🤖 Generated with Claude Code