strings: OpenBSD builders timing out running strings test

[ianlancetaylor]

2018-06-29T20:48:07-a5f8128/openbsd-amd64-62
2018-06-29T21:27:23-955cc07/openbsd-amd64-62
2018-06-29T23:01:49-3198b90/openbsd-amd64-62
2018-06-29T23:03:53-1b12a2c/openbsd-amd64-62
2018-06-30T01:04:30-0dc814c/openbsd-amd64-62

[ianlancetaylor]

Most likely cause is https://golang.org/cl/121495 which started running much longer string comparison tests on the builders.

[ianlancetaylor]

But the full test only takes 9 seconds on my laptop so it's hard to understand how it could take 180 seconds on OpenBSD.

[ianlancetaylor]

See also #26155

[ianlancetaylor]

Using gomote and running go test strings without -test.short, I see that TestCompareStrings takes 213.40 seconds to run.

[gopherbot]

Change https://golang.org/cl/121820 mentions this issue: strings: do much less redundant testing in TestCompareStrings

[ianlancetaylor]

Running the test with -test.cpuprofile gives me this from go tool pprof's top command:

Showing nodes accounting for 21s, 94.13% of 22.31s total
Dropped 72 nodes (cum <= 0.11s)
Showing top 10 nodes out of 80
      flat  flat%   sum%        cum   cum%
     7.68s 34.42% 34.42%      7.68s 34.42%  runtime.nanotime
     5.59s 25.06% 59.48%      5.59s 25.06%  runtime.thrsleep
     2.36s 10.58% 70.06%      2.36s 10.58%  runtime.osyield
     2.08s  9.32% 79.38%      2.08s  9.32%  runtime.memmove
     1.36s  6.10% 85.48%      1.36s  6.10%  runtime.thrwakeup
     0.61s  2.73% 88.21%      0.61s  2.73%  memeqbody
     0.51s  2.29% 90.50%      0.51s  2.29%  cmpbody
     0.36s  1.61% 92.11%      0.36s  1.61%  runtime.procyield
     0.32s  1.43% 93.55%      0.40s  1.79%  runtime.scanobject
     0.13s  0.58% 94.13%      0.13s  0.58%  runtime.findObject

[josharian]

linux/arm too

[ianlancetaylor]

CL 121820 has been committed, which should let this test pass reliably, so removing the release-blocker label. Leaving the issue open to investigate why the test is so much slower on OpenBSD compared to GNU/Linux. It may be only that GNU/Linux gets the current time via a VDSO and sleeps on a futex, but it would be nice to know for sure.