一区二区三区三上|欧美在线视频五区|国产午夜无码在线观看视频|亚洲国产裸体网站|无码成年人影视|亚洲AV亚洲AV|成人开心激情五月|欧美性爱内射视频|超碰人人干人人上|一区二区无码三区亚洲人区久久精品

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

谷歌在內(nèi)存方面依賴于per memcg lru lock

Linux閱碼場 ? 來源:Linuxer ? 作者:Linuxer ? 2021-01-15 14:00 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

自電子計算機誕生以來,內(nèi)存性能一直是行業(yè)關(guān)心的重點。內(nèi)存也隨著摩爾定律,在大小和速度上一直增長。現(xiàn)在的阿里云服務器動輒單機接近TB的內(nèi)存大小,加上數(shù)以百記的CPU數(shù)量也著實考驗操作系統(tǒng)的資源管理能力。

作為世間最流行的操作系統(tǒng)Linux, 內(nèi)核使用LRU, Last Recent Used 鏈表來管理全部用戶使用的內(nèi)存,用一組鏈表串聯(lián)起一個個的內(nèi)存頁,并且使用lru lock來保護鏈表的完整性。

b3ca29b4-56f1-11eb-8b86-12bb97331649.png

所有應用程序常用操作都會涉及到LRU鏈表操作,例如,新分配一個頁,需要掛在inactive lru 鏈上, 2次訪問同一個文件地址, 會導致這個頁從inactive 鏈表升級到active 鏈表, 如果內(nèi)存緊張, 頁需要從active 鏈表降級到inactive 鏈表, 內(nèi)存有壓力時,頁被回收導致被從inactive lru鏈表移除。不單大量的用戶內(nèi)存使用創(chuàng)建,回收關(guān)系到這個鏈表, 內(nèi)核在內(nèi)存大頁拆分,頁移動,memcg 移動,swapin/swapout, 都要把頁移進移出lru 鏈表。

可以簡單計算一下x86服務器上的鏈表大?。簒86最常用的是4k內(nèi)存頁, 4GB 內(nèi)存會分成1M個頁, 如果按常用服務器256GB頁來算, 會有超過6千萬個頁掛在內(nèi)核lru 鏈表中。超大超長的內(nèi)存鏈表和頻繁的lru 操作造成了2個著名的內(nèi)核內(nèi)存鎖競爭, zone lock, 和 lru lock. 這2個問題也多次在阿里內(nèi)部造成麻煩, 系統(tǒng)很忙, 但是業(yè)務應用并沒得到多少cpu時間, 大部分cpu都花在sys上了。一個簡單2次讀文件的benchmark可以顯示這個問題, 它可以造成70%的cpu時間花費在LRU lock上。

作為一個知名內(nèi)核性能瓶頸, 社區(qū)也多次嘗試以各種方法解決這個問題, 例如,使用更多的 LRU list, 或者LRU contention 探測。

但是都因為各種原因被linux 內(nèi)核拒絕。

尋找解決方案

通過仔細的觀察發(fā)現(xiàn), 內(nèi)核在2008年引進內(nèi)存組-memcg以來, 系統(tǒng)單一的lru lists已經(jīng)分成了每個內(nèi)存組一個lru list, 由每個內(nèi)存組單獨管理自己的lru lists。那么按道理lru lock的contention應該有所減小???為什么還是經(jīng)常在內(nèi)部服務器觀察到lru lock hot引起的sys 高?

原來, 內(nèi)核在引入per memcg lru lists后,并沒有使用per memcg lru lock, 還在使用舊的全局lru lock 來管理全部memcg lru lists. 這造成了本來可以自治的memcg A, 卻要等待memcg B 釋放使用的lru lock。然后A拿起的lru lock又造成 memcg C的等待。。。

那么把全局lru lock拆分到每一個memcg中, 不是可以理所當然的享受到了memcg獨立的好處了嗎?這樣每個memcg 都不會需要等待其他memcg 釋放lru lock。鎖競爭限制在每個memcg 內(nèi)部了。

b426b940-56f1-11eb-8b86-12bb97331649.png

要完成lru lock 拆分,首先要知道lru lock 保護了多少對象, 通常情況中, page lru lock需要保護lru list完整性, 這個是必須的。與lru list相關(guān)的還有page flags中的lru bit,這個lru bit用作頁是否在lru list存在的指示器, 可以避免查表才能知道頁是否在list中。那么lru lock保護它也說的通。

但是lru lock 看起來還有一些奇怪的保護對象,承擔了一些不屬于它的任務:

1.PageMlock bit,保護 munlock_vma 和split_huge_page 沖突,

