2026 年 Linux 核心設計課程自我評量

姓名: 邱昱晴 GitHub 帳號: seallllllllll

本份自我評量遵循課程自我評量指引的書寫規範，避免「期許自己」、「已盡最大努力」等空泛承諾，所有產出皆附對應的公開軌跡（GitHub PR、HackMD 開發紀錄、Google Doc 紀錄）。各項自評分數皆為 1 到 10 的整數。

成果發表與貢獻

自評分數：9/10

〈Concurrency Primer〉導讀

• 修正專有名詞的嚴謹度
  1. 將 cpu、Arm 改為大寫 CPU、ARM，專有名詞全大寫
  2. load modfiy store 修改為 load-modify-store
  3. lock free 改成 lock-free

從熱力學第二定律到系統軟體：機率、資訊熵與現代作業系統的大融通

• 空格排版問題：

  1. jitter (抖動)嚴格限定 改為 jitter (抖動) 嚴格限定
  2. 獲得 CPU(反映 CPU 排程器… 改為 獲得 CPU (反映 CPU 排程器…
  3. THP(transparent huge pages) 改為 THP (transparent huge pages)

• 術語不一致（漏字）：

  1. 因而工程上更常看 lag 的 drift 與高分位界… 改為 高分位數（或高分位數界限）。 前文與統計學慣用詞都是用「分位數」(Quantile) 或是「信賴區間」，突然出現「分位界」不易閱讀容易混淆。

• False sharing 的量測鏈與可否證性段落，語意不嚴謹： False sharing 的觸發條件不是變數本身未對齊（Unaligned）。變數本身有可能對齊了它的資料型態（例如一個 4-byte 的整數對齊在 4 的 kernel 邊界），但只要兩個獨立的變數落在同一個 64-Byte 的快取行（Cache Line）內，就會引發 False sharing。所以改成「多執行緒頻繁寫入位於同一個快取行（Cache Line）但邏輯上獨立的變數」。

Linux 核心的 hash table 實作

• 文章寫到：至於 A 為什麼使用 golden ratio，也就是 A = \((\sqrt{5}-1)/2 \approx 0.6180339887...\) 呢？ 黃金比例的值是 \((\sqrt{5}+1)/2 \approx 1.618\)。文章中使用的 \((\sqrt{5}-1)/2 \approx 0.618\) 是黃金比例的倒數（\(\phi^{-1}\)），也被稱為共軛黃金比例（Golden Ratio Conjugate），應該是筆誤，以此更正為 golden ratio 的倒數。

作業與隨堂測驗

自評分數：9/10

HW1 全部完成，HW2 進度約一半，其他兩份作業未完成。14 次隨堂測驗皆有參與及和同學討論，也有筆記記錄檢討。所有開發紀錄公開於 HackMD，並通過資訊科技詞彙翻譯用語檢核。學期初規定自己每天應投入四小時，假日休息，週投入時數平均 20 小時。

隨堂測驗隨老師課堂一起檢討，另外也有完成部分延伸問題的回答：

• 將 Linux 核心的 ___update_load_sum 邏輯移植至 userspace，模擬 naive 與 PELT-like 兩種手法： 證實了不保留碎片會導致顯著的負偏誤（systematic underestimation），並量化了誤差程度，深入解析了 Linux 開發者在效能與精確度之間的工程取捨。

• 在 binary64 環境下構造 \(a, b, c\) 證明浮點數不滿足結合律，並分析 rounding 對應的 G/R/S 位元狀態： 完整推導 naive 與 Kahan 的誤差界（\(O(n\epsilon)\) vs \(O(\epsilon)\)），並分析編譯器最佳化選項（如 -ffast-math 與 -fassociative-math）如何導致 Kahan 補償機制失效。

• abs(INT_MIN) 在二補數系統中為未定義行為（Undefined Behavior）： 硬體運算（~x + 1）的溢位特性，以及 C 語言為了極致效能而採取的措施。

• 推導了 \(avg = avg - (avg \gg w) + (val \ll f)\) 與 EWMA 公式 \(s_t = (1-\alpha)s_{t-1} + \alpha x_t\) 的等價關係。

詳細可以到作業紀錄查看。

期末專題

自評分數：10/10

專題名稱：改進 vwifi 執行人：seallllllllll

vwifi 是一個基於 Linux cfg80211 子系統開發的虛擬無線網路驅動，旨在透過 Linux Network Namespace 隔離技術，模擬 Station (STA) 與 Access Point (AP) 的無線傳輸環境。主要的功能擴充與改進包括：

• 動態速率適應：導入 cfg80211_bitrate_mask，實現基於 MCS、GI 與頻寬的傳輸速率模擬。
• 物理層真實性：基於 Airtime 原理實作封包序列化延遲 (Serialization Delay)，更精準模擬 Wi-Fi 傳輸損耗。
• 可重現測試框架：建立自動化測試腳本，如丟包模擬與速率驗證。

專案內容

Rate Control 與 Bitrate Mask

將原本硬編碼 (Hardcoded) 的 MCS 31/20MHz 資訊移除，改為透過網卡 rate_state 動態讀取。

• 技術實作：建立 HT20 MCS 速率查詢表 (Lookup Table)，支援 Long/Short GI 切換。
• 使用者介面：透過 iw dev <iface> set bitrates ht-mcs-2.4 <index> 指令，即可即時調整虛擬網卡的實體傳輸速率，並同步反映於 station dump 資訊中。

TX/RX 延遲模擬

• 公式推導：\(T_{\mu s} = \lceil \frac{L \times 8 \times 1000}{R} \rceil\)，其中 \(L\) 為封包長度 (Bytes)，\(R\) 為速率 (kbps)。
• 使用 hrtimer (High-Resolution Timer) 取代傳統 timer_list，滿足微秒級的延遲精確度。
• 封包排入 RX Queue 後，會被標記 deliver_at 時間戳，由 Timer 觸發 Workqueue 進行後續處理。
• 除錯工具：新增 tx_delay_scale 模組參數，可放大延遲倍率，利於在 ping 測試中觀察不同 MCS 下的 RTT 變化。

Kernel Panic 除錯

• Use-After-Free 預防：重構 vwifi_free 與 vwifi_delete_interface 的解除安裝路徑，確保先斷開鏈結再釋放資源。
• 死鎖 (Deadlock) 解除：修復 cancel_work_sync 在持有 Mutex 時呼叫引發的問題，確保模組卸載路徑安全。
• Race Condition 防護：針對 vwifi_disconnect_routine 使用 READ_ONCE 與嚴格的鎖機制，防止在 Driver 狀態關閉時產生懸空指標。

測試與驗證

• 驗證 iw 指令設定是否跟 hash table 一致。證實在相同 MCS 下，Short GI 的 Bitrate 顯著高於 Long GI，且 station dump 資訊與預期完全一致。
• 透過 module parameter 動態設定丟包率，模擬惡劣的無線環境。測試發現 Destination Host Unreachable 為常見現象，所以改成先建立 Neighbor Cache 再進行測試，提高測試的穩定性。
• 透過調整 tx_delay_scale，成功在 ping 測試中觀察到 MCS 0、MCS 7 與 MCS 31 帶來的明顯 RTT 差異。

觀摩同儕專題並提問

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

1. Stanley0915 — 雖然關閉 CONFIG_PRINTK_NBCON 成功省下了約 9.7 KB 的空間，但這會失去哪些潛在的保障？特別是在單核心 noMMU 環境下，退回依賴全域鎖的舊機制。
2. ga13234624 — 我在 vwifi 實作時有遇到 vwifi_disconnect_routine 寫法問題，會引發 use-after-free、race condition 等問題，導致 rmmod 時的 kernel panic。但在專案修復這邊沒有看到，想知道 rmmod 時有沒有遇到類似的事？如果有是如何解決的？
3. kezhenx666 — Firefox 會因為 WebRTC 傳送空的 ICE Candidate ("") 導致連線解析失敗，這是已知限制嗎？可以到 Android Open Source Project 的 Issue Tracker 搜尋或回報這個發現
4. Patriciaath999 — 你提到 Bonobo 的 v12_never（有 pool、無 THP）對 TLB 有微幅貢獻，而果蠅（dm6）與人類（human）則無，是因為跨物種 anchor 分佈差異。為什麼跨物種的 sequence alignment 會導致 anchor 密度或分佈不同？
5. ArBin1020 — 可以推測為什麼理論上的 FPR 改善，沒有轉換成實際的系統收益嗎？可能效能瓶頸在於其他地方，而不是在 Bloom filter 的 false positive？

同儕提問回覆

7 月 8 日中午前已回覆全部提問 (公開於 HackMD 留言串)，詳請可見改進 vwifi。

與授課教師的互動

自評分數：8/10

1. 與老師信件往來討論期末專案，並更正自己面對期末專案的態度。
2. 線上一對一面談（2026/05/25）中，老師要求在不使用標準數學函式庫（<math.h>）且必須避免整數乘法溢位的前提下，實作一個計算整數陣列「幾何平均數（Geometric Mean）」的函式。面談完後有深度思考過，思路以及想出來的策略已經記錄於 google doc 中。
3. 討論期末專案的內容，學習遇到 kernel panic 該如何解決。專案本身的問題出在 rmmod 身上，那要如何 trace code 來找到問題點？應當先了解移除模組的整個運作流程，方能往上追溯。追溯也有技巧，透過切換不吧同的 github commit 比較好找問題點（看 code 何時出現錯誤）。這些都是平常自己做學不到的寶貴經驗，也因為老師的指點我才能順利解決 kernel panic。
4. 在課堂問答中參與模擬面試（2026/06/02），回去過後回放錄音並閱讀相關的文章以及自己過去寫的筆記，來思考回答的正確性與邏輯順序，另外也發現自己也有講話太慢（思考太久）的問題。

所見所聞所感

自評分數：10/10

看完〈因為自動飲料機而延畢的那一年〉，其實第一個想法是覺得這位前輩很有勇氣。延畢在大家的眼裡是多嚴重、可能一輩子沒辦法洗白的事，但其實重點是你是「為了什麼」而延畢。人生沒什麼正確答案，但大家都依照著社會期待在走。面對一件「沒有標準答案」的事，要怎麼去完成它？

文章開頭的等價交換原則我很喜歡，也是我在修老師上學期的計算機結構一直提醒自己的事，你想要得到什麼你就應該付出多少，沒有付出何來的成果？沒有付出怎麼會覺得自己可以勝任一切？作者付出了金錢、時間、延畢這件事，並埋首苦幹，不停的 try and error 來做出他的自動飲料機。現在的我付出了什麼？

在作者的 try and error 之中我想到了每個作業、專案老師要求的細節、從推導的數學、口頭表達中的用詞，甚至是態度。在改掉之前的習慣，開始重視上述看似不那麼重要、不那麼「技術性」的事後，我覺得整個效率更高更好、方向更明確。俗話說魔鬼藏在細節裡，去重視細節，就好比蓋房子用好的材料，即使蓋到 101 層依舊穩固，不重視細節，蓋出來的也只是海砂屋罷了。

分數計算

幾何平均 (GEOMEAN) 計算：

\(\text{GEOMEAN} = \sqrt[5]{9 \times 9 \times 10 \times 8 \times 10} = \sqrt[5]{68400} = 9.168\)

方案 B：\(1+9=10\) 自我評量總分：10 / 10