CC @aclements @RLH

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.

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

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.

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