其實, 上述2個函數(shù)在調(diào)用鏈中都需要 page lock, 所以沖突可以完全由page lock來保證互斥。這里lru lock使用屬于多余。

2.pagecache xa_lock和memcg->move_lock,

xa_lock并沒有需要lru lock保護的場景,這個保護也是多余。相反,lru lock放到xa_lock 之下, 符合xa_lock/lock_page_memcg, 的使用次序。反而可以優(yōu)化 lru lock 和 memcg move_lock的關(guān)系。

3.lru bit in page_idle_get_page, 用在這里是因為擔心 page_set_anon_rmap中, mapping 被提前預取訪問,造成異常。用memory barrier 方式可以避免這個預取, 所以可以在page idle中撤掉lru lock.

+ WRITE_ONCE(page->mapping, (struct address_space *) anon_vma);

經(jīng)過這樣的修改, lru lock 可以在memory lock 調(diào)用層次中降級到最底層。

b46d8b40-56f1-11eb-8b86-12bb97331649.png

這時, lru lock已經(jīng)非常簡化,可以用per memcg lru lock來替換全局的lru lock了嗎?還不行,使用per memcg lru lock 有一個根本問題,使用者要保證 page所屬的memcg不變,但是頁在生命周期中是可能轉(zhuǎn)換memcg的,比如頁在memcg之間migration,導致 lru_lock隨著memcg變化, 拿到的lru lock是錯誤的,好消息是memcg 變化也需要先拿到lru lock鎖,這樣我們可以獲得lru lock之后檢查這個是不是正確的鎖:

b4a700dc-56f1-11eb-8b86-12bb97331649.png

如果不是, 由反復的relock 來保證鎖的正確性。bingo! 完美解決!

由此, 這個feature曲折的upstream 之路開始了。。。

最終解決

這個patchset 2019年發(fā)出到社區(qū)之后, google的 Hugh Dickins 提出, 他和facebook的Konstantin Khlebnikov 同學已經(jīng)在2011發(fā)布了非常類似的patchset,當時沒有進主線。不過google內(nèi)部生產(chǎn)環(huán)境中一直在使用。所以現(xiàn)在Hugh Dickins發(fā)出來他的upstream版本。關(guān)鍵路徑和我的版本是一樣的

2個相似patchset的PK, 引起了memcg 維護者Johannes 的注意, Johannes發(fā)現(xiàn)在compaction的時候, relock并不能保護某些特定場景:

b55f3e36-56f1-11eb-8b86-12bb97331649.png

所以他建議,也許增加原子的lru bit操作作為 lru_lock 的前提也許可以保護這個場景。Hugh Dickins 則不認為這樣會有效,并且堅持他patchset已經(jīng)在google內(nèi)部用了9年了。一直安全穩(wěn)定。。。

Johannes的建議的本質(zhì)是使用lru bit代替lru lock做page isolation互斥,但是問題的難點在其他地方, 比如在通常的一個swap in 的場景中:

b5bc905e-56f1-11eb-8b86-12bb97331649.png

swap in 的頁是先加入lru, 然后charge to memcg, 這樣造成頁在加入lru 時,并不知道自己會在那個memcg上, 我們也拿不到正確的per memcg lru_lock, 所以上面場景中左側(cè)CPU 即使提前檢查PageLRU 也找不到正確的lru lock 來阻止右面cpu的操作, 然并卵。

正確的解決方案, 就是上面第9步移動到第7步前面, 在加入lru前charge to memcg. 并且在取得lru lock之前檢查lru bit是否存在, 這樣才可以保證我們可以拿到的是正確的memcg 的lru lock。由此提前清除/檢查lru bit的方法才會有效。這個memcg charge的上升, 在和Johannes討論后, Johannes在5.8 完成了代碼實現(xiàn)并且和入主線。

在新的代碼基礎(chǔ)上, 增加了lru bit的原子操作TestClearPageLRU, 把lru bit移出了lru lock的保護,相反用這個bit來做page isolation的互斥條件, 用isolation來保護頁在memcg間的移動, 讓lru lock只完成它的最基本任務, 保護lru list完整性。至此方案主體完成。lru lock的保護對象也由6個減小到一個。編碼實現(xiàn)就很容易了。

b61bc128-56f1-11eb-8b86-12bb97331649.png

測試結(jié)果

方案完成后, 上面提到的file readtwice 測試中,多個memcg的情況下,lru lock 競爭造成的sys 從70% 下降了一半,throughput 提高到260%。(80個cpu的神龍機器)

b652d294-56f1-11eb-8b86-12bb97331649.png

