引用:
|
作者jasonyang
其實從這次的壓力測試可以看出另外一件有趣的事實，就是常常有人 FUD k8 的多工問題，或說是 "k8 多工迷思"，其實對我們這種學了那麼久的 OS 與程式設計的人來看，這根本就是 OS 排程的問題，當 task/process 數量大於 processor 的數量後，兩者又佔據 100% cpu 資源且優先權相等時，OS 排程器的設計就關乎性能影響甚大。
在這次的測試中，擁有 4 個 logical processor 的 p4ee 跑四隻程式，四個程式都得到平均的使用率，而 2 個 physical processor 的 a64 x2(k8)，k8 在四隻程式中贏了三個，輸了 divx，且 divx 跑得特別慢，這在許多人的眼裡，就是 k8 多工有問題，但是在我們眼裡，只是 OS 排程的問題，THG 證明了這點，THG 最後把 P4EE HT 關閉，也是 2 個 physical processor，結果就是與 k8 一樣的結果(更慘的是 4 隻程式全輸)，沒有什麼 divx 跑特別慢的問題，這就證明了是 OS 排程的問題...
|
Aye... you are god damn right
像 Divx 這種編解碼程式本身的優先權一定不會預設太高, 所以在一個快速反應的系統中，當其他程式能夠不斷獲得資源而迅速的執行時，這類程式就會跑得特別慢；當遇到其他程式未能有效使用資源時，這類程式相對的 CPU 使用率才會提升。其實這也早就不是新聞了，P4 管線...真的太長。所以跑特定測試時，管線比較能夠有效填滿，理論效能就會出來，但是實際軟體測試時，就沒這麼好康了。