簡介

• 國立成功大學 智慧資訊安全碩士學位學程
• GitHub: kezhenx666

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

本份自我評量遵循課程自我評量指引 的書寫規範，避免「期許自己」、「已盡最大努力」等空泛承諾,所有產出皆附對應的公開軌跡 (Linux 上游 patch、GitHub PR、HackMD 開發紀錄、會議錄影)。

---

成果發表和貢獻

6 分。

於 KVM: Linux 虛擬化基礎建設 : 在 kvm-host 專案中的原始程式碼 kvm-host/src/arch/arm64/vm.c 的 init_reg() 函式中，註解提及 /*Clear x1 ~ x3 */，但在實作的 for 迴圈卻是 0 ~ 3 ，這並不包含 3，代表 x3 並未被設定為 0，目前該錯誤還在閱讀是否為開發者有其他考量因素。

這學期對於 Linux 核心程式碼和老師教材未做出貢獻，老師上課曾說 : 「Linux 的註解寫的很詳細」，因此，我透過老師的教材理解搭配教材擷取的 Linux 核心程式碼和註解內容閱讀以及 git log 變化的脈絡，在我寫作業幫助我反思為何該機制會這樣被取代，這對於我後續在閱讀他人專案時會先第一手閱讀程式註解和 log 說明，而非一昧的依賴工具。

作業/隨堂測驗

8 分。

作業重點回顧 :

2026q1 Homework1 (warmup) :

這是第一次面對自己過去所學的知識並不夠堅固的開始，因此，對於作業一的每一題我都閱讀教材和查閱規格書並且搭配 Linux 核心程式碼做回答。

• git log 和程式註解的資訊比我想得多

如其中一個習題 : 為何針對鏈結串列的節點走訪 (linked list traversal) 難以被 hardware prefetcher 預測？若使用 __builtin_prefetch(node->next); 是否一定改善效能？請記憶體存取圖形角度解釋，並從 git log 探討 Linux 核心的 List API 一度採用 prefetcher 又棄置的考量。

我回答的方式先分析鏈結串列本身特性並閱讀相關論文來說明 hardware prefetcher 的實作機制，接著閱讀 GCC 文件對於 __builtin_prefetch() 函式的目的，分析在 prefetch 可能發生尚未完成和過早完成的情況下，兩者的效能影響，而針對第三小題在閱讀 git log 內容時，發現開法者說明已明確表明為何會將 Linux 核心的 List API 採用 prefetcher 棄置的原因為使用者應該要根據自身的工作負擔自行加入，而非由通用的 API 實作，因為在核心中，需要處理得鏈結串列通常很短，prefetch 會很常來不及發揮作用，這樣只會造成系統負擔。

• 本來就應該這樣，並非甚麼都是理所當然

在 Linux 核心程式碼中，為何機制會被棄用或是有些會被採用都是有數學和實驗做分析，如老師上課談到為何在 Linux 核心程式碼中的 merge sort 會有延遲合併的機制存在不同於 fully-eager bottom-up mergesort，這需要分析極端合併發生時所需要的比較回合數變化，透過 2:1 延遲合併可以確保當極端情況越來越嚴重時，可以分散合併深部到不同層之中降低比較次數，此外，這個改善的想法也詳細描述於註解中，甚至有相關文件和論文可以閱讀。

2026q1 Homework2 (stdc) :

因為期末專案與記憶體有關，因此，我主要閱讀〈記憶體管理、對齊及硬體特性〉、〈C 語言的 bit field〉 在閱讀記憶體章節時，我對於過去作業系統所學的相關知識幾乎消失，因此，在回答這章節內容時，我是先重新閱讀作業系統教材搭配老師教材來回應習題。

• 理論和實際還是有差異

關於不同硬體對於記憶體存取就有不同方式，x86 架構下，CPU 會自動分解成多次對齊存取，再做資料重組，但在 RISC 架構下，並不支援非對齊存取，遇到非對齊情況就會直接觸發例外，或是要多額外指令來處理，那在 Linux 核心需要同時滿足不同硬體架構，所以提供額外函式 get_unaligned()、put_unaligned() 透過位移運算和邏輯操作，目的是為了讓不同硬體架構下皆可以正確地讀寫資料而不會有錯誤發生，像這種實務上跨系統的開發考量點是無法在作業系統書上得到。

2026q1 Homework3 (basics) :

未完成

期末專題

8 分

Linux 核心設計 - 題目 : Linux 核心設計專案: pKVM

• 2026/05/12 第一次與老師討論主題，因上課提到對於 Android 手機碎片化問題，因此對該題目有興趣，與老師討論後，需要先閱讀老師教材有關 KVM 和 kvm-host 專案的實際執行並記錄問題，還有對於 Google 提出的 pKVM　為何是基於虛擬機器而非容器。

我的作法是閱讀 Linux LWN 演講的內容，並分析虛擬機器和容器差異，以及 Android 手機碎片化問題的發生原因，最後閱讀老師教材和執行 kvm-host 專案，因為完成以上問題再次向老師討論。

• 2026/06/09 第二次與老師討論下一步，老師先問幾個問題就說我需要閱讀第一手教材，而非別人的筆記，所以我需要再去閱讀 Google 官方的演講和簡報並且記錄影片中所有問題，先搞懂為甚麼這個機制被提出、和原先的差異在哪，不要想著馬上做，然後先去執行 Android 有提供原始程式碼和模擬器先去執行起來。