Upstream過程

經(jīng)過漫長4輪的逐行review, 目前這個feature 已經(jīng)進入了 linus的 5.11 https://github.com/torvalds/linux

第一版patch 發(fā)到了社區(qū)后, google的skakeel butt立刻提出, google曾經(jīng)在2011發(fā)過一樣的patchset來解決 per memcg lru lock 問題。所以,skakeel 要求我們停止自己開發(fā), 基于google的版本來解決這個問題。然后我才發(fā)現(xiàn)真的2011年 google Hugh Dickins 和 Facebook Konstantin Khlebnikov 就大約同時提出類似的patchset。, 但是當時引起的關(guān)注比較少,也缺乏benchmark來展示補丁的效果, 所以很快被社區(qū)遺忘了。不過google內(nèi)部則一直在維護這組補丁,隨他們內(nèi)核版本升級。

對比google的補丁, 我們的實現(xiàn)共同點都是使用relock來確保page->memcg線性化, 其他實現(xiàn)細節(jié)則不盡相同。測試表明我們的patch性能更好一點。于是我基于自己的補丁繼續(xù)修改并和Johannes討論方案改進。這也導致了以后每一版都有g(shù)oogle同學的反對:我們的測試發(fā)現(xiàn)你的patchset 有bug, 請參考google可以工作的版本。并在linux-next上發(fā)現(xiàn)一個小bug時達到頂峰:https://lkml.org/lkml/2020/3/6/627 google同學批評我們抄他們的補丁還抄出一堆bug.

b6a804d0-56f1-11eb-8b86-12bb97331649.png

其實這些補丁和Hugh Dickins的補丁毫無關(guān)聯(lián), 并且在和Johannes的持續(xù)討論中,解決方案的核心:page->memcg的線性化已經(jīng)進化了幾個版本了, 從relock 到 lock_page_memcg, 再到TestClearPageLRU. 和google的補丁是路線上的不同。

面對這樣的無端指責,memcg 維護者 Johannes 看不下去, 出來說了一些公道話:我和Alex同學都在嘗試和你不同的方案來解決上次提出的compacion沖突問題,而且我記得你當時是覺得這個沖突你無能為力的:

b7422466-56f1-11eb-8b86-12bb97331649.png

之后google同學分享了他們的測試程序,然后在這個話題上沉默了一段時間。

后來memcg charge的問題解決后, 就可以用lru bit來保證page->memcg互斥了。v17 coding很快完成后。intel 的Alexander Duyck, 花了5個星期, 逐行逐字的review整個patchset, 并其基于補丁的改進, 提出了一些后續(xù)優(yōu)化補丁。5個星期的review, 足以讓一個feature 錯過合適的內(nèi)核upstream 窗口。但是也增強了社區(qū)的信心。

(重大內(nèi)核的feature 的merge窗口是這樣的:大的feature 在進入linus tree之前, 要在linux-next tree 待一段時間, 主要的社區(qū)測試如Intel LKP, google syzbot 等等也會在著重測試Linux-next。所以為了保證足夠的測試時間, 進入下個版本重要feature 必須在當前版本的rc4之前進入linux-next。而當前版本-rc1通常bug比較多, 所以最佳rebase 版本是 rc2, 錯過最佳merge 窗口 rc2-rc4. 意味著需要在等2個月到下一個窗口。并且還要適應新的內(nèi)核版本的相關(guān)修改。)

基于5.9-rc2的 v18 版本完成后, google hugh dickins同學強勢歸來,主動申請測試和review,根據(jù)他的意見v18 做了很多刪減和合并,甚至推翻了一些Alexander Duyck要求的修改。patch 數(shù)量從32個壓縮到20個。Hugh Dickin 逐行review 了整整4個星期。也完美錯過了5.10和入窗口。之后v19, Johannes 同學終于回來開始review. Johannes比較快,一個星期就完成了review?,F(xiàn)在v20, 幾乎每個patch 都有了2個reviewed-by: Hugh/Johannes.

然而, 這次不像以前, 以前 patchset 沒有人關(guān)心, 這次大家的review興趣很大,來了就停不住, SUSE的 Vlastimil Babka 同學又過來開始review, 并且提出了一些coding style 和代碼解釋要求。不過被強勢的Hugh Dickins 駁回:

b781fed8-56f1-11eb-8b86-12bb97331649.png

