1
0
mirror of https://github.com/golang/go synced 2024-11-17 21:54:49 -07:00

runtime: expand acceptable PingPongHog factor from 2 to 5

Since TestPingPongHog tests the scheduler, it's ultimately
probabilistic. Currently, it requires the result be at most of factor
of 2 off of the ideal. It turns out this isn't quite enough in
practice, with factors on 1000 iterations on linux/amd64 ranging from
0.48 to 2.5. If the test were failing, we would expect a factor closer
to 1000X, so it's pretty safe to expand the accepted factor from 2 to
5.

Fixes #20494.

Change-Id: If8f2e96194fe66f1fb981a965d1167fe74ff38d7
Reviewed-on: https://go-review.googlesource.com/44859
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This commit is contained in:
Austin Clements 2017-06-05 10:59:57 -04:00
parent b225051f1d
commit d263e85597

View File

@ -428,10 +428,13 @@ func TestPingPongHog(t *testing.T) {
<-lightChan
// Check that hogCount and lightCount are within a factor of
// 2, which indicates that both pairs of goroutines handed off
// the P within a time-slice to their buddy.
if hogCount > lightCount*2 || lightCount > hogCount*2 {
t.Fatalf("want hogCount/lightCount in [0.5, 2]; got %d/%d = %g", hogCount, lightCount, float64(hogCount)/float64(lightCount))
// 5, 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
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))
}
}