[閒聊] IntelIce Lake Xeon 離開休眠過長

PC購物

標籤:閒聊
18100

寫在前面:

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,但可能會
導致更高的功耗以換取更高的性能。

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.160.72.29 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/PC_Shopping/M.1594990032.A.7A1.html
本人1樓特定情形下,或許我們會見到14nm比10nm省電QQ 07/17 20:50
ariadne2樓這是好問題 之後用大小核 結束休眠要先叫醒誰? XD 07/17 20:51
本人3樓邏輯太復雜 deadlocked 大小都一起一睡不起 07/17 20:57
bubunana4樓SKL KBL初期發布都有這問題 CPU 內frabic內PMU部分 07/17 21:00
bubunana5樓FW再調整就可以解決 若客戶決定這state用不到 還是 07/17 21:00
bubunana6樓要急著出貨 直接禁用也不是沒有過 因為改那塊 等於 07/17 21:00
bubunana7樓全部都要重驗 幾個月時間跑不掉 07/17 21:00
jior8樓不建議超頻之後是不建議休眠了嗎? 07/17 21:01
bubunana9樓不過原Po結論蠻有趣的 哈! 07/17 21:01
bubunana10樓那是servers 用耶 進cstate很重要? 07/17 21:03
cancelpc11樓會啊,有人會戰拿來當伺服器時的待機功耗XD 07/17 21:08
storm082212樓會醒不過來?那就不讓你睡 07/17 21:27
yymeow13樓一般來說終端的工程師會直接在伺服器設定不要睡那麼 07/17 21:35
yymeow14樓沉就好了。基本上工程師只祈禱能好好動,放十包乖乖 07/17 21:36
yymeow15樓也ok 07/17 21:36
friedpig16樓買伺服器來待機臭了嗎 07/17 21:37
yymeow17樓說老實話server會睡到攤也很少見 XD 07/17 21:38
friedpig18樓就還沒正式launch的產品 bug很多很意外嗎 07/17 21:39
本人19樓10nm這問題還蠻大的 另一點是whitley是一延又延 正 07/17 22:13
本人20樓常是不會搞這麼久 07/17 22:13
本人21樓然後什麼量產品睡了某幾core回不來 就是另個故事了 07/17 22:16
jasonkey12322樓server用途都是24h運作,影響不大 07/17 22:30
sdbb23樓救救北極熊 07/17 22:40
leung374025024樓大概要等幾個月後的新步進才會修,反正對伺服器而 07/18 00:40
leung374025025樓言問題不大 07/18 00:40
mmnnoo26樓稍微看一下內文而已,文章講的不是指OS的待機/休眠 07/18 01:04
mmnnoo27樓動作吧?而是Linux kernel的light sleep/deep sleep 07/18 01:05
mmnnoo28樓?是的話,那就無關Server是24h工作這件事情了,而 07/18 01:05
mmnnoo29樓是你CPU不忙的時候,low power表現很差~~~ 這樣就挺 07/18 01:06
mmnnoo30樓嚴重的... 07/18 01:06
延伸閱讀
[閒聊] 關於intel官網尚無400系列晶片組驅動
[閒聊] 大超組裝PC菜單
[閒聊] MSI被指控企圖賄賂評測員
[閒聊] 羅技G533 心累的RMA過程(圖多
Re: [閒聊] AVX指令集實際應用是甚麼功能?
[閒聊] HP怎麼可以這麼爛
[閒聊] VA面板怎麼都做曲面的?因成本低還是好賣?
[閒聊]維修價格是原價快要三倍的路由器