CI runs once, and no workflow cancels a commit on main - #3
Merged
Conversation
Two changes, matching what storage now does and what three of the four workflows here already did. **ci.yml fired twice per push.** An unfiltered `push:` fires alongside `pull_request:` for every push to a branch with one open, so every push started two identical runs and the concurrency group killed one — after both had taken a runner. image.yml, kernel.yml and qemu.yml have always filtered `push:` to main; this was the exception. **Nothing cancels a run on main any more.** cancel-in-progress applied there too, so two merges landing close together left the first with no verdict. Two merges are two things to verify. What is given up: a branch with no pull request open is not tested. That is what opening one is for. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_019GHRRFvbnZi5q3KSTvyW5a
aledbf
added a commit
that referenced
this pull request
Sep 10, 2026
…ves it
The research's ranked candidate for a kernel rebuild was CONFIG_XFRM=n, on the
grounds that xfrm_init runs inside ip_rt_init and register_xfrm_state_bpf does
BTF work Docker does not need. The measurements agree right up to the last step
and then invert the conclusion.
function_graph at depth 1, silent console, dmesg read back from the guest:
inet_init 9252 us
└─ ip_rt_init 9444 us (97% of it)
└─ xfrm_init 8971 / 8638 / 9135 us over three boots
└─ register_xfrm_state_bpf 9045 / 9306 us - essentially all of it
Which reads as a 9 ms saving sitting behind one config symbol. It is not. Filter
on register_btf_kfunc_id_set instead and the boot makes 51 calls to it:
#1 9301.9 us #2 0.75 us #3 1.52 us ... #51
The first call pays the one-time parse of the 4.35 MB .BTF section and every
other call is microseconds. XFRM is not expensive; it is merely first in the
queue. CONFIG_XFRM=n would hand the same 9 ms to whichever kfunc set registers
next, and the only symbol that removes it is CONFIG_DEBUG_INFO_BTF=n - which is
the one thing here that is not up for discussion.
Recorded at the BTF assertion in kernel/Dockerfile, where the decision to keep
BTF now carries its price.
That is the third time in this session a per-function number turned out to
belong to something else: acpi_purge_cached_objects at 26x under a wide filter,
ksm_init and kcompactd_init at 3 ms of vCPU descheduling each, and now this.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_019GHRRFvbnZi5q3KSTvyW5a
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
1 participant
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.
The same change storage just took, and what three of the four workflows here already did.
ci.ymlfired twice per push. An unfilteredpush:fires alongsidepull_request:for every push to a branch with one open, so every push started two identical runs and the concurrency group killed one — after both had already taken a runner.image.yml,kernel.ymlandqemu.ymlhave always filteredpush:to main;ci.ymlwas the exception.Nothing cancels a run on main any more.
cancel-in-progressapplied there too, so two merges landing close together left the first with no verdict at all. Two merges are two things to verify, not one.What is given up: a branch with no pull request open is not tested. That is what opening one is for.
🤖 Generated with Claude Code
https://claude.ai/code/session_019GHRRFvbnZi5q3KSTvyW5a