分享到plurk 分享到twitter 分享到facebook

c8763yee (徐彥翔)

簡介

2026 Linux 核心設計 春季班 自我評量

本份自我評量遵循 課程自我評量指引 的書寫規範，避免「期許自己」、「已盡最大努力」等空泛承諾，所有產出皆附對應的公開軌跡 (Linux 上游 patch、GitHub PR、HackMD 開發紀錄、會議錄影)。各項自評分數皆為 1 到 10 的整數，最末以幾何平均計算總分並適用方案 B。

成果發表與貢獻

9 分

以下貢獻採計區間為 2 月 23 日到 7 月 8 日。以相關貢獻被合併或公開演講審稿通過的當下時間為準。

Kernel patch (Trivial)

我在閱讀 AMD IBS 相關程式碼時發現其在 arch/x86/include/asm/amd/ibs.h:80 中 bit-field 註解中 bit 範圍標示錯誤 (正確的範圍應該是 16-31)，考慮到可能有開發者被註解誤導 bit-field 範圍，因此「路見不平，拿 Patch 來補」，發送了第一個 Linux kernel patch。

該 Patch 於 2026/03/06 合併入 tip tree 中的 perf/core 分支，並在 2026/04/14 於 7.1 的 Merge window 中合併入主線

教材修改

公開演講

作業與隨堂測驗

作業

在進行探討〈解讀計算機編碼〉題組時實際推導出溢位後對於群性質的影響

在進行〈分析「快慢指標」〉題組時使用數學分析對鏈結串列分別使用 Merge sort 與 Fisher-Yates shuffle 進行隨機排序時的時間複雜度 Average/Worst case。

隨堂測驗

  • 第 1 週：34 / 100
  • 第 3 週：41 / 138
  • 第 4 週：49 / 133
  • 第 5 週：16 / 117
  • 第 6 週：70 / 102
  • 第 7 週：105 / 112
  • 第 8 週：68 / 116
  • 第 10 週：102 / 105
  • 第 13 週：84 / 105
  • 第 15 週：96 / 108

課程初期由於可以上網查資料與本地撰寫執行程式，因此做題目時偏向直接從對應 Linux 核心程式碼與撰寫 Python 程式計算，導致的結果就是來不及做完全部題目。不過在課程期間由於對 C 語言（主要是 C99 與 C11）規格的重視，在後續進行測試時遇到類似的題目也能直覺想到對應的知識點並進行作答，使得後續測驗成績逐漸提昇。

期末專題

5 分

未完成期末專題，並且由於無法說明 MGLRU 本身對 Linux 核心於個人電腦的改善，因此未登記於課程期末專題。

題目：針對 MGLRU 的 refault feedback loop 統計 (PID Controller) 根據 Generation 存活時間衰減歷史權重。

本題目對應 Yu Zhao 在 [PATCH mm-unstable v15 06/14] mm: multi-gen LRU: minimal implementation 中 refault feedback loop 部份程式提到的 Future optimizations(vmscan.c:3144-3146)

\[S_{new} = \frac{S_{old}}{\Delta t}+\frac{\Delta t-1}{\Delta t}x_t\] \(\Delta t = \text{jiffies}-lrugen_{ts}[Gen_{min}]\)

開發紀錄：GitHub

在進行期末專題時我發現我會時常把問題與架構想得太複雜，導致後續花費過多時間在處理 Userspace 模擬 MGLRU 架構本身以及觀察 MGLRU 相較於 Active/Inactive list 的具體改善指標。

尚未釐清的是：我無法區分 Yu Zhao 當初設計 Refault feedback loop 時省略 D term 是否基於雜訊考量的刻意設計，且上述推測在 MGLRU 對應檔案的 commit message 與 LKML 討論中均無明文佐證。

觀摩同儕專題並提問 (公開軌跡，共 5 件 \(\ge\) 課程要求 5 件)

本年度同儕專題索引於 linux2026-projects, 留下提問軌跡如下:

  1. keep90ing：〈Linux 核心設計專題: SLUB_TINY 分析和改進〉 詢問其「混合尺寸配置工作負載」實驗中的工作負載大小與權重之選擇考量
  2. ascodeasice：〈Linux 核心設計專題: RISC-V 平台驗證和改進〉 詢問其具體關閉的 Kernel config 與關閉後具體減少 Kernel image 空間
  3. PinkNekoFist：〈Linux 核心設計專題: DRM 研究〉 詢問其 User space (Mesa) 與 Kernel space (DRM) 的溝通方式
  4. patata0717：〈Linux 核心設計專題: MDP-based memory tiering〉 詢問 phase_switch workload 在 mdp policy 上的 NUMA distance, CPU locality 與 remote page ratio 的數據問題
  5. Arbin1020：〈Linux 核心設計專題: MGLRU 的數學分析和改進〉 詢問 hash2 (splitmix64) 帶來的分類品質改善並沒有反應到 Throughput 的原因，並提醒實驗圖片連結失效

與授課教師的互動

7 分

一對一討論共 2 次、課堂問答（進行議題後續追蹤） 2 次、課後討論 2 次，根據日期排序。

課堂問答軌跡

課後討論

  • 2026/03/03：課後向授課教師詢問上述 Kernel patch 提交與合併流程的疑問
  • 2026/04/21：課後向授課教師詢問 COSCUP 與期末專題的題目選擇

一對一討論

具體紀錄請參考 2026 Linux 核心設計行事曆 中標記 一對一討論：c8763yee 的活動

  • 2026/04/27：第一次一對一討論：詢問期末專題題目方向

