簡介

• 資訊工程學系 115 級(2021~2025)

• Github:Andrewtangtang

• Hackmd:Andrewyuntang

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

成果發表和貢獻

我曾參與教材內容的修訂，將 I/O 模型演化：Linux 的 io_uring 一文中的「排程小節」修改為「排程小結」。此外，我也主動向老師提出，是否應將「上下文切換」調整為「context switch」。雖然老師基於教材整體語言風格的考量，認為無需更動，只要能清楚傳達意思讓讀者理解內容即可，但這次討論讓我深刻體會到：在撰寫技術內容時，不僅需重視正確性，也要對用詞細節抱持高度的敏感與要求。 由於我參與的修改範圍主要集中於文字與措辭的微調，因此我給自己這部分 6 分。

作業／隨堂測驗

• Homework (lab0)

  • 學習 Linux 核心風格的 List 實作方式。Linux 將 list 結構嵌入其他資料結構中，搭配 list.h 所提供的 macro，可實現鏈結串列操作，並透過 container_of 取得原始結構體，這對我後續理解核心架構有很大幫助。
  • 閱讀論文〈Dude, is my code constant time?〉後，學會如何判斷程式是否具備 constant-time 特性，並實作 dudect 工具來以統計方式分析程式碼執行時間是否與輸入無關，以抵抗時序攻擊。
  • 理解 commit message 應說明 what 、why 與 how，這讓我寫程式時更注重版本控制與說明能力。

• Homework2 (quiz1+2)

• Homework3 (kxo)

  • 學習 Linux 核心中的中斷處理機制，了解 softirq、tasklet 與 workqueue 的差異與用途。
  • 使用 setjmp 和 longjmp 實作 coroutine，體會有效利用 user-level thread 可在輕量級的任務場景中有效降低切換開銷。
  • 利用 ftrace 追蹤函式呼叫，測量核心與使用者空間間的通訊成本，加深我對核心系統開銷的理解。

• Homework5 (assessment)

  • 記錄我在閱讀教材〈Demystifying the Linux CPU Scheduler〉過程中的思考與問題。
  • 撰寫〈自動販賣機而延畢的那一年〉的觀後心得，深刻體會到統計邏輯與對細節的重視，在軟體開發與創業思維中同樣重要。

綜合上述內容，我認為這些作業確實幫助我深入理解 Linux 核心的重要機制，並養成更扎實的技術寫作與實作習慣。因此，我給自己這一部分 8 分。

期末專題

Linux 核心專題：Redis/Valkey + io_uring 我的期末專題聚焦於理解 Linux 所提供的 asynchronous I/O 機制 io_uring，並探討其在真實應用中的效能表現。我不僅研究 io_uring 的基本原理與系統呼叫設計，也深入探索其進階功能，例如開啟 IOPOLL 模式（透過 Completion Queue 輪詢減少中斷延遲），並與傳統的 mmap 系統呼叫在 1BRC 大量資料處理場景中進行效能比較。我也重現了 Anolis OS 團隊先前針對 Redis 將 epoll 替換為 io_uring 的研究，分析其在真實伺服器負載下的延遲與吞吐效能差異。過程中我學習使用 perf 和 strace 等工具觀察系統事件（如 syscall 數量、page fault、context switch），並從這些系統層級指標中解讀實驗結果。

我認為我可以給自己這部分 10 分：

• 5 分在於我成功重現先前研究，讓同學能更具體理解 io_uring 在應用層的實際優勢
• 另外 5 分在於我對實驗中各項效能指標的觀察與分析，讓我具備以系統軟體的角度來解讀效能差異的能力，也提升了我對 kernel behavior 的掌握度。

與授課教師的互動

一對一討論

• 5/12：與授課老師討論課業上遇到的問題，詳細紀錄於 Homework5 (assessment)。當時我向老師提問：vruntime 是否可能發生 overflow？老師則反問我：「為什麼 CFS（Completely Fair Scheduler）總是挑選 vruntime 最小的任務執行？」這讓我體認到，在探討一個問題前，應先釐清該機制設計的初衷與原理，唯有掌握動機與架構，才能進一步深入思考潛在風險與隱患。

