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

proposal: runtime: disallow changing GOMAXPROCS #20303

Closed
valyala opened this Issue May 9, 2017 · 7 comments

Comments

Projects
None yet
7 participants
@valyala
Contributor

valyala commented May 9, 2017

The runtime.GOMAXPROCS function allows updating the number of p at any time during the program execution. This could be useful before go1.5 when GOMAXPROCS was set to 1 by default and when goroutine scheduler wasn't very good.

Now the goroutine scheduler is great and GOMAXPROCS equals to the number of available CPU cores by default. So there are no major reasons to change it during program execution. Additionally, GOMAXPROCS may be overridden via environment variable at program start if required:

GOMAXPROCS=1 ./path/to/program

The ability to change GOMAXPROCS in runtime complicates the code in runtime and sync packages. @dvyukov should agree with this :)

The documentation to runtime.GOMAXPROCS explicitly says:

This call will go away when the scheduler improves.

Maybe it's time to make runtime.GOMAXPROCS no-op, i.e. just return the GOMAXPROCS value set at program start?

@gopherbot gopherbot added this to the Proposal milestone May 9, 2017

@gopherbot gopherbot added the Proposal label May 9, 2017

@dvyukov

This comment has been minimized.

Show comment
Hide comment
@dvyukov

dvyukov May 9, 2017

Member

FWIW we use GOMAXPROCS=1 in some tests, and I think cluster management systems may need finer-grained control over GOMAXPROCS during dynamic machine partitioning.

Member

dvyukov commented May 9, 2017

FWIW we use GOMAXPROCS=1 in some tests, and I think cluster management systems may need finer-grained control over GOMAXPROCS during dynamic machine partitioning.

@ianlancetaylor

This comment has been minimized.

Show comment
Hide comment
@ianlancetaylor

ianlancetaylor May 9, 2017

Contributor

Yes, if your VM is reconfigured, or if somebody wants to call sched_setaffinity on your process, then it still makes sense to change GOMAXPROCS.

Contributor

ianlancetaylor commented May 9, 2017

Yes, if your VM is reconfigured, or if somebody wants to call sched_setaffinity on your process, then it still makes sense to change GOMAXPROCS.

@XANi

This comment has been minimized.

Show comment
Hide comment
@XANi

XANi May 11, 2017

Wouldn't that make LockOSThread() way less useful tho ? Currently you can just increase number of goroutines before calling it to be sure you will have other threads to use for rest of goroutines

XANi commented May 11, 2017

Wouldn't that make LockOSThread() way less useful tho ? Currently you can just increase number of goroutines before calling it to be sure you will have other threads to use for rest of goroutines

@ianlancetaylor

This comment has been minimized.

Show comment
Hide comment
@ianlancetaylor

ianlancetaylor May 11, 2017

Contributor

There isn't any real interaction between LockOSThread and GOMAXPROCS. GOMAXPROCS is essentially the number of operating system threads that are permitted to run Go code concurrently. When a goroutine is ready to run, the scheduler permits it to run if there are fewer than GOMAXPROCS threads running. That is true whether or not a goroutine is locked to a thread.

Contributor

ianlancetaylor commented May 11, 2017

There isn't any real interaction between LockOSThread and GOMAXPROCS. GOMAXPROCS is essentially the number of operating system threads that are permitted to run Go code concurrently. When a goroutine is ready to run, the scheduler permits it to run if there are fewer than GOMAXPROCS threads running. That is true whether or not a goroutine is locked to a thread.

@rsc rsc changed the title from proposal: disallow changing GOMAXPROCS in runtime to proposal: runtime: disallow changing GOMAXPROCS May 15, 2017

@rsc

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc May 15, 2017

Contributor

This would certainly eliminate a source of bugs, but we're aware of uses both inside and outside Google that update GOMAXPROCS in reaction to containers or VMs reconfiguring the number of available effective CPUs. We can't do this before Go 2, but even in Go 2 I don't think we can do this.

Contributor

rsc commented May 15, 2017

This would certainly eliminate a source of bugs, but we're aware of uses both inside and outside Google that update GOMAXPROCS in reaction to containers or VMs reconfiguring the number of available effective CPUs. We can't do this before Go 2, but even in Go 2 I don't think we can do this.

@rsc rsc closed this May 15, 2017

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Sep 14, 2017

@valyala you are wrong. There are good reasons to set GOMAXPROCS to > NUMCPU. The scheduler is not that good at all - it is not even preemptive!

ghost commented Sep 14, 2017

@valyala you are wrong. There are good reasons to set GOMAXPROCS to > NUMCPU. The scheduler is not that good at all - it is not even preemptive!

@davecheney

This comment has been minimized.

Show comment
Hide comment
@davecheney

davecheney Sep 14, 2017

Contributor

This issue has been closed for several months, please do not consent further.

We don't the issue tracker to ask questions. Please see https://golang.org/wiki/Questions for good places to continue this discussion. Thanks.

Contributor

davecheney commented Sep 14, 2017

This issue has been closed for several months, please do not consent further.

We don't the issue tracker to ask questions. Please see https://golang.org/wiki/Questions for good places to continue this discussion. Thanks.

@golang golang locked and limited conversation to collaborators Sep 14, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.