From 73b8afc25633d97b3e8216e9b539b302970b9484 Mon Sep 17 00:00:00 2001 From: Aleksei Sviridkin <3811295@gmail.com> Date: Mon, 17 Aug 2026 03:09:04 +0300 Subject: [PATCH] test(e2e): run tenant workers on one vCPU with CPU headroom above it 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 Signed-off-by: Aleksei Sviridkin <3811295@gmail.com> --- hack/e2e-chainsaw/_lib/run-kubernetes.sh | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/hack/e2e-chainsaw/_lib/run-kubernetes.sh b/hack/e2e-chainsaw/_lib/run-kubernetes.sh index bfeec8aed..b47dc3490 100644 --- a/hack/e2e-chainsaw/_lib/run-kubernetes.sh +++ b/hack/e2e-chainsaw/_lib/run-kubernetes.sh @@ -3167,24 +3167,24 @@ ${ouroboros_addon} # ceiling. Workers failing to join (cozystack/cozystack#3513) have been # measured burning their vCPU threads flat out at a ceiling equal to their # vCPU count while the guest kernel made no progress, which is what a vCPU - # spinning on a lock looks like when the vCPU holding that lock is the one - # preempted out of the quota they share. Whether the spare CPU lets the - # preempted one back in is what this is here to answer. The request is + # spinning on a lock looks like. Spare quota above the pair did not change + # it: under a ceiling of 3 the pair kept burning the same 1.4 to 1.8 cores + # with no progress, so the spin is not a quota artefact. A single vCPU + # cannot spin on its sibling, which is what this shape is here to answer, + # and the ceiling above the vCPU count keeps the emulator and IO threads + # from eating into the one core the guest computes with. The request is # what keeps scheduling where it was: setDefaultResourceRequests, in # KubeVirt's VMI mutating webhook, copies a declared CPU limit into an # undeclared CPU request, so the limit alone would have every worker ask # the scheduler for its whole ceiling and sit Pending on Insufficient cpu. # Its value is the one KubeVirt derived for these workers before, from the # vCPU count and the cluster CPU allocation ratio. - podCpuLimit: 3 - podCpuRequest: 200m - # Two vCPUs at the memory the workers had before. Sized by resources - # rather than by instanceType: u1.large doubles memory along with the - # vCPUs, and four 8Gi workers do not fit beside the rest of the suite, - # so the second worker of each cluster stayed Pending on Insufficient - # memory and the node group never reached two Ready nodes. + podCpuLimit: 2 + podCpuRequest: 100m + # One vCPU at the memory the workers had before. Sized by resources + # rather than by instanceType, which cannot carry the pod CPU pair above. resources: - cpu: 2 + cpu: 1 memory: 4Gi roles: - ingress-nginx