• 6/10：與老師討論為什麼 io_uring 能提升高效能網路伺服器的效能。我原先認為其效益主要來自「減少系統呼叫次數」，但老師指出其最大優勢其實在於其 lock-free 設計。這讓我重新思考在多核、高並行環境中，鎖的開銷與延遲不確定性對整體效能影響甚鉅。此外，老師也回覆了我之前關於 vruntime overflow 的問題：的確有可能發生，但發生機率極低，可透過 CFS 計算 vruntime 的行為建模方式統計評估，若此事件發生的時間遠超越實際場景，開發者便可視為可接受的風險。

• 6/30：老師要求我實作 SPSC FIFO queue，並進一步思考 lock-free 與 lock-less 結構的設計差異，這促使我深入理解 Linux kernel 中 io_uring 的內部實作邏輯與資料結構。相關筆記詳見：SPSC FIFO QUEUE。

課堂問答

• 5/20：與老師在課堂上討論 Redis 為什麼採用 skip-list 作為資料結構。我事後查閱相關論文與資料，深入理解 skip-list 在資料庫中的特性，包括其在插入、刪除與範圍查詢上的效率優勢與實作簡潔性。 詳細紀錄見：課堂討論

• 6/17：與老師探討 semaphore 與 mutex_lock 的差異，特別是 mutex_lock 具備 ownership 概念，因此若某執行緒長時間持有鎖不釋放，將造成系統阻塞的風險。這個問題引發我進一步研究 pthread_mutex_timedlock 的設計原理與使用情境，以避免鎖的 starvation 與 deadlock 狀況。 詳細紀錄見：課堂討論

綜合以上不論是課堂上的問答，還是一對一的討論，我給自己這部分 10 分。每次和老師的互動，不只是單純的發問，而是幫助我發現自己在系統軟體理解上的盲點。像是 vruntime 是否會 overflow、為什麼 io_uring 能帶來效能提升、或是 semaphore 和 mutex 的差異，這些問題都讓我事後回去查資料、看論文、做實驗，甚至寫成筆記。 我覺得這門課最讓我有收穫的，就是這種從「問題」出發，再透過閱讀、反思、討論來對題可以有更進一步的探討與理解，這讓我學習不只是從單一表面的角度思考，而是可以更全面的去理解問題的根本與其他議題的關聯。

所見所聞

這學期修習這門課帶給我兩方面的成長：一是對系統軟體的理解（可參見前述內容），二則是對「學習」本身態度的轉變，以下將著重分享後者。

在學期初的第一堂課，老師提到軟體開發中的疏失可能造成的實際危害，讓我深刻意識到這門課對細節的重視，也讓我體會到，身為工程人員，應該對自己寫出來的每一行程式碼負責。開學初的隨堂測驗更讓我感到煎熬，尤其是數學部分的題目。這讓我意識到，自己過去三年來對數學的學習並不紮實是理解力薄弱的根本原因。從那時起，我開始調整自己的學習心態，每一個提問與測驗，都是一個深入探索議題的起點，而非只是為了給出一個正確答案。

這門課也讓我重新定義了「學習」的真正意義。過去的我常靠小聰明與考古題拿到還不錯的成績，但當面對開放性的問題時，卻只能用模糊的形容詞和模稜兩可的語句掩飾自己的不理解。我曾習慣用「看起來懂了」來騙自己，但在這堂課，我學會了正視自己的不足。當我面對一個問題沒有百分之百掌握時，我必須坦然承認我不知道。犯錯不可恥，可恥的是一知半解卻假裝自己已經理解。只有真正面對自己的不足，才能讓能力踏實前進。

此外，我也學到作為工程人員，任何「結論」都必須建立在「數據」之上。觀察實驗結果、記錄行為模式，然後從中推論，是比背誦理論更關鍵的能力。我也學會，不應急著動手寫程式，而是要先釐清問題，了解要解決的是什麼，觀察程式的實際行為，確認理解後再動手實作。這樣才能避免落入「舉燭」看程式卻一直幻想的窘境。

我給自己這部分 10 分。因為這些所見所聞，讓我學會以正確的態度面對工程問題。老師每一次的講課與回覆，都拉我離開過去的舒適圈與錯誤學習習慣。更重要的是，我知道這堂課的學習並不是終點，而是我未來面對現實世界的問題時，該持續秉持的素養與準則。

自我評分

1.成果發表和貢獻： 6 分

2.作業/隨堂測驗： 8 分

3.期末專題： 10 分

4.與授課教師的互動： 10 分

5.所見所聞所感： 10 分

總分：使用方案 B: 1 + floor(GEOMEAN) ＝ 1＋floor(8.634719)= 9