Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: enable scheduler randomization independent of the race detector #43794

Open
josharian opened this issue Jan 20, 2021 · 4 comments
Open

runtime: enable scheduler randomization independent of the race detector #43794

josharian opened this issue Jan 20, 2021 · 4 comments

Comments

@josharian
Copy link
Contributor

@josharian josharian commented Jan 20, 2021

-race does scheduler randomization. This has proved to be a useful way to flush out logical races, bad lock orderings, etc.

However, running with the race detector enabled (a) is slow and (b) is only supported on a subset of platforms.

I propose that we make it possible to run with scheduler randomization enabled, independent of whether the race detector is enabled.

I believe that this could be done entirely at run time, perhaps via a GODEBUG flag.

cc @dvyukov @bradfitz @aclements @mknyszek

@mvdan
Copy link
Member

@mvdan mvdan commented Jan 20, 2021

Out of curiosity, is this something that could simply be turned on at all times, similar to how ranging over a map is always pseudo-random with the Go toolchain? Assuming that the cost is negligible, it could be a net win.

@prattmic
Copy link
Member

@prattmic prattmic commented Jan 20, 2021

This seems like something that could be made into a GODEBUG option without issue. I doubt the few branches it would add will be noticeable.

I'm not sure what the cost is, but if low enough I think enabling all the time could be interesting as well.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jan 20, 2021

I took a look at randomizeScheduler. I think the only noticeable cost would be an additional loop in runqputslow, which is called to move half of a local run queue to the global queue. That additional loop will be over the goroutines being moved to the global queue. Currently I think it can be up to 128 entries. Since runqputslow is only called when the local run queue is full, this isn't going to be particularly common. There would also be a bunch more calls to fastrand.

So while of course someone would have to benchmark this, it seems plausible that the cost would be fairly low.

@dvyukov
Copy link
Member

@dvyukov dvyukov commented Jan 21, 2021

@ianlancetaylor note that there maybe a significant cost related to loss of scheduling locality in runqput.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants