版本 1b08c3e457d7eeb2295cfb60a601bdbbdd8c6938
Changes from 1b08c3e457d7eeb2295cfb60a601bdbbdd8c6938 to 4682ee24e1af132174c4f0fbca44b4f934c084dd
# 2026 年 Linux 核心設計課程自我評量
姓名：`洪英豪`
GitHub 帳號：`Bigtooth123`
## 成果發表與貢獻
> 6
在[從 CPU cache coherence 談 Linux spinlock 可擴展能力議題](https://hackmd.io/@sysprog/linux-spinlock-scalability)當中修正分號問題
## 作業
> 10
* [Homework1](https://hackmd.io/@jason917/linux2026-warmup)
* [Homework2](https://hackmd.io/@jason917/linux2026-stdc)
* [Homework3](https://hackmd.io/@jason917/linux2026-basics)
* [Homework4](https://hackmd.io/@jason917/linux2026-introspect)
從這些作業當中我獲得了以下收穫：
1. 更加深入的理解 C 語言指標運用技巧
2. 撰寫效能測試程式碼，並熟悉使用 perf 等工具來分析程式效能
3. 學習了很多 Linux kernel 相關議題，像是 linked list 操作與排序, hash table, 記憶體機制, syscall 完整流程以及 Linux 核心檔案 I/O 機制等等
4. 查閱第一手資料，比如直接看 Linux manual page
5. 實作這些作業後，重新統整並複習了作業系統跟計算機組織的概念，包括了像是浮點數, 記憶體快取架構與 page table 等等
## 期末專題
> 8
[專題連結](https://hackmd.io/@sysprog/SyC5lS3gMg)
本期末專題著重於從硬體微架構與快取一致性（Cache Coherence）的視角，分析、建模並量化 Linux 中的同步機制。專案中我完成了下列幾項工作：
* 建構馬可夫鏈模型：建立基於 $M/M/c$ 的排隊模型，推導出 Ticket Spinlock 與 MCS Spinlock 在不同排隊人數下的微觀狀態機率分佈（$P_k$）與期望吞吐量公式。
* Userspace 競爭模擬與低開銷量化：使用 C11 原子操作在使用者空間實作 Ticket Lock 與 MCS Lock。為避免全域計數器破壞 MCS 的區域自旋優勢，透過 64-byte 快取行對齊（Padding）消除偽共享（False Sharing），並設計低頻率抽樣機制（SAMPLE_RATE = 1000）進行動態量化。
* 帶入微觀物理時間常數驗證模型：在模型中帶入與硬體環境對齊的物理參數（臨界區時間 $E = 10\text{ ns}$ 對應 50 次空迴圈、快取交接成本 $c = 50\text{ ns}$、包含 x86 LOCK XCHG 原子指令開銷的到達時間 $T_{\text{arrive}} = 50\text{ ns}$），使理論吞吐量與狀態分佈曲線與實測趨勢高度吻合。
除以上成果外，我也深入分析了實驗中呈現的硬體運作邏輯。在狀態分佈對比中，Ticket Lock 的狀態高度集中在全員排隊（$P_8$），驗證了其釋放鎖時的循序點對點單播（Unicast）更新會帶來 $O(N)$ 的延遲堆積；而 MCS Lock 則能有效將分佈往排隊人數較少的狀態推移。此外，實驗也解讀了效能在核心數 $N=2$ 時達到巔峰後下滑的物理本質：當核心處於自旋時，快取作廢訊息將引發大量延遲。
### 提問
## 與授課教師的互動
> 8
* 第十週課堂問答(4/28)
* 討論Thread 間如何保護共享記憶體，發現自己對於 mutex, semophore, spinlock 概念不清楚。
* 第十八周課堂問答(6/23)
* 被問到第十六周考試的內容 SPSC。
* 線上一對一討論(5/27)
* 在一對一討論時被問到平方根相關問題，但是發現對於這些教材不熟習，結束討論我後把內容紀錄在 [5/27 一對一討論](https://hackmd.io/@jason917/Sy4o7UYxGe)
* 誠實面對自己
## 所見所聞所感
> 9
在選修 Linux 核心設計之前，就曾耳聞這堂課內容極多極廣，需要花費非常多的時間，因此在我大三的時候不敢選修這堂課，一直到了大四最後一學期，我才下定決心為了自己拼一把。
還記得第一個禮拜看到作業一後，我真的受到了強烈的衝擊，作業內容超級多，老師說需要每週付出 20 小時的時間，我覺得如果要完整完成要花的時間絕對超過 20 小時，為了能夠灌雙系統我甚至去買了 SSD ，還剛好碰上持續的價格上漲。
接下來的學習過程真的是既扎實又充滿挑戰，同時又非常特別，老師上課會隨機點人來回答問題，也要求要約一對一討論，都一再的讓我們面對自己的不足。更重要的是，這堂課不允許我們僅停留在概念層面，而是必須探究現實世界中系統的真實運作。在撰寫作業的過程中，我的學習方式也產生了改變，從最初遇到問題單純依賴 ChatGPT，到後來學會親自翻閱、追蹤 Linux Kernel 的原始碼，我對系統核心也變得越來越熟悉。
回顧這段學習過程，從前四次作業中學到了許多知識。在實作面上，我不僅深入掌握了 C 語言指標的進階運用，更學會了如何撰寫效能測試程式碼，並運用 perf 揪出系統效能瓶頸。在系統機制上，我研究了 Linked list 與 Hash table 的底層實作、記憶體管理、Syscall ，以及核心檔案 I/O 機制，我還重新重新複習了浮點數底層表示、記憶體快取架構與 Page table 是如何影響程式運作。而在最後的專題上，我理解了在 smp 架構上所面對的多核競爭問題，而為了解決這些同步與記憶體順序議題，必須引入 memory barrier 甚至 atomic 操作。
最後，在看了〈因為自動飲料機而延畢的那一年〉後，我對作者說的一句話深有感觸：「但這是他媽的真實的人生，熱血毫無用武之地」，我在寫作業跟專題的時候，常常沒有做好規劃，就投入到實做當中，急迫的想要趕快看到結果，但是往往會因為流程或模型沒有想清楚，導致又要整個實驗重作。這讓我深刻體會到，真實世界的工程開發靠的不是一時的衝動與熱血，唯有周全的實驗設計、嚴謹的邏輯推演與耐心的除錯，才能確保實作走在正確的軌道上。
## 分數計算
$GEOMEAN=(6 \times 10 \times 8 \times 8 \times 9)^{1/5}=8.085$
選擇方案 B ：$1+floor(GEOMEAN)=1+8=9$
