# 6.12 非均勻訪存下的調度模型 ## 6.12.1 調度器架構的演變 Go 的運行時調度器只經歷了兩個主要版本的迭代。Go 語言誕生之初的調度器，和我們現在所看到的從 Go 1.1 起引入的工作竊取調度器。 ### 單線程版調度器 最早期（Go 1 之前）的 Go 調度器甚至不能良好的支持多線程 \[Cox, 2008\]，即默認的最大 M 數為 1。 這個版本的調度器負責將準備運行的 G 與等待工作的調度程序 M 相匹配。如果有準備好的 G 且沒有等待的 M，則會在新的 OS 線程中啟動一個新的 m， 這樣所有準備好的（有限多個）G 可以同時運行。并且，這時的 M 無法退出。 原因在于最早先的 Go 只適當的支持了 Linux，甚至連目標支持的 OS X （當時還沒有更名為 macOS）也尚未實現。 其中一個主要的問題就在調度器鎖的處理并不完善、垃圾回收的支持也不夠完整。 ### 多線程版調度器 隨后的一年時間中，調度器得到了完善的改進，能夠正式的支持多個系統線程的版本 \[Cox, 2009\]。 但這時仍然需要用戶態代碼通過 $GOMAXPROCS 或 runtime.GOMAXPROCS() 調用來調整最大核數。 而`m`不能退出的問題仍然沒有得到改進。 ### 工作竊取調度器 隨著 Go 1.1 的出現，Go 的運行時調度器得到了質的飛越，調度器正式引入 M 的本地資源 P \[Vyukov, 2013a\]， 大幅降低了任務調度時對全局鎖的競爭，提出了沿用至今的 MPG 工作竊取式調度器設計。 我們已經在前面的使用了大量篇幅介紹這一調度器的設計，這里便不再贅述了。 ## 6.12.2 改進展望：非均勻訪存感知的調度器 目前的調度器設計總是假設 M 到 P 的訪問速度是一樣的，即不同的 CPU 核心訪問多級緩存、內存的速度一致。 但真實情況是，在 NUMA（non-uniform memory access，非均勻訪存）架構下，CPU 僅在 局部訪問自身 NUMA 節點內的內存時才能獲得一致的訪問速度。更一般地說，這種基于 NUMA 架構的處理器是也是一個分布式的系統。 **圖 1：NUMA 架構** 針對這一點，Go 官方已經提出了具體的調度器設計 \[Vyukov, 2014\]，但由于工作量巨大，甚至沒有提上日程。 TODO: 討論設計的優劣 ## 小結 Go 語言用戶態代碼的調度核心在未來的十年里只進行了兩次改進，足見其設計功力， 但隨著 Go 語言的大規模應用，以及越來越多的在多核機器上使用調度器的性能問題也會逐漸暴露出來， 讓我們對未來下一個大版本的改進拭目以待。