Go's scheduler, the GMP model. Will the M busy waiting?

[黎波]

Inside the Go's scheduler, what will happen when an M that already has P attached cannot find a G both from local runqueue (include trying to steal from other P's) and global runqueue.

Will the M keep trying in a busy waiting manner? If so, would this makes the CPU usage in a high level? If not, suppose the M go to idle, e.g. wait on some condition variable stuff. Then when it will get wake up?

[Ian Lance Taylor]

On Wed, Dec 9, 2020 at 9:44 AM 黎波 <lbqq...@gmail.com> wrote:
>
> Inside the Go's scheduler, what will happen when an M that already has P attached cannot find a G both from local runqueue (include trying to steal from other P's) and global runqueue.
>
> Will the M keep trying in a busy waiting manner? If so, would this makes the CPU usage in a high level? If not, suppose the M go to idle, e.g. wait on some condition variable stuff. Then when it will get wake up?

The M will drop the P (by calling releasep and pidleput) and then
suspend itself (by calling stopm). The M will sleep on a note,
m.park. There are then various ways that some other M will wake it up
again, most commonly by calling startm. There are various calls to
startm in the scheduler. For example, one common case is when a
goroutine becomes ready to run (because of a channel receive or
something like that), and there are idle P's, then the waking
goroutine will call startm to wake up some sleeping M, which will in
the normal case acquire the idle P and start running the newly-ready
goroutine.

Ian