mirror of
https://github.com/golang/go.git
synced 2025-12-28 06:34:04 +00:00
runtime: relax threadsSlack in TestReadMetricsSched
runtime.GC is called in the test and may spin up GOMAXPROCS (proportional to the initial count) new threads. We need to be robust to this, and it happens relatively frequently on some platforms. We didn't notice this earlier since the heap is so miniscule that runtime.GC essentially finished instantly without all the threads getting spun up. Fixes #76613. Change-Id: I2af02cb090d5c1c952e4db53ad35895b6f23f638 Reviewed-on: https://go-review.googlesource.com/c/go/+/726642 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
This commit is contained in:
parent
8947f092a8
commit
fe4952f116
@ -91,8 +91,10 @@ func SchedMetrics() {
|
||||
// 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
|
||||
// modes. We then also add initialGMP to this slack, since we're
|
||||
// about to call runtime.GC, and in the worst case this will
|
||||
// spin up GOMAXPROCS new threads to run those workers.
|
||||
threadsSlack := 5 + uint64(initialGMP)
|
||||
|
||||
// Make sure GC isn't running, since GC workers interfere with
|
||||
// expected counts.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user