LWN：最近在關(guān)注的kernel改動！

關(guān)注了就能看到更多這么棒的文章哦～

Kernel topics on the radar

By Jonathan Corbet
August 2, 2021
DeepL assisted translation
https://lwn.net/Articles/864603/

內(nèi)核開發(fā)社區(qū)非常繁忙，每天都有成千上萬的電子郵件飛來飛去，每個時刻都有許多不同的開發(fā)任務(wù)在進行中。這些工作中大部分最終都會引出 LWN 的相關(guān)文章，但我們沒有辦法涵蓋所有的工作，甚至沒有辦法涵蓋全部那些有趣的工作。下面是我們的第一次嘗試，希望也可以成為后續(xù)我們定期的專題：快速過一下目前編者正在跟蹤的那些工作，不過不確定它們后續(xù)會不會變成一篇完整文章的主題。第一組的主題包括 memory folios 、task isolation 、以及谷歌的 lightweight threading framework。

Memory folios

三月份的時候已經(jīng)在 LWN 介紹過了 memory folios 。Matthew Wilcox 的這組 patch 增加了 "foio" 的概念，即其確保了不會成為一個 compound page 中的 tail page。也就是 folio page 可以保證要么是一個獨立的（singleton）page ，要么是一個 compound page 的開頭部分，它也創(chuàng)建了一個 API 來給內(nèi)存管理功能新定義了一些有用的 structure，節(jié)省了一些內(nèi)存空間，并且稍微提高一些場景下的性能表現(xiàn)。

雖然內(nèi)存管理社區(qū)仍然沒有完全接受這個概念（一些開發(fā)者認為這個改動很大但好處卻很小），但看起來這組 patch 似乎越來越可能在不久的將來被合并進來?；蛘撸辽贂_始走 merge 流程。人們不會一下子合入所有 138 個 patch（這是最后一次統(tǒng)計的數(shù)字）的內(nèi)存管理 patch set。在 7 月中旬的時候 Wilcox 提出了他的計劃，也就是在 5.15 中合并前 89 個 patch ，而其余的 patch 將在接下來的兩個開發(fā)周期內(nèi)得到合入。目前似乎沒有人對這個時間表提出異議。

不過在 7 月下旬，Wilcox 偶然發(fā)現(xiàn)了一篇他命中注定會讀到的 Phoronix benchmarking 的文章，該文章顯示在內(nèi)核中應(yīng)用了 folio 補丁后，PostgreSQL 的性能提高了 80%。他說這個結(jié)果是 "看起來很令人鼓舞（plausibly real）"，并且提出是不是應(yīng)該加速合并這些 folio 相關(guān)的 patch。但其他開發(fā)者的反應(yīng)則是表示懷疑。PostgreSQL 的開發(fā)者 Andres Freund 研究了一下這個結(jié)果是如何出現(xiàn)的，并得出結(jié)論說這個測試 "歸根結(jié)底并沒有測量出什么特別有趣的結(jié)果"。他自己的測試得到了 7% 的提高，不過（正如他所指出的）這仍然是一個不錯的改進了。

最終來看，支持 folio 的力量似乎越來越強，而 merge 過程很可能仍將在 5.15 的時候開始。

Retrying task isolation

去年，開發(fā)社區(qū)曾經(jīng)討論過 task-isolation mode，也就是允許那些對 latency 很敏感的應(yīng)用程序在沒有內(nèi)核干擾的情況下得以在 CPU 上運行。這項工作最終沒有被 merge，但人們顯然仍然對這種模式很感興趣，從 Marcelo Tosatti 的 patch set 就可以看出這一點。它采取了一種更簡單的方法來解決這個問題，至少起初的時候是這樣的。

這個 patch 著重關(guān)注的是，哪怕 CPU 在 "nohz" 模式下運行時不會有定期的 clock tick，也仍然會產(chǎn)生內(nèi)核中斷，因此會引出麻煩。具體而言，他正在研究 "vmstat" 代碼，這部分代碼是為內(nèi)存管理子系統(tǒng)執(zhí)行清理工作的。其中一些工作是在一個單獨的線程中完成的（通過一個工作隊列來運行），當(dāng) CPU 運行在 nohz 模式下時，該線程通常會被禁用。不過，有些情況會導(dǎo)致這個線程在 nohz CPU 上被重新 reschedule 得以運行，從而導(dǎo)致原來的應(yīng)用程序無法再獨占該處理器。

