runtime: bump thread count slack for TestReadMetricsSched

This test is *still* flaky, but it appears to be just
mayMoreStackPreempt and the thread count *occasionally* exceeds the
original (and arbitrary) thread count slack by exactly 1.

Bump the thread count slack by one. We can investigate further and bump
it again if it continues to be a problem.

Fixes #75664.

Change-Id: I29c922bba6d2cc99a8c3bf5e04cc512d0694f7fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/708868
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>

diff --git a/src/runtime/testdata/testprog/schedmetrics.go b/src/runtime/testdata/testprog/schedmetrics.go
index 6d3f68a848e00adca338fcc0ded866b705f13e5c..bc0906330f1a4f5bd320c7e65c26db68b5af9f77 100644 (file)
--- a/src/runtime/testdata/testprog/schedmetrics.go
+++ b/src/runtime/testdata/testprog/schedmetrics.go
@@ -84,7 +84,12 @@ func SchedMetrics() {
 
        // threadsSlack is the maximum number of threads left over
        // from the runtime (sysmon, the template thread, etc.)
-       const threadsSlack = 4
+       // Certain build modes may also cause the creation of additional
+       // threads through frequent scheduling, like mayMoreStackPreempt.
+       // A slack of 5 is arbitrary but appears to be enough to cover
+       // the leftovers plus any inflation from scheduling-heavy build
+       // modes.
+       const threadsSlack = 5
 
        // Make sure GC isn't running, since GC workers interfere with
        // expected counts.