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
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FeatureRequest NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@josharian
Copy link
Contributor

-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 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

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

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.

@dmitshur dmitshur added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 20, 2021
@dmitshur dmitshur added this to the Backlog milestone Jan 20, 2021
@dvyukov
Copy link
Member

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
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FeatureRequest NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
Status: Triage Backlog
Development

No branches or pull requests

7 participants