[kixelated]

Profiles relay lock contention under video-heavy before and after the epoch-based kio::log (moq-dev/moq#6782) for log-lock-profile.

These numbers aren't trustworthy. desktop was busy with other agents for the whole run: across 128 samples taken 20 s apart over 43 minutes, the 1-minute load ranged from 5.4 to 30.2 (median 11.8). bench/README.md asks for load near zero. The quest stays open, and this PR only records the attempt and the maintainer's decision in its Plan. It lands as a checkpoint so the quest's claim frees up for the quiet rerun.

Measurements

Command: quest gate nix develop --command just bench-profile lock video-heavy "1 4 16" tokio-workers <base>, run from origin/main 1c733a0 with two bases:

• d854bf98b1~1, the commit before perf(kio,net): lock-free append-only log for group frames #6782, as the quest's Plan asks.
• d854bf98b1, the commit that merged perf(kio,net): lock-free append-only log for group frames #6782. The Plan's single run compares pre-perf(kio,net): lock-free append-only log for group frames #6782 against today's main, which also includes later group changes (moq-dev/moq#7141, moq-dev/moq#7139, moq-dev/moq#7056, …). Profiling this second base shows perf(kio,net): lock-free append-only log for group frames #6782's effect on its own.

The harness's own tables, plus mutex wait split by the locked kio::State<T> (summed from mutex.folded):

revision	workers	control fps	profiled fps	mutex wait	TrackState	GroupState	Route / other
pre-#6782 (7237beb17a)	1	28315	22039	0.0 ms	–	–	–
pre-#6782	4	31745	31649	79.4 ms	74.7 (94%)	0.8 (1%)	3.9 (5%)
pre-#6782	16	–	–	failed: perf dropped events (PERF_RECORD_LOST lost 1)
#6782 (d854bf98b1)	1	29948	31080	0.0 ms	–	–	–
#6782	4	30698	31450	35.5 ms	35.5 (100%)	0 (0%)	0
#6782	16	32111	31906	4.4 ms	4.4 (100%)	0 (0%)	0
main (1c733a08d0)	1	10985	16976	2.5 ms	–	0	2.5 (cache::WallDeadlines)
main	4	32531	31410	121.6 ms	100.1 (82%)	10.4 (9%)	11.2 (9%, Route)
main	16	–	–	failed: worker moq-quic-10 has nonalternating switch records

Read with the noise in mind:

• Taken at face value, perf(kio,net): lock-free append-only log for group frames #6782 shows no regression. At 4 workers, GroupState waits fell from 0.8 ms (1%) to none, and total mutex wait fell from 79 to 35 ms. At 16 workers, perf(kio,net): lock-free append-only log for group frames #6782 has no GroupState waits, but the pre-perf(kio,net): lock-free append-only log for group frames #6782 capture failed, so that worker count has no comparison. At 1 worker, there are no mutex waits on either side. This agrees with perf(kio,net): lock-free append-only log for group frames #6782's criterion direction.
• The noise is about as large as the effect. On main, the unprofiled 1-worker run reached only 11k fps, against 28–30k for the other revisions. Total wait at 4 workers varies 3× between revisions, almost all of it in TrackState, which perf(kio,net): lock-free append-only log for group frames #6782 didn't change.
• main shows GroupState waits again: 10.4 ms at 4 workers, under group::Consumer::poll_read_frame_once → Prefetch::pop_cached (the frame read path changed after perf(kio,net): lock-free append-only log for group frames #6782). This could be noise, or it could be a later change. Rerunning on a quiet host would tell which.
• At 16 workers, both failures came from the perf capture: an event lost in one run and out-of-order switch records in the other. Both are likely load-induced, and the harness rightly refused them.

The raw evidence (perf.data, mutex.folded, lock.json) stayed on desktop in this worktree's .tmp/bench/run.gwlrzz (pre-#6782 base) and .tmp/bench/run.NniwH7 (#6782 base and main). It gets deleted along with the worktree.

Changes

• quest/m1/unbounded-groups/log-lock-profile.md: the Plan now records this attempt, suggests profiling d854bf98b1 as a second base, and records the 2026-10-30 decision to rerun both bases on a quiet host, with the GroupState follow-up to check then.

Decisions

1. ✅ Keep the quest; rerun on a quiet host (maintainer, 2026-10-30). These numbers do not finish it.
2. Deferred to the rerun, as recommended: whether the GroupState waits on main (poll_read_frame_once / Prefetch::pop_cached) need their own quest. The quest's Plan now says to suggest that follow-up if they persist on a quiet host.

Choices made without asking

• Profiled d854bf98b1 as a second base in addition to the Plan's d854bf98b1~1, so perf(kio,net): lock-free append-only log for group frames #6782's effect is isolated from later changes.
• Ran at the measured load instead of waiting for the host to go quiet, as the afk brief asked, and labelled the results untrustworthy.
• Landing this as a quest checkpoint rather than leaving the draft open: the quest's Plan carries the remaining work, and an open draft would hold the quest's claim until the host is quiet.

Suggested follow-ups

• Under load, the 16-worker lock capture fails on perf losing events or recording nonalternating switches. A larger perf ring buffer (-m) could make the capture more robust. This is only worth doing if the failures persist on a quiet host.

Checks

• quest check --base origin/main: ok (670 documents) on 37ddd15cb0.
• just check origin/main: passed on ef2a2718c3; 37ddd15cb0 only edits quest prose.

Review

Local review skipped as trivial: the diff adds only two Plan bullets recording the attempt and the maintainer's decision, with no code change. Head: 37ddd15.

(Written by Claude Opus 5.5)

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

You'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 11 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used all 4 included reviews currently available.

Learn how review limits work.

Review configuration:

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: a1c45875-2ed3-4f6e-a78e-f311c1fb44a0

Commits

Reviewing files that changed from the base of the PR and between 7c8e255 and 37ddd15.

Files selected for processing: 1

• quest/m1/unbounded-groups/log-lock-profile.md

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-30T20:15:19.277486Z	37ddd15	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[kixelated]

Automated review by review (OpenAI)

Reviewed commit: 37ddd15

No actionable bugs found in the quest Plan update. Keeping the quest open and requiring quiet-host comparisons against both bases is the right direction: it avoids treating the noisy measurements as completion or attributing later changes to #6782. The two added bullets are appropriately scoped; no extra implementation complexity is introduced.

Verification: inspected the complete diff, surrounding quest, benchmark guidance, and existing review activity. This is a documentation-only review; I did not run tests or benchmarks or independently validate the recorded measurements.