e2e: fixed flaky test_id:32646 CPU load balancing on cgroupv1#1457
e2e: fixed flaky test_id:32646 CPU load balancing on cgroupv1#1457SargunNarula wants to merge 1 commit intoopenshift:mainfrom
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: SargunNarula The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
SargunNarula
force-pushed
the
load_balancing_annotation
branch
2 times, most recently
from
ed4738d to
16b91bb
Compare
|
/verified by @SargunNarula |
openshift-ci-robot
added
the
verified
|
@SargunNarula: This PR has been marked as verified by DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
test/e2e/performanceprofile/functests/1_performance/cpu_management.go
Outdated
Show resolved
Hide resolved
The test was flaky because it checked /proc/schedstat immediately after pod startup, before kubelet had time to reconcile system pod cpusets. This race window caused intermittent failures where load balancing appeared still enabled on the Guaranteed pod's CPUs. On cgroupv1 systems, disabling CPU load balancing requires ALL cgroups that intersect with a CPU to have sched_load_balance=0. Signed-off-by: Sargun Narula <snarula@redhat.com>
SargunNarula
force-pushed
the
load_balancing_annotation
branch
from
16b91bb to
bd2c0e0
Compare
|
/retest |
|
@SargunNarula: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
4 participants
The test was flaky because it checked /proc/schedstat immediately after pod startup, before kubelet had time to reconcile system pod cpusets. This race window caused intermittent failures where load balancing appeared still enabled on the Guaranteed pod's CPUs.
On cgroupv1 systems, disabling CPU load balancing requires ALL cgroups that intersect with a CPU to have sched_load_balance=0.