寫在前面:
Tom's hardware最近發的好文
俗話說解決不了問題就解決發現問題的人
愛買又愛嫌, 是不會去買AMD?
機器翻譯加人工潤飾,建議直上原文
別帖:Intel 10nm真讓人頭大：不只頻率上不去還不穩定
本文:
Sleepy Intel Ice Lake Xeons Take Longer to Ramp Up Frequency Than Expected
https://www.tomshardware.com/news/
sleepy-intel-ice-lake-xeons-take-longer-to-ramp-up-frequency
翻譯:
標題:Intel Ice Lake Xeon花了比預期更長的時間離開休眠
副標:如何解決?別讓CPU睡下去
Linux kernal的最新patch（透過Phoronix）指出了英特爾近乎神話般的10nm + Ice
Lake Xeon處理器的一個有趣問題：退出某些睡眠狀態後，CPU花費比預期更長的時間才能
恢復正常頻率，這將影響性能一致性, 由於“不穩定” 的CPU時鐘頻率。
這個問題的嚴重性尚不清楚，但如果沒有其他說明，它確實表明了英特爾在Ice Lake
Xeon處理器上的工作仍在繼續，儘管存在一些挑戰。由於有報導稱英特爾的server 時程
再次受到延遲，我們上週聯繫了該公司，以確認時間表是否仍然按計劃進行。該公司回應
說：“我們仍有望在2H20向客戶交付10nm Ice Lake。”
我們拭目以待。回到眼前的問題。處理器處於各種C state（休眠），以減少空閒期間的
總體功耗。 C state對每個內核的省電程度不同，最深層的睡眠包括停止內核時鐘，刷新
快取和降低電壓以最大程度地省電。此外，應用package C state，從而減少CPU package
上由所有內核（例如fabric和uncore）共享的資源的功耗和clock。
註: CPU package = Core + Uncore, 所以有C state和package C state
睡眠狀態越深，每個處理器可以節省的電量就越多。但是，從較深的睡眠狀態恢復到全速
需要的時間比較淺的睡眠狀態要長。根據報告，對於Ice Lake Xeon處理器，某些電源狀
態下該過程似乎需要更長的時間。
英特爾“kernal測試機器人”發布了patch並解釋了該問題。正如Phoronix所指出的那樣
，此修復程式碼來自一位英特爾員工，這意味著該公司很可能在自己的測試中遇到了該問
題。該問題的解釋如下：
“在ICX平台上，當從比C1E更深/等於C1E的C State喚醒時，CPU頻率將緩慢上升。儘管此
功能確實在許多情況下節省了能量，但這也可能導致意外結果。例如，工作負載可能會導
致性能不穩定由於CPU頻率的不穩定，另外，當CPU利用率較低時，CPU頻率可能無法鎖定
為特定水平。
“因此，此修補程式碼將禁用C1E auto promotion，並將C1E暴露為單獨的idle state，
以便在必要時可以通過sysfs禁用C1E和C6。”
為了解決該問題，系統可以完全禁用C1E和C6狀態，從而防止晶片進入較低的睡眠狀態。
工程師進一步闡述了這個問題： “除了C1和C1E，C6的退出延遲是通過專用工具測量的。
但是_CST暴露的退出延遲（41us）比我們測量的退出延遲（128us）小得多。這可能是由
於_CST使用從PkgC0 + C6喚醒時的延遲，而不是在測量C6時喚醒的PC6 + C6。因為我
們需要理論上最長的延遲所以選擇後者。” 在這裡，我們看到問題出在如何測量退出等
待時間（CPU彈回到全速狀態所花費的時間），然後暴露給Kernal。 ACPI_CST將C state
資訊傳達給Kernal，它列出了處理器處於PkgC0 + C6狀態時測得的延遲。這意味著一個或
多個內核可能處於C6睡眠狀態，但是其餘的package（fabric和uncore）仍在全速（PkgC0
）運作。在這種狀態下，core僅需41us即可恢復正常操作。 但是，當處理器進入PkgC6
+ C6狀態時，package也會與core一起掉電（PkgC6狀態），因此處理器要花更多時間才能
恢復全速。英特爾在這種情況下測出128us的睡眠退出延遲，因此看來Kernal得到了錯誤
的睡眠退出值。 只是為了了解它與其他Intel處理器有何不同，我們搜索了基於Skylake
的處理器的典型睡眠退出延遲。
我們回顧了去年初由大都會應用科學大學的Vladislav Govtva撰寫的有趣的學士論文
[PDF]。他測量了幾代不同英特爾處理器的睡眠退出延遲，而在上面我們可以看到他使用
英特爾至強鉑金8170M（Skylake）的結果。 Govtva在C6狀態下測得的最大喚醒延遲（與
退出延遲相同）約為108us，這比Ice Lake處理器快20us。這裡可能涉及不同的測量標準
，但是簡單比較數字就知道睡眠退出延遲增加18.5％。 英特爾似乎已通過允許系統在特
定條件下禁用某些睡眠狀態來“解決”了該問題，但這很可能只是一個極端情況，不適用
於許多類型的應用場合。我們正在與Intel進行進一步的澄清，但是鑑於Ice Lake尚未正
式發布，因此我們希望不會學到很多東西。 有趣的是，英特爾是否會繼續通過磨牙(?)來
調整該參數。 Phoronix認為該patch可以進入下個月開放的Linux 5.9 cycle，但可能會
導致更高的功耗以換取更高的性能。
--
Tom's hardware最近發的好文
俗話說解決不了問題就解決發現問題的人
愛買又愛嫌, 是不會去買AMD?
機器翻譯加人工潤飾,建議直上原文
別帖:Intel 10nm真讓人頭大：不只頻率上不去還不穩定
本文:
Sleepy Intel Ice Lake Xeons Take Longer to Ramp Up Frequency Than Expected
https://www.tomshardware.com/news/
sleepy-intel-ice-lake-xeons-take-longer-to-ramp-up-frequency
翻譯:
標題:Intel Ice Lake Xeon花了比預期更長的時間離開休眠
副標:如何解決?別讓CPU睡下去
Linux kernal的最新patch（透過Phoronix）指出了英特爾近乎神話般的10nm + Ice
Lake Xeon處理器的一個有趣問題：退出某些睡眠狀態後，CPU花費比預期更長的時間才能
恢復正常頻率，這將影響性能一致性, 由於“不穩定” 的CPU時鐘頻率。
這個問題的嚴重性尚不清楚，但如果沒有其他說明，它確實表明了英特爾在Ice Lake
Xeon處理器上的工作仍在繼續，儘管存在一些挑戰。由於有報導稱英特爾的server 時程
再次受到延遲，我們上週聯繫了該公司，以確認時間表是否仍然按計劃進行。該公司回應
說：“我們仍有望在2H20向客戶交付10nm Ice Lake。”
我們拭目以待。回到眼前的問題。處理器處於各種C state（休眠），以減少空閒期間的
總體功耗。 C state對每個內核的省電程度不同，最深層的睡眠包括停止內核時鐘，刷新
快取和降低電壓以最大程度地省電。此外，應用package C state，從而減少CPU package
上由所有內核（例如fabric和uncore）共享的資源的功耗和clock。
註: CPU package = Core + Uncore, 所以有C state和package C state
睡眠狀態越深，每個處理器可以節省的電量就越多。但是，從較深的睡眠狀態恢復到全速
需要的時間比較淺的睡眠狀態要長。根據報告，對於Ice Lake Xeon處理器，某些電源狀
態下該過程似乎需要更長的時間。
英特爾“kernal測試機器人”發布了patch並解釋了該問題。正如Phoronix所指出的那樣
，此修復程式碼來自一位英特爾員工，這意味著該公司很可能在自己的測試中遇到了該問
題。該問題的解釋如下：
“在ICX平台上，當從比C1E更深/等於C1E的C State喚醒時，CPU頻率將緩慢上升。儘管此
功能確實在許多情況下節省了能量，但這也可能導致意外結果。例如，工作負載可能會導
致性能不穩定由於CPU頻率的不穩定，另外，當CPU利用率較低時，CPU頻率可能無法鎖定
為特定水平。
“因此，此修補程式碼將禁用C1E auto promotion，並將C1E暴露為單獨的idle state，
以便在必要時可以通過sysfs禁用C1E和C6。”
為了解決該問題，系統可以完全禁用C1E和C6狀態，從而防止晶片進入較低的睡眠狀態。
工程師進一步闡述了這個問題： “除了C1和C1E，C6的退出延遲是通過專用工具測量的。
但是_CST暴露的退出延遲（41us）比我們測量的退出延遲（128us）小得多。這可能是由
於_CST使用從PkgC0 + C6喚醒時的延遲，而不是在測量C6時喚醒的PC6 + C6。因為我
們需要理論上最長的延遲所以選擇後者。” 在這裡，我們看到問題出在如何測量退出等
待時間（CPU彈回到全速狀態所花費的時間），然後暴露給Kernal。 ACPI_CST將C state
資訊傳達給Kernal，它列出了處理器處於PkgC0 + C6狀態時測得的延遲。這意味著一個或
多個內核可能處於C6睡眠狀態，但是其餘的package（fabric和uncore）仍在全速（PkgC0
）運作。在這種狀態下，core僅需41us即可恢復正常操作。 但是，當處理器進入PkgC6
+ C6狀態時，package也會與core一起掉電（PkgC6狀態），因此處理器要花更多時間才能
恢復全速。英特爾在這種情況下測出128us的睡眠退出延遲，因此看來Kernal得到了錯誤
的睡眠退出值。 只是為了了解它與其他Intel處理器有何不同，我們搜索了基於Skylake
的處理器的典型睡眠退出延遲。
我們回顧了去年初由大都會應用科學大學的Vladislav Govtva撰寫的有趣的學士論文
[PDF]。他測量了幾代不同英特爾處理器的睡眠退出延遲，而在上面我們可以看到他使用
英特爾至強鉑金8170M（Skylake）的結果。 Govtva在C6狀態下測得的最大喚醒延遲（與
退出延遲相同）約為108us，這比Ice Lake處理器快20us。這裡可能涉及不同的測量標準
，但是簡單比較數字就知道睡眠退出延遲增加18.5％。 英特爾似乎已通過允許系統在特
定條件下禁用某些睡眠狀態來“解決”了該問題，但這很可能只是一個極端情況，不適用
於許多類型的應用場合。我們正在與Intel進行進一步的澄清，但是鑑於Ice Lake尚未正
式發布，因此我們希望不會學到很多東西。 有趣的是，英特爾是否會繼續通過磨牙(?)來
調整該參數。 Phoronix認為該patch可以進入下個月開放的Linux 5.9 cycle，但可能會
導致更高的功耗以換取更高的性能。
--
All Comments