Looks to be related to the shuffle from StackInuse to StackSys in readmemstats_m. With the single runs of the runtime test, StackSys == 0 before this shuffle, so it's fine to clobber it with StackInuse and pull that amount out of HeapSys. Everything still adds up to Sys. But with the multiple runs StackSys != 0 at this point, so when we clobber it, the new sum differs from the original sum in Sys by this much.

I'm not sure why multiple runs changes this, but this shuffle smells wrong.

Ah. I think newosproc0 is the only function that manipulates memstats.stacks_sys directly. It gets called in the runtime test suite by TestNewOSProc0, which presumably runs after TestMemStats. In a single run, this means when TestMemStats runs, stacks_sys==0. But in a multi-run, the first run of TestNewOSProc0 will run before the second run of TestMemStats, so the second run of TestMemStats sees stacks_sys!=0.

The problem is just as easy to trigger with
go test -short runtime -cpu=1,1

https://go-review.googlesource.com/9366

CL https://golang.org/cl/9366 mentions this issue.