Hugh 的影響力還是很大的, Vlastimil 和其他潛在的reivewer都閉上了嘴。代碼終于進了基于5.10-rc 的 linux-next。不過這個駁回也引起一個在5.11提交窗口的麻煩, memory總維護者 Andrew Morthon突然發(fā)現(xiàn)Vlastimil Babka 表示過一些異議。所以他問我:是不是輿論還不一致, 還有曾經(jīng)推給你一個bug, 你解決了嗎?

I assume the consensus on this series is 'not yet"?

Hugh再次出來護場:我現(xiàn)在覺得patchset 足夠好了, 足夠多人review過足夠多的版本了, 已經(jīng)在linux-next 安全運行一個多月了,沒有任何功能和性能回退, Vlastimil也已經(jīng)沒有意見了。至于那個bug, Alex有足夠的證據(jù)表明和這個補丁無關(guān)。。。

b7cd8df8-56f1-11eb-8b86-12bb97331649.png

最終這個patchset享受到了Andrew 向 Linus單獨推送的待遇。進了5.11。

后記

在 Linux 上游做事情,有很多成就感,也可以保證自己需要的feature,一直在線, 免去了內(nèi)核升級維護之苦。但也會面臨荊棘和險阻, 各種內(nèi)部不關(guān)心的場景都要照顧到, 不能影響其他任何人的feature。所以相比coding, 大量的社區(qū)討論大概是coding的3~5倍時間,主要是反復的代碼解釋和修改.

在整個upstreaming的過程中特別值得一提的是一些google的同學態(tài)度轉(zhuǎn)變, 從一開始的反對,到最后加入我們。從google方面來說, google在內(nèi)存方面有很多優(yōu)化都依賴于per memcg lru lock. 這個代碼加入內(nèi)核也解除了他們9年來的代碼維護痛苦。

原文標題:memcg lru lock 血淚史

文章出處:【微信公眾號:Linuxer】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

責任編輯:haq

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • Linux
    +關(guān)注

    關(guān)注

    87

    文章

    11507

    瀏覽量

    213521
  • 操作系統(tǒng)
    +關(guān)注

    關(guān)注

    37

    文章

    7135

    瀏覽量

    125450

原文標題:memcg lru lock 血淚史

