Repository navigation
Conversation
ab9 on the AMD bench: pipe.throughput's per-round writer thread follows spawn placement's rotation over the whole machine, and every round that lands it in the other LLC from its reader reads slow, in both arms and without exception. One unexplained same-LLC slow round is recorded as an open observation. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Nov 3, 2026
Collaborator
Author
|
Closed unmerged: the defect it records (a spawned thread starts in any LLC, not its spawner's) is fixed by #1153, which passed its pre-set A/B (ab11: pipe rounds stay in one LLC, storm waiters on their own CPUs, thread.spawn_join −22%). The record lives in #1153's commits, body and evidence (https://github.com/ToyOSOrg/evidence/blob/931d1ab5b58f2809988d192065158fa1a741035c/pr-1153/r3/judgment.md); landing it only for #1153 to delete it would be churn. |
Japabu
added a commit
that referenced
this pull request
Nov 4, 2026
Spawn placement ranked CPUs by queue, sleep, busy SMT siblings and wake depth, and broke ties by a rotation over the whole machine, so a thread spawned to work with its spawner started in either LLC. On the AMD bench ab9 measured what that costs a thread streaming to its spawner: every pipe.throughput round whose writer thread the rotation put in the other LLC read about 0.42x at 16384 bytes per write and 0.48x at 65536, in both arms and without exception (issues/a-spawned-thread-starts-in-any-llc-not-its-spawners.md, #1151). `CpuHandles::place` takes the spawner's CPU as `near` and, after the queue, the sleep and the free core, prefers a CPU in its LLC; a free core elsewhere still beats a shared core near, so a burst of threads spreads over every free core before it doubles up. A thread spawned into its own process passes its CPU; a new process's first thread, a kernel thread and a relocation pass none and place as before. The simulator's `Op::Spawn` passes the spawning step's CPU, as the kernel does. Tests: `a_spawned_thread_starts_on_a_free_core_in_its_spawners_llc` (host) and `a_spawned_partner_starts_in_its_spawners_llc` (simulator, AMD shape, 40 seeds: no kick crosses the LLCs but the spawner's own move). Without the LLC term both red; with the simulator passing no spawner, the simulator test reds with 11 crossing kicks. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Files
issues/a-spawned-thread-starts-in-any-llc-not-its-spawners.md, a defect in spawn placement found by #1129's ab9.Problem
CpuHandles::placebreaks ties by a rotation over the whole machine and never weighs the spawner's LLC. On the AMD bench,pipe.throughput's per-round writer thread followed that rotation (14, 15, 0, … 5 at 16384) in all six ab9 boots of both arms. Every round that put it in the other LLC from its reader read slow, without exception: about 2.0, 3.5 and 4.8 GB/s at 4096, 16384 and 65536, against about 5.0, 8.4 and 10.0 in one LLC. One same-LLC base round read 5.6 GB/s with nothing in its record to explain it; the issue records it as an open observation.Evidence: ab9 judgment, per-boot rows.
Resulting behaviour
None: issues only. The fix (a spawned thread prefers a free core in its spawner's LLC) follows as its own PR, which the issue is assigned to.
Checks
None run: the change is one Markdown file. No gate checks issue frontmatter; review does (
issues/README.md).🤖 Generated with Claude Code