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.

Sign up for GitHub

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

Jump to bottom

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

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
Member

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
@dmitshur dmitshur added the FeatureRequest Issues asking for a new feature that does not need a proposal. label 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.

@bcmills bcmills mentioned this issue May 27, 2021
Open
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 7, 2022
@mknyszek mknyszek moved this to Triage Backlog in Go Compiler / Runtime Jul 15, 2022
@srosenberg srosenberg mentioned this issue Jun 22, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FeatureRequest Issues asking for a new feature that does not need a proposal. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
Go Compiler / Runtime
Status: Triage Backlog
Milestone
Backlog
Development

No branches or pull requests
7 participants
@josharian @dvyukov @prattmic @dmitshur @ianlancetaylor @mvdan @gopherbot