-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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: goroutine starvation due to Gosched #13546
Comments
Interesting, though I agree with your assessment that this seems relatively low priority. I think if we fix the problem with non-preemptible loops (#10958) it will also fix this, and I'd much rather fix non-preemptible loops than try to put a hack in the scheduler (unless it can be more generally justified). Hopefully SSA will make it easier to fix non-preemptible loops (because SSA will make everything easier, right? :) |
Yes, fixing non-preemptible loops is definitely better. |
Closing as a dup of #10958, though we can of course reopen if we want to take a more specific approach to this problem. |
The following program hangs:
One goroutine constantly calls
runtime.Gosched
but another runnable goroutine is starved.The root cause is: Gosched puts the current goroutine onto global run queue, then the thread check local run queue (empty), then it checks global run queue and picks up the old goroutine again. But at the same time there is another runnable goroutine in remote per-P queue.
This is probably not super critical, as it can happen only if there are goroutines in tight non-preemptable loops. But still we could check local queues ahead of global queue once in a while in findrunnable. We do the opposite hack in schedule -- check global queue ahead of local queue once in a while. On the other hand this will destroy locality, which is bad for performance...
The text was updated successfully, but these errors were encountered: