RSEQ 效能重構意外打壞 TCMalloc:Linux 核心團隊如何在效能與相容間找平衡
Linux Kernel Mailing List · 2026-04-22
2026年4月22日,MongoDB 工程師 Mathias Stearn 在 Linux 核心郵件論壇(LKML)發出回歸回報「[REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere」。Linux 6.19 對 restartable sequences(rseq)機制的效能重構,同時打壞了 ARM64 的正確性保證與 Google TCMalloc 的假設,演變成核心「不可回歸」原則與 Hyrum's Law 的正面衝突。
背景:rseq 如何讓使用者空間跑「不可搶占」的臨界區
Restartable sequences 透過 rseq() 系統呼叫運作:執行緒向核心註冊一塊 struct rseq 記憶體,記錄所在 CPU 編號與一個 abort handler 位址。使用者空間可據此寫出短小臨界區,一旦核心偵測到該執行緒在區內被搶占或搬移到別顆 CPU,就把程式計數器導向 abort handler,讓程式重新開始。這個機制讓每執行緒的 per-CPU 資料結構不必依賴昂貴的原子操作就能維持一致性,TCMalloc 的 per-CPU 快取正是靠它避免跨執行緒搶鎖。
核心改動:6.19 拿掉了「多餘」的寫入
Linux 6.19 合入的 39a167560a61(「rseq: Optimize event setting」)與 566d8015f7ee(「rseq: Avoid CPU/MM CID updates when no event pending」),把每次排程事件都無條件更新 rseq_cs、cpu_id_start 的舊作法,改成只在判定「有事件待處理」時才寫入,官方量測顯示多種工作負載因此有約15% 的效能提升。問題是 ARM64 在同核心搶占時不會像 x86 一樣設定 TIF_NOTIFY_RESUME,導致核心誤判沒有事件、放棄中止本應中止的臨界區,直接違反 rseq 文件承諾的原子性保證。TCMalloc 則長期依賴 cpu_id_start 在臨界區外也被無條件更新來偵測搬遷,寫入一旦被省略,per-CPU 快取的一致性假設隨即失效,實測會在 percpu_tcmalloc.h:852 產生「CHECK in Pop: next (false)」斷言並直接中止程序。
影響範圍:一場關於「誰該讓步」的爭論
Google 工程師稍早已在 google/tcmalloc 的 issue #292 記錄類似當機,關閉 glibc 內建 rseq(GLIBC_TUNABLES=glibc.pthread.rseq=0)可穩定重現。Peter Zijlstra 一度反駁,指 TCMalloc 依賴的是文件未承諾、且會被 DEBUG_RSEQ 標示為錯誤的行為,Google 早知情卻未修正;但 Mark Rutland 也承認 ARM64 的搶占判斷本身是獨立正確性錯誤,必須修。Thomas Gleixner 的修法是拆分核心進入路徑:把 arm64_enter_from_user_mode_syscall() 獨立出來,只在中斷(IRQ)路徑補上 rseq_note_user_irq_entry(),避免系統呼叫路徑增加負擔。
librseq 維護者 Mathieu Desnoyers 同步把文件修正為「可能被設為 NULL」,而非保證清除。Olivier Dion 則提出「Optimized RSEQ V2」ABI 擴充方案:以更大的 struct rseq 註冊尺寸讓程式協商加入新語意,舊有 glibc/TCMalloc 註冊維持無條件更新的相容路徑,兩種效能取捨得以並存。
Asahi Linux 正式收編 M3 系列 Mac,GPU 加速仍是最後一塊拼圖
Asahi Linux Blog · 2026-09-06
2026年9月6日,Asahi Linux 開發者 James Calligeros 在官方部落格宣布,M3 系列 Mac 的支援已併入官方安裝程式,搭載 M3、M3 Pro、M3 Max 的 MacBook 與 iMac 從此可透過標準流程安裝 Linux,唯獨 Mac Studio 用的 M3 Ultra 仍未支援。目前 M1/M2 上大部分能用的功能都已移植過來,但 GPU 加速與完整的顯示控制器(DCP)支援仍付之闕如。
背景:一群志工如何在沒有官方文件下逆向 Apple Silicon
Asahi Linux 是一個純靠社群逆向工程、把 Linux 移植到 Apple Silicon Mac 上的計畫,蘋果並未提供任何官方晶片文件。GPU 驅動堆疊的拆解由固定幾位開發者分工完成:Alyssa Rosenzweig 撰寫 OpenGL 驅動與編譯器,Asahi Lina 撰寫核心驅動並協助 OpenGL 開發,Dougall Johnson 負責逆向指令集,Ella Stanforth 則在既有核心驅動與編譯器基礎上開發 Vulkan 支援。蘋果的 AGX GPU 是源自 PowerVR 架構的分塊渲染器(tiler),核心驅動走 Linux 的 DRM 子系統,使用者空間驅動則以 Gallium3D 介面實作在 Mesa 裡,這套驅動在 M1/M2 上已通過 Khronos 的 OpenGL ES 3.1 一致性認證。
核心改動:M3 現在能開機做什麼
依 AsahiLinux/docs 專案的功能支援矩陣,此次涵蓋 T8122(M3)、T6030(M3 Pro)、T6031/T6034(M3 Max)三種晶片,T6032(M3 Ultra)欄位仍標示「待定」。已可用的功能包括視訊鏡頭、內建麥克風、USB 3(上限 10 Gb/s)、含 AV1 的硬體加速影片解碼、WiFi 與藍牙,而NVMe、PCIe、SPI 等儲存與匯流排功能也已達到穩定可用,cpufreq、cpuidle 與待機睡眠等電源管理功能同樣可用。這些功能鎖定的核心版本是 linux-asahi 7.2~7.3,更完整的驅動修補預計要等到 7.4 之後才會落地。
影響範圍:GPU 與 DCP 仍卡住,睡眠與 HDMI 因此受限
功能矩陣把 GPU 與 DCP 在 M3、M3 Pro、M3 Max 上都標為「WIP」,M3 Ultra 則同樣是「待定」。部落格明白警告「現階段不要期待有效能或省電的 3D 加速」,由於顯示控制器尚未完整支援,搭載 HDMI 的 MacBook 機型該連接埠會被停用,系統睡眠功能也因為韌體 framebuffer 的限制而暫時關閉。目前這條安裝路徑仍藏在 Expert 模式底下才看得到,團隊表示 GPU 相關進度會在「未來幾個月」公布,並提到將在 freedesktop.org 的場合上做進一步簡報。
Rust 除錯調查出爐:近半使用者從沒開過偵錯器,型別呈現是最大痛點
Rust Blog(Compiler Team) · 2026-09-07
2026年9月7日,Rust 編譯器團隊(Compiler Team)在官方部落格公布首次大規模「Rust 除錯調查」結果。這份調查於 2026 年 2 月發出,回收超過2,300 份回覆,交出一份罕見以具體數字量化 Rust 除錯體驗現況的報告。
背景:為什麼要做這份調查
受訪者中有超過八成自評為「進階」或「中階」Rust 使用者,樣本理論上偏向已經熟悉工具鏈的族群。即使如此,目前正在使用偵錯器的比例只有 46%,代表過半受訪者根本不用偵錯器;在自評新手的族群裡,這個「從未用過偵錯器」的比例更接近五成。調查也問到棄用 Rust 的原因:約 3% 的前 Rust 使用者表示除錯體驗差是他們停用的直接原因,另外還有 24% 表示這是部分原因。
核心改動:數字說了什麼
在工具選擇上,IDE 內建的 LLDB 是使用率最高的傳統偵錯器,命令列 GDB 居次,但平台差異明顯:Linux 使用者偏好命令列 GDB,佔比在 45% 到 77% 之間視情境而定,macOS 與 Windows 使用者則多半用 IDE 內的 LLDB。偵錯器的實際用途中,87% 用於逐行單步執行,51% 用來取得當機或卡住行程的堆疊回溯,只有 25% 會拿來除錯非同步(async)程式碼,44% 的受訪者需要同時除錯 Rust 與其他語言混合的程式(其中 C 佔 70%、C++ 佔 43%、Python 佔 20%)。
不使用偵錯器的最大原因是效率考量:81% 認為日誌或 print 除錯更快更簡單,37% 表示自己寫的程式碼通常不需要偵錯就能動,其餘則指向偵錯器對特定語言特性、標準函式庫型別或外部函式庫型別支援不足。在願意單步執行的受訪者裡,超過五成回報遇過問題,其中非同步程式碼佔 28% 最常見,巨集(macro)展開佔 23%,函式指標僅占 6% 最少見。而所有痛點裡最普遍的是「數值呈現太差」,高達 74% 的受訪者提到這一點,55% 表示根本印不出變數內容,尤其在 enum、HashMap、Vec 與字串型別上特別嚴重。
影響範圍:debugger_visualizer 屬性乏人問津
Rust 早已提供 debugger_visualizer 屬性,可以內嵌 Natvis(給微軟系偵錯器)或 GDB pretty-printer 腳本來改善數值顯示,但調查發現 62% 的函式庫作者根本不知道有這個屬性存在。在知道卻沒採用的作者裡,約半數表示沒有時間維護,另外約半數表示不知道該怎麼寫 visualizer 腳本。報告據此列出後續優先改善方向:更好的 enum 變體顯示、能看到實際內容的集合型別呈現、把字串型別顯示成可讀文字、加強非同步程式碼(尤其是堆疊回溯)的除錯支援,以及改善在迭代器與 Future 狀態機之間單步執行的體驗。文章也提到目前有一個 Google Summer of Code 專案,正在改善除錯資訊測試與 visualizer 腳本相容性,呼應調查發現的缺口。