其實從這次的壓力測試可以看出另外一件有趣的事實，就是常常有人 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 排程的問題，不是 CPU 的問題，只要同時工作(proccssor/task) 且佔用 100% 資源的程式大過 processor 數量，多少會造成系統的延遲增高，與 cpu 資源分配不均，主因是在 OS 排程的設計，而非 cpu。

而從另一個角度來看，當有一個 process/thread 需要 real-time or highest level priority 時，系統又有一個較低或一般優先權的行程時，k8 或未開 ht 的 p4 的系統下，OS 會因為優先權的關係，分配大部分 cpu 資源給優先權高的，假設 90%，而另外一個只有 10%，而在 HT 開啟的 p4 系統下，OS 誤以為有兩顆處理器，這時候因為 HT 的關係，可能各得到 50% 的 cpu resource，這樣的結果卻違反了優先權的設定。