test(e2e): run tenant workers on one vCPU with CPU headroom above it - #3863
Merged
Aleksei Sviridkin (lexfrei) merged 1 commit intoAug 17, 2026
Merged
Conversation
Under a two-vCPU worker both vCPU threads burn 1.4 to 1.8 cores between them while the guest kernel never gets past SMP bringup, and raising the CFS ceiling from two cores to three changed neither the burn nor the progress, so the spin is between the two vCPUs, not against the quota. A single-vCPU guest has no sibling to spin on. The ceiling of two keeps the QEMU emulator and IO threads from eating into the one core the guest computes with, and the request keeps scheduling where the workers always were. Assisted-By: Claude <noreply@anthropic.com> Signed-off-by: Aleksei Sviridkin <3811295@gmail.com>
Aleksei Sviridkin (lexfrei)
requested review from
Andrei Kvapil (kvaps),
Timofei Larkin (lllamnyp) and
myasnikovdaniil
as code owners
August 17, 2026 00:09
Aleksei Sviridkin (lexfrei)
deleted the
test/e2e-worker-single-vcpu-with-headroom
branch
August 17, 2026 00:09
Contributor
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughTenant worker CPU settings were reduced in the Kubernetes end-to-end configuration. The CPU limit changed from 3 to 2, the request from 200m to 100m, and worker capacity from two vCPUs to one. ChangesTenant worker sizing
Estimated code review effort: 2 (Simple) | ~5 minutes Possibly related PRs
Suggested reviewers: ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
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.
What this PR does
Moves the e2e tenant workers from two vCPUs to one, keeping a CPU limit above the vCPU count:
resources.cpu: 1withpodCpuLimit: 2andpodCpuRequest: 100m.This is the next step of the #3513 measurement series. With two vCPUs the failing worker's two vCPU threads burn 1.4 to 1.8 cores between them while the guest kernel never gets past SMP bringup, and raising the CFS ceiling from 2 to 3 cores (#3862) changed neither the burn nor the progress, so the spin is between the two vCPUs rather than against the quota. A single-vCPU guest has no sibling vCPU to spin on, which is exactly what this shape tests. The ceiling of 2 keeps the QEMU emulator and IO threads from eating into the one core the guest computes with, which was the failure shape of the original single-vCPU workers whose quota equalled their vCPU count. The request of 100m is what KubeVirt derived for a one-vCPU worker before, so scheduling does not move.
Like its predecessors this changes only what the e2e suites run, not what any chart ships by default.
Screenshots
Not applicable, no UI change.
Downstream repositories
The diff is one values block inside
hack/e2e-chainsaw/_lib/run-kubernetes.sh. Nothing in the trigger map is touched.Release note
Summary by CodeRabbit