在本次一對一討論結束後進行模擬面試，題目為如何使用位元運算來實作浮點數除二。當時由於對 IEEE 754 格式的過度思考如何處理 Infinity 與 NaN 導致在實作與說明思路時無法準確說明，甚至把 exponent 的位數說成 10 位。不過在模擬面試期間提出思路與授課教師討論時也逐漸確定實作方式與特殊狀況處理。最後使用 memcpy 複製成 int32_t 後拆分 mantissa、exponent 與 sign，使用 if 檢查 exponent 在減一後是否會出現 underflow 來決定是要回傳 0 給 caller 處理還是繼續進行除二並重新拼裝回 float。

// exponent check 
if (exponent == 0){ 
// 0 - 1 = 11111111
    return 0; // INFINITY or NAN
} 
// normal case
i = ((exponent - 1) << 23) |( i >> 31)<<31 | (i&((1<<23)-1));

會後被要求將針對 Infinity/NaN 的 special case 檢查去除，與改用避免 UB/IB 的 union 實作來取代當下使用的 memcpy (Follow up 紀錄)。

  • 2026/05/15：第二次一對一討論：回報期末專題相關研究發現

所見所聞所感

9 分

〈因為自動飲料機而延畢的那一年〉 心得：

為什麼會出問題呢？因為這裡是他媽的真實世界啊。 大多數人一直活在本來就應該這樣嗎的童話世界裡，電視打開就可以看，機車買來就可以騎，手機買來就可以用，一切都理所當然，本來就應該這樣。偶爾買到不好用的商品我們就抱怨幾句，丟掉換其他更好用的牌子，卻很少意識到那個「本來就該這樣」，背後需要經過多少人月的投入與研發。

讀到這一段時讓我想到當初選擇針對 MGLRU refault feedback loop 進行期末專題時也是想得很簡單，當初認為只要將兩個 Generation 的統計數值取差值後應用進這個 PID Controller 作為 D 項就可以提昇 MGLRU 在記憶體壓力剛開始出現時的反應速度，然後在數學分析時才發現除了需要考慮兩個 Generation 統計差值要怎麼取之外，還需要考慮獲取到差值後要怎麼應用至 MGLRU 架構中。甚至到現在我還沒有想到這個修改具體適用的 Workload 以及對於其他 Workload 是否出現 Regression。

關於數學與謹慎用詞

一開始因為就學期間忽略數學的重要性，導致光是在進行作業一的「探討〈解讀計算機編碼〉」題組時在補充缺失的數論知識就花了 3 天，因此導致後面只能針對程式語言的題目進行作答，同時持續補充之前沒學好的數學知識。這樣的結果是在第三次作業時只能先紀錄閱讀教材時的發現與問題。

不過也是在進行作業撰寫時開始注重詞彙的使用，帶來的影響是在撰寫文章時，針對文章中可能有岐義的漢語用詞主動查詢資訊科技詞彙翻譯與使用 zhtw-mcp 檢查資訊科技詞彙翻譯中未提到的部份用語。因此意外發現不明使用者使用 AI 「抄襲」 zhtw-mcp GitHub repo 這件事並沒有那麼簡單，該使用者還在 repo 中放入病毒檔案並在 README.md 引導下載。 (FYI：Hexastrike 對於類似案例中攻擊行為的分析)。

關於與上游開發者互動

第一次送出 LKML patch 時，Borislav Petkov (maintainer of X86 ARCHITECTURE (32-BIT AND 64-BIT)) 直接退回 Commit 並指出 Commit 訊息可以簡化。在修正 Commit 訊息後發布 v2 patch。不過後續即杳無音訊。在第二周課後向授課教師詢問相關問題時得知 maintainer 對於這種 trivial patch「相對」不會太重視，並告知我可以向邱冠維 (maintainer of MIN HEAP) 寄信詢問相關的問題。

This just fixes the misleading comment. No functional changes.

s/This just fixes/Fix/

寄信向邱冠維詢問後，剛好 Peter Zijlstra (maintainer of PERFORMANCE EVENTS SUBSYSTEM) 在回信前合併了這個 Patch。後續收到邱冠維的回信，並被告知下次 v2 patch 不要回覆在上一個版本。

關於自身投入的回顧

課程初期在閱讀課程教材時間為每週 21 小時，後面由於進行期末專題與處理研究所事物，每週閱讀教材時間降至每週 10 小時。 在閱讀課程教材時發現語法、連結失效等錯誤時想到作者自己可以修改錯誤但沒做，那為什麼不能我來改？於是著手修改。 即使只能修改 Typo 或是用語錯誤，無法作到像是整理並補充〈Linux 核心設計：記憶體管理〉的 Reverse mapping 部份的程度，但畢竟「勿以善小而不為」。

分數計算

項次 名稱 分數
1 成果發表與貢獻 9
2 作業與隨堂測驗 7
3 期末專題 5
4 與授課教師的互動 7
5 所見所聞所感 9
  • 幾何平均 (GEOMEAN) 計算

\[ GEOMEAN \ = \sqrt[5]{9 \times 7 \times 5 \times 7 \times 9} \ = 7.236527563504052 \]

驗算: \(| 7.236527563504052^5-(9 \times 7 \times 5 \times 7 \times 9)| \ll 1\)，符合定義。

方案選擇:

  • 方案 B: 1 + floor(GEOMEAN)

  • 1 + floor(7.236527563504052) = 1 + 7 = 8

自我評量總分: 8 / 10