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 <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

diff --git a/src/runtime/proc_test.go b/src/runtime/proc_test.go
index c49d6ae8a8fc8ffadcd8eb5b65ca5ff6fda77a58..418e448d2fec02f6b51921c34917cc57da613ec7 100644 (file)
--- 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))
        }