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: empty local run queue when executing dedicated GC worker #20011

Closed
zhaozhiqianghw opened this issue Apr 17, 2017 · 5 comments

Comments

Projects
None yet
5 participants
@zhaozhiqianghw
Copy link

commented Apr 17, 2017

For the dedicated goroutine doing marking work between STW1 and STW2, it can not be preempted until finishing the initial marking work. So how about the goroutines in the local queue of the P executing this gcmarking work goroutine. They are starving?

I doesn't find any codes to move the goroutines from local queue to global queue so that this goroutines can be scheduled. So please help me clear about it. If runtime doesn't do it, I think it's quite unfair for the goroutines in the local queue of the P executing the dedicated goroutine.

@zhaozhiqianghw zhaozhiqianghw changed the title runtime:gc how about the goroutines in local queue of the P executing the GC goroutine runtime:gc how about the goroutines in local queue of the P executing the GC dedicated marking goroutine Apr 17, 2017

@ianlancetaylor ianlancetaylor changed the title runtime:gc how about the goroutines in local queue of the P executing the GC dedicated marking goroutine runtime: gc how about the goroutines in local queue of the P executing the GC dedicated marking goroutine Apr 17, 2017

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Apr 17, 2017

@aclements

This comment has been minimized.

Copy link
Member

commented Apr 17, 2017

You're right that there's no code to actively push these goroutines out of the queue, but other Ps will still steal them off the queue. I don't think it would be hard to kick them to the global queue; I just haven't seen concrete evidence that this is a problem.

@aclements aclements added this to the Go1.9Maybe milestone Apr 17, 2017

@zhaozhiqianghw

This comment has been minimized.

Copy link
Author

commented Apr 17, 2017

The stealling will occur when the local queues are empty of all other Ps and the global queue is also empty which is a quite no-busy state. I mean that if the P executing GC marking goroutines need other M to steal its goroutines, it will never happen when the system is busy. So the goroutines in the local queue of the P executing GC marking goroutine will come across large latency. If they are put into global queue, they will have more probabilities to be scheduled. @aclements

@randall77

This comment has been minimized.

Copy link
Contributor

commented Apr 17, 2017

Go doesn't have a fair goroutine scheduler. So if your system is > 100% loaded, you're going to have to starved goroutines no matter what. If you're below 100% loaded, you will have periods where there are no goroutines to run and any goroutines in queues will get stolen.
At just around 100% loaded, there may be things we can do to make things better, for instance by preferentially stealing from Ps which are otherwise occupied with GC work.

@aclements aclements changed the title runtime: gc how about the goroutines in local queue of the P executing the GC dedicated marking goroutine runtime: empty local run queue when executing dedicated GC worker Jun 23, 2017

@gopherbot

This comment has been minimized.

Copy link

commented Jun 23, 2017

CL https://golang.org/cl/46610 mentions this issue.

@gopherbot gopherbot closed this in 489620d Jun 26, 2017

@golang golang locked and limited conversation to collaborators Jun 26, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.