---
title: Chang Yun-Tang (張昀棠)
categories: User
...

# 簡介
- 資訊工程學系 115 級(2021~2025)

- Github:[`Andrewtangtang`](https://github.com/Andrewtangtang)
- Hackmd:[`Andrewyuntang`](https://hackmd.io/@Andrewyuntang)

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

## 自我評分
1.成果發表和貢獻： 6 分

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

3.期末專題： 10 分

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

5.所見所聞所感： 10 分

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

### 成果發表和貢獻

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

### 作業／隨堂測驗

* [Homework (lab0)](https://hackmd.io/@Andrewyuntang/linux2025-homework1)

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

* [Homework2 (quiz1+2)](https://hackmd.io/@Andrewyuntang/linux2025-homework2)

* [Homework3 (kxo)](https://hackmd.io/@Andrewyuntang/linux2025-homework3)

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

* [Homework5 (assessment)](https://hackmd.io/@Andrewyuntang/linux2025-homework5)

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

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

### 期末專題

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

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

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

### 與授課教師的互動

#### 一對一討論

* **5/12**：與授課老師討論課業上遇到的問題，詳細紀錄於 [Homework5 (assessment)](https://hackmd.io/@Andrewyuntang/linux2025-homework5)。當時我向老師提問：`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](https://hackmd.io/@Andrewyuntang/spsc_fifo)。
 
#### 課堂問答

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

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

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