Tosatti 的 patch set 增加了一組新的 prctl() 命令來解決這個問題。PR_ISOL_SET 這個命令會設(shè)置 "isolation parameters"，這個參數(shù)可以是 PR_ISOL_MODE_NONE 或 PR_ISOL_MODE_NORMAL。后者要求內(nèi)核避免發(fā)生中斷。但這些參數(shù)一直要等到 task 真正進入了 isolation 模式才會開始生效，這是通過 PR_ISOL_ENTER 命令來完成的。內(nèi)核看到需要進入 isolation 模式的時候，就會立即執(zhí)行之前推遲的所有 vmstat 工作，這樣內(nèi)核就不會在以后不方便清理的時候再做這個工作了。在 isolation mode 中，任何一次系統(tǒng)調(diào)用結(jié)束的時候都會觸發(fā)這個 deferred-work 要完成的 cleanup 動作。因為這些系統(tǒng)調(diào)用很可能總會觸發(fā)一些 delayed work，這樣在應(yīng)用程序代碼運行時情況不會被弄得更加混亂。

這個改動的意圖明顯是希望使這類功能更加普遍適用，也就是保證任何一個 delayed work 都要得以立即執(zhí)行。這導(dǎo)致其他人（包括 Nicolás Sáenz）的質(zhì)疑，認為這種采用單一的 mode 來控制那些各種不同的內(nèi)核操作是不對的。他說，將各種行為分割開來，后續(xù)就可以將一些決策動作轉(zhuǎn)移到用戶空間。經(jīng)過反反復(fù)復(fù)的討論，Tosatti 同意修改接口，讓用戶空間可以明確控制每個可能會用到的 isolation 功能。實現(xiàn)該 API 的一個 patch set 已于 7 月 30 日發(fā)布出來，它增加了一個新的操作（PR_ISOL_FEAT），用于查詢 isolation 模式激活時可以被靜默掉的那些 action。

順便說一下：我們社區(qū)的新成員可能不知道，20 年前，Tosatti 被人們稱為神奇企鵝馬塞洛（Marcelo the Wonder Penguin）。

User-managed concurrency groups

今年 5 月的時候，Peter Oskolkov 發(fā)布了一組 patch 實現(xiàn)了名為 "user-managed concurrency group" （UMCG) 的機制。這個工作顯然是被稱為 "Google Fibers" 的 scheduling framework 的一個實現(xiàn)，這自然是可以想象到的最不符合 Google 風(fēng)格的名字（反諷一下）。這組 patch 起初沒有解釋清楚它究竟希望實現(xiàn)什么功能，但隨著時間的推移，大家越來越清楚這個情況了。

UMCG，旨在成為一個輕量級的、由用戶空間控制的 M:N 線程機制。經(jīng)過人們的一些催促后發(fā)布了一個文檔，描述了其核心理念。一個用戶空間的進程可以設(shè)置一個或多個并發(fā)組（concurrency group）來管理它的工作。在每個組中，都會有一個或多個 "server" 線程。他的計劃似乎是讓應(yīng)用程序針對每個可用的 CPU 都設(shè)置一個 server 線程。同時還會有不確定數(shù)量的 "worker" 線程，用來執(zhí)行應(yīng)用程序需要完成的工作。在任一時刻，每個 server 線程都可以執(zhí)行一個 worker。用戶空間可以隨時控制哪些 worker 線程得以運行，具體的方法就是將它們 attach 到 server 上。各種事件（比如 worker 被阻塞在 I/O 上了）的通知處理可以讓 server 線程保持忙碌。

在 8 月 1 日版本的 patch set 中，定義了兩個系統(tǒng)調(diào)用來管理這個機制。調(diào)用 umcg_ctl() 就會把一個線程注冊為 UMCG task，可以是 server mode，也可以是 worker mode。它還可以進行 unregistration 動作。umcg_wait() 則是主要的調(diào)度機制。例如，worker 線程可以用這個 API 來暫停執(zhí)行。但 server 線程也可以使用 umcg_wait() 來喚醒一個特定的 worker 線程，或者強制從一個 worker 線程切換到另一個 worker 線程。只要 worker 線程繼續(xù)運行，該調(diào)用通常就會一直保持阻塞狀態(tài)。一旦 umcg_wait() 返回，server 線程就可以選擇一個新的 worker 來執(zhí)行了。

至少看起來是這么回事。幾乎沒有關(guān)于這些系統(tǒng)調(diào)用真正會如何被使用的文檔，也根本沒有示例代碼。這組 patch 的最新版本終于包括了一些對系統(tǒng)調(diào)用的介紹，此前的版本中完全沒有。也許正是這個原因，這項工作到目前為止收到的 review 相對較少。Oskolkov 似乎更專注于內(nèi)核內(nèi)的功能的具體實現(xiàn)，但 review 人員會希望能先對用戶空間要用的 API 進行較長時間的仔細研究，因為如果這個 API 被合入的話就必須永遠都得到支持。UMCG 看起來很有趣，而且可能會很有用，但是這種對 core-kernel 部分的改動，最起碼來說也是很難得到 merge 的。到目前為止，由于缺乏對其用法的詳細介紹，要想 merge 這組 patch 就會更加困難。

全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。

長按下面二維碼關(guān)注，關(guān)注 LWN 深度文章以及開源社區(qū)的各種新近言論～