我認為我應該及早與老師討論，因為在第二次討論中，我發現我閱讀材料的來源應該是 Google 線上演講和第一手教材，並且在第二次討論老師問 2~3 問題後，我就覺得我太心急於想要拿到一個題目，但沒有把基礎背景知識補齊。

總結我的期末專案進度:

回應老師討論所提出的內容和執行方式，針對 Google 教材閱讀，並執行所提供的模擬器和教材專案，以上我都有做到且完成，但我還未對於實際專案做程式碼修改和重現，目前實作 pKVM 需依賴 arm64 的 Exception Level 來實現安全性防護，但在我目前實驗硬體為 x86 並在上面執行 Android 模擬裝置，是無法真實呈現 pKVM 想達成的保護機制，因此，我現在嘗試移植模擬環境到 arm64 環境中執行。

因此，我給自己期末專案 6 分。

觀摩其他學員的期末專題：

1. Linux 核心設計物專題: kxo

在紀錄 CPU 所剩資源中，為何會在每 100 ms 分配任務時，給予各個 CPU budget ，100 是如何選擇 ?

2. Linux 核心設計專題: 測量系統資源開銷並改善

筆記寫到會 rollup 找可以減少的地方，在 printk 中分析剩下的功能，你要如何決定那些是必要功能，哪些是可刪減的 ?

3. Linux 核心設計專題: openBMC 改進

任務提及到 openBMC，從筆記中你目前的實驗環境包含三個 terminal，這之中是否含有 openBMC ?

4. Linux 核心設計專題: CPU 排程器研究

任務有提及到實作最小可行 BPF scheduler，那關於該實驗的 baseline 會如何建立 ?

5. Linux 核心設計專題: RISC-V 平台驗證和改進

在最小 Device tree 中，你說到實際開發時，會先從 dts 檔案分析並建立最小的 device tree，這個分析動作要如何判斷 ?

回應其他學員提問 :

已完成回覆學員發出的問答。

與授課教師的互動

5 分

與授課教師預約線上一對一問答 0 次，在實體課程後與授課老師一對一問答 2 次

• 2026/05/12 : 向授課老師詢問期末專案內容。
• 2026/06/09 : 回應授課老師先前對於專案提問的回應。

所見所聞所感

10 分

閱讀〈因為自動飲料機而延畢的那一年〉系列文章後，讓我印象最深刻的，是作者在試圖解決冰塊切分問題時，經歷了許多挫折、反覆嘗試與成本考量。當時團隊成員即將出國，專案又缺乏人力加入，甚至多數人都認為自動飲料機這個專案的回報率很低。在這樣的情況下，jserv 對作者說了一句話：「你該學習的不是看到事情要完蛋了就去避免失敗，而是應該學習如何處理與承受失敗，你才能變得比以前更強大。」，這句話也呼應老師從期初到期末不斷提到的「誠實面對自己」。

• 誠實面對自己

在撰寫作業 0 - Warmup 習題時，我閱讀每一份教材，都覺得其中許多內容過去在作業系統與 C 語言程式設計課程中似乎已經學過。然而，當真正要回答作業題目時，才發現自己的用詞並不精確，概念也相當模糊。這讓我意識到，過去以為自己理解的知識，其實仍停留在表層，因此，面對習題我都在閱讀完課程教材和參考權威資訊來回答並反思。

「對你而言真正重要的事物，會比你想得到的事物更早出現在路邊。」這句話讓我反思，若真的想要翻身，就必須有所犧牲。當我認知到自己在 Linux 知識面前有多麼渺小時，就不應該再逃避學習，而是要專注在真正重要的事物上，不再自欺欺人。

另外，文章中提到：「大多數人一直活在『本來就應該這樣』的童話世界裡。電視打開就可以看，機車買來就可以騎，手機買來就可以用，一切都被視為理所當然。偶爾買到不好用的商品，我們只會抱怨幾句，丟掉後換其他更好用的牌子，卻很少意識到那些『本來就該這樣』的背後，需要經過多少人月的投入與研發。」，這段話讓我想到這學期老師教授 Linux CPU 排程器演進歷史與並行程式設計、系統資源共享時，將過去曾學過的統計、離散數學、機率，甚至不同時空背景下的歷史脈絡，其實都影響 Linux 作業系統的設計與發展，看似理所當然能夠正常運作的系統，背後其實累積無數實作嘗試、失敗與改進和實驗支持。

• 關於自身投入的回顧

學期 20 週中；期初每天投入 3 小時以上閱讀教材，補足作業系統相關知識並撰寫回答習題，上課紀錄老師教授的主題，在得到期末專案題目後，每天投入 2 小時補足專案需要的背景資訊包括 : 記憶體管理、MMU 機制、KVM 演講、KVM 虛擬化基礎建設、原始程式碼分析、KVM API，有透過撰寫筆記來記錄過程，但尚缺乏實際實作。

自我評量 (1 ~ 10)

分數計算

項次	名稱	分數
1	成果發表與貢獻	6
2	作業與隨堂測驗	8
3	期末專題	8
4	與授課教師的互動	5
5	所見所聞所感	10

幾何平均 (GEOMEAN) 計算

\[\text{GEOMEAN} = \sqrt[5]{6 \times 8 \times 8 \times 5 \times 10} = \sqrt[5]{19200} = 7.19\] 方案選擇

• 方案 A : 0
• 方案 B : 1 + floor(GEOMEAN)。
• 採方案 B : \(1 + \lfloor(GEOMEAN)\rfloor\) = 1 + \(\lfloor(7.19)\rfloor\) = \(1 + 7\) = 8

自我評量總分 : 8 / 10