文章出處:【微信號:LinuxDev,微信公眾號:Linux閱碼場】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關(guān)推薦
    熱點推薦

    擺脫依賴英偉達!OpenAI首次轉(zhuǎn)向使用谷歌芯片

    電子發(fā)燒友網(wǎng)報道(文/李彎彎)近日,據(jù)知情人士透露,OpenAI近期已開始租用谷歌的張量處理單元(TPU),為旗下ChatGPT等熱門產(chǎn)品提供算力支持。這一舉措不僅標志著OpenAI首次實質(zhì)性
    的頭像 發(fā)表于 07-02 00:59 ?6592次閱讀

    時間的力量:RTC如何賦能萬物精準運行?

    這些我們習以為常的“準時”與“精確”,背后都依賴于電子設(shè)備的“時序基準源”——實時時鐘(Real-Time Clock, RTC)。
    的頭像 發(fā)表于 05-28 17:21 ?235次閱讀
    時間的力量:RTC如何賦能萬物精準運行?

    Altera Agilex 5 D系列FPGA的性能和能效

    隨著邊緣計算領(lǐng)域的迅速發(fā)展,許多應用日益依賴于內(nèi)存技術(shù)來實現(xiàn)更高的性能或每瓦性能。Altera 的 Agilex 5 D 系列 FPGA 可提供一系列經(jīng)過精心設(shè)計的內(nèi)存選擇,助力用戶輕松采用先進的
    的頭像 發(fā)表于 03-27 13:36 ?601次閱讀

    穩(wěn)定性建設(shè)之依賴設(shè)計

    作者:京東物流 馮志文 背景 隨著分布式微服務的發(fā)展,一個普通的應用可能會依賴于許多其他服務,這給系統(tǒng)的限流降級、優(yōu)化改造等操作帶來了困難。在沒有明確強弱依賴關(guān)系的情況下,我們很難有效地進行這些操作
    的頭像 發(fā)表于 02-21 09:49 ?340次閱讀
    穩(wěn)定性建設(shè)之<b class='flag-5'>依賴</b>設(shè)計

    可控硅的控制奧秘:依賴直流還是交流?

    可控硅是一種重要的半導體器件,通過控制極的觸發(fā)信號實現(xiàn)對電流的控制。它可以在直流和交流電路中應用,分別用于開關(guān)、調(diào)節(jié)、調(diào)光等功能。直流控制和交流控制的特點和應用場景有所不同,但都依賴于精確的觸發(fā)電路設(shè)計。通過合理設(shè)計控制電路和保護電路,可以充分發(fā)揮可控硅的性能,實現(xiàn)對電路的精確控制。
    的頭像 發(fā)表于 01-10 15:44 ?1882次閱讀
    可控硅的控制奧秘:<b class='flag-5'>依賴</b>直流還是交流?

    RAID 5 硬件與軟件 RAID 的區(qū)別

    RAID 5硬件RAID與軟件RAID之間存在顯著的差異,這些差異主要體現(xiàn)在實現(xiàn)方式、性能、數(shù)據(jù)安全性、靈活性以及成本等方面。 一、實現(xiàn)方式 硬件RAID : 依賴于專用的硬件RAID控制器來管理
    的頭像 發(fā)表于 12-27 18:05 ?1186次閱讀

    虛擬設(shè)計與優(yōu)化電力電子系統(tǒng)依賴于半導體芯片模型

    方法,該方法結(jié)合了靜態(tài)和動態(tài)表征技術(shù)以及參數(shù)擬合,從而能夠創(chuàng)建高度精確的模型。電力電子技術(shù)幾乎存在于現(xiàn)代生活的各個方面,從消費電子到可再生能源集成和交通。這些系統(tǒng)
    的頭像 發(fā)表于 12-10 11:57 ?599次閱讀
    虛擬設(shè)計與優(yōu)化電力電子系統(tǒng)<b class='flag-5'>依賴于</b>半導體芯片模型

    關(guān)于LRU(Least Recently Used)的邏輯實現(xiàn)

    湊巧看到一個有關(guān)LRU(Least Recently Used)的邏輯實現(xiàn),其采用矩陣方式進行實現(xiàn),看起來頗有意思,但文章中只寫方法不說原理,遂來研究下。LRU(Least Recently
    的頭像 發(fā)表于 11-12 11:47 ?923次閱讀
    關(guān)于<b class='flag-5'>LRU</b>(Least Recently Used)的邏輯實現(xiàn)

    無人機慣導IMU和航姿參考系統(tǒng)

    無人機飛行姿態(tài)的控制是其飛行性能和任務執(zhí)行能力的核心,依賴于精確的傳感器數(shù)據(jù)、高效的控制算法和可靠的執(zhí)行機構(gòu)
    的頭像 發(fā)表于 11-06 17:45 ?1209次閱讀
    無人機慣導IMU和航姿參考系統(tǒng)

    鴻蒙Flutter實戰(zhàn):09-現(xiàn)有Flutter項目支持鴻蒙

    │ ├── printer ├── pubspec.lock ├── pubspec.yaml └── yarn.lock plugins 是依賴于原生平臺的插件, components 是平臺無關(guān)
    發(fā)表于 10-23 16:36

    隧道定位導航技術(shù)主要依賴于哪些原理或技術(shù)

    在交通運輸領(lǐng)域,隧道作為連接不同區(qū)域的重要通道,其內(nèi)部的安全與效率問題一直備受關(guān)注。尤其是在隧道內(nèi),由于山體或建筑物的遮擋,衛(wèi)星信號往往無法直接到達,傳統(tǒng)的GPS等衛(wèi)星導航定位技術(shù)在隧道內(nèi)難以正常工作。因此,隧道定位導航技術(shù)的發(fā)展顯得尤為重要。那么,隧道定位導航技術(shù)主要依賴于哪些原理或技術(shù)呢?
    的頭像 發(fā)表于 08-14 11:04 ?897次閱讀

    聚徽-嵌入式工控機是如何散熱的

    嵌入式工控機散熱主要依賴于以下幾種方式:
    的頭像 發(fā)表于 08-14 09:21 ?624次閱讀

    為什么需要在JTAG LOCK期間實現(xiàn)RAMIN?

    大家好,我想問一下,為什么我們需要在 JTAG LOCK 期間實現(xiàn) RAMIN(內(nèi)存初始化)?
    發(fā)表于 07-24 06:35

    IGBT功率器件的散熱方式

    功率器件的正常運行在很大程度上依賴于散熱。常用的散熱方式有自冷、風冷、水冷和沸騰冷卻四種。
    的頭像 發(fā)表于 07-15 16:31 ?2068次閱讀
    IGBT功率器件的散熱方式

    邊OTG邊充電芯片如何實現(xiàn)充電與數(shù)據(jù)傳輸并行?

    邊OTG邊充電芯片實現(xiàn)充電與數(shù)據(jù)傳輸并行的功能,主要依賴于其內(nèi)部的設(shè)計和與USB Type-C接口標準的結(jié)合。
    的頭像 發(fā)表于 07-14 10:35 ?1332次閱讀