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

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

Kernel topics on the radar

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

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

Memory folios

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

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

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

最終來(lái)看，支持 folio 的力量似乎越來(lái)越強(qiáng)，而 merge 過(guò)程很可能仍將在 5.15 的時(shí)候開(kāi)始。

Retrying task isolation

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

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

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

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

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

User-managed concurrency groups

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

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

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

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

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

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