From c087121dafc1e0250d43b545e85d67e7e6762f74 Mon Sep 17 00:00:00 2001 From: Cherry Mui Date: Wed, 18 May 2022 15:15:33 -0400 Subject: [PATCH] runtime: relax the threshold for TestPingPongHog The test checks that the scheduling of the goroutines are within a small factor, to ensure the scheduler handing off the P correctly. There have been flaky failures on the builder (probably due to OS scheduling delays). Increase the threshold to make it less flaky. The gap would be much bigger if the scheduler doesn't work correctly. For the long term maybe it is better to test it more directly with the scheduler, e.g. with scheduler instrumentation. May fix #52207. Change-Id: I50278b70ab21b7f04761fdc8b38dd13304c67879 Reviewed-on: https://go-review.googlesource.com/c/go/+/407134 TryBot-Result: Gopher Robot Reviewed-by: Bryan Mills Run-TryBot: Cherry Mui Reviewed-by: Ian Lance Taylor Reviewed-by: Michael Knyszek --- src/runtime/proc_test.go | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/runtime/proc_test.go b/src/runtime/proc_test.go index c49d6ae8a8f..418e448d2fe 100644 --- a/src/runtime/proc_test.go +++ b/src/runtime/proc_test.go @@ -477,11 +477,12 @@ func TestPingPongHog(t *testing.T) { <-lightChan // Check that hogCount and lightCount are within a factor of - // 5, which indicates that both pairs of goroutines handed off + // 20, which indicates that both pairs of goroutines handed off // the P within a time-slice to their buddy. We can use a // fairly large factor here to make this robust: if the - // scheduler isn't working right, the gap should be ~1000X. - const factor = 5 + // scheduler isn't working right, the gap should be ~1000X + // (was 5, increased to 20, see issue 52207). + const factor = 20 if hogCount > lightCount*factor || lightCount > hogCount*factor { t.Fatalf("want hogCount/lightCount in [%v, %v]; got %d/%d = %g", 1.0/factor, factor, hogCount, lightCount, float64(hogCount)/float64(lightCount)) }