簡介

• 國立成功大學 資訊工程學所 116 級
• GitHub: jeremylu0830

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

成果發表和貢獻

8 分。

• 第19周教材 : Rust for Linux 研究
  • garbade collector => garbage collector
  • virtme 配合 busybox 使用 （通過 rcS 在 Linunx 啟動時將放置核心的目錄掛載到 /lib/modules）=> Linux
  • 直關上的作法為使用 use std::ffi::CStr;，但是在核心模組開發中我們不能使用 std 相關函式庫 => 直觀上
• 第 10 週教材 : Linux 核心設計: 多核處理器和 spinlock
  • enabled interrupts (sti) => Enable interrupts (sti)
• 第 14 週教材 : Linux 核心 Copy On Write 實作機制
  • 處裡 process 記憶體之間的干擾 => 處理
  • 讓就的資料有更好的 locality => 讓舊的資料
  • 找不到想要的 page fault 就會出發 page fault exception => 觸發 page
  • 隨時開起 pfn_to_page 、page_to_pfn => 開啟 pfn_to_page
• 第 14 週教材 : KVM: Linux 虛擬化基礎建設
  • 裡面包含 Bus 初始化、 serial device 初始化、 PCI Bus 初始化，遇有對 GICv3 的初始化 => 還有對 GICv3
  • device_feature_select 用來選擇呈現的 Feature 是高 32 位還是低 32位 => 位 改成 精確的位元

以上貢獻都是跟 typo、英語文法以及相關用詞的修正，但老師說勿以善小而不為，但是尚未有程式碼邏輯和行為的改動去解決真實世界的問題，因此計算為 8 分。

作業/隨堂測驗

7 分。

• 2026q1 Homework1 (warmup)
• 2026q1 Homework2 (stdc)
• 2026q1 Homework3 (basics)

在寫作業的時候，學習了許多以往沒有注意到的細節，以及被草草帶過的觀念，這次的作業所需要培養的能力包含找資料、驗證資料、推導原理以及理解並付諸實現，這過程中也意識到數學在資訊產業的重要性。同時，作業促使我體會到閱讀第一手資料的重要性。與其盲目訴諸搜尋引擎，不如直接查閱 C99 規格書或 man page 等官方文件，從最根本的定義去理解問題。第三次作業由於自身規劃不佳，沒有能夠動筆。隨堂測驗的部分，總計只缺席了一次，這種即席的測驗很好的訓練我如何在有限的資源以及時間，盡可能地回答問題，遇到不會的題目也能夠推理出可能的答案，讓我能夠在後須專題閱讀規格書時快速找到重點。我給自己7分。

期末專題

8 分。

Linux 核心設計專題: 異質多核通訊機制

原以為異質多核的難處在於高階的架構設計，真正投入後才發現，關鍵往往藏在那些過去被忽略的底層細節裡。本次專題尚未做到改進效能，只有更新 MilkV sdk、建立一套基準 benchmark以及嘗試將 Linux 版本更新至 7.0。

雖然沒有做到改進，但其中學習到的知識，包含燒錄 image、了解 USB bus，又或者是 RPMsg 與 VirtIO 的關係，最重要的還是意識到 benchmark 的重要性，都是過去以為理所當然、實際動手才發現處處是細節的部分。

在建立 benchmark 的過程中，也體會到「量測本身會改變被量測對象」這件事。最初純粹的 RTT 量到約 75µs，但為了拆解延遲、在核心與韌體的路徑上插入時間探針後，同樣的往返卻變成約 105µs——多出的約 30µs 正是探針讀取時鐘、每趟讀取 procfs、小核額外記錄所引入的觀測開銷。這讓我理解到，要看見內部結構，就必須付出干擾系統的代價，而紀錄這個代價、區分系統最佳值與量測時的值，才是嚴謹的態度。更進一步，在嘗試直接量測跨核傳輸延遲時，也遇到了不同 clock domain 的問題：大核 Linux 用經過校正的 monotonic clock、小核 ThreadX 只能直接讀硬體的 raw mtime 計數器，兩者原點與單位皆不同，不能直接相減；唯有讓兩核都讀取同一顆共用的 CLINT mtime，才能真正跨核比較。這個看似單純的兩個時間相減，背後牽涉到的是整個計時子系統的設計哲學。

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

• Linux 核心設計專題: Linux no-MMU 的客製化和改進
• Linux 核心設計專題: 縮減系統啟動時間和客製化
• Linux 核心設計專題: 改進 vcam
• Linux 專題: 效能分析和改進案例探討
• Linux 核心設計專題: 改進 vwifi

與授課教師的互動

8 分。

• 4/14 課堂討論：探討 process vs thread 在 linux 的本質差異在哪。
• 5/12 課後討論 : 討論異質多核專題，先去重現去年實驗，了解整體的架構，理解其中原理，不用到當學校老師，但至少要會統整當補習班老師的程度。
• 5/26 課堂討論：探討異質多核的重要性以及 RPMsg 和 VirtIO 相關問題，包含 頻率跟功耗的關係、為何異質多核需要通訊以及為何需要有異核的架構。
• 6/23 課後討論：與老師分析我目前 benchmark 的不足，我假定大核往小核的通訊成本等於小核往大核，這是錯誤的想法，並與老師討論可能的原因，以及去測試不同payload 對通訊成本的負擔。
• 6/2 模擬面試:與助教和老師討論 ，Process 與 Thread 的本質差異、Stack 與 Heap 的設計考量、使用 POSIX Thread 控制執行順序、Futex 的設計與排程器的互動，但都答不出來，有在後續檢討以及追蹤(回信的方式)

所見所聞所感

10 分。

誠實面對自己

這堂課首先讓我意識到作為碩士生，我連許多基本的能力都不足，像是高中數學無法運用在現實生活、說自己懂C語言卻無法實作資料結構，甚至連 Quick sort 都無法做出全面分析，只會死背複雜度。起初覺得我只是不想努力，只要認真讀就會變成強者，但越是上課，越是難過，發現自己其實是井底之蛙。這會下意識地想讓人逃避，無法有實質改進，不如承認自己的不足，虛心求教，一點一滴地把教材看完，即使很慢。到後期也比較敢跟老師對話，相較於一開始傾向選擇看似安全或討好的說法，現在我更願意誠實面對自己。

對細節的重視

許多人剛拿到專題的時候會急於改進，包括我，劈頭就是問說我能改甚麼，但專案都是由前人一點一滴去累積的，想要在很短的時間內理解就很難了，何況是做出改進，裡面的細節很多，這點我感同身受，在異質多核裡面，不論是 USB 、 RPMsg 又或是 VirtIO 都大有學問，如果不去鑽研這些學長實作的細節，會不知道哪裡是他嘗試過的方向。benchmark 的分析也是研究的重點，細節藏在魔鬼中，這是真的，在起初我以為 小核送往大核 以及 大核送往小核 的時間是一樣的，但經過岩井的 benchmark 查證，發現會有很大的差距，這也讓我理解到一個好的研究是必須靠嚴謹的分析，在有限的程式碼盡可能榨乾有用的資訊。這也在實習的過程幫助我，剛好我的 team 是做 performance 相關，不僅能看到一個產品對於 benchmark 有多注重，也能讓我更快跟上他們對於細節的思路，了解到產品不是平地起高樓，必須經過很多心思，以及對於細節的重視堆疊上去的。

閱讀〈因為自動飲料機而延畢的那一年〉

我最有感覺的是我最有感覺的是「你不能現在就放棄，要是現在就放棄的話，你這輩子日後遇到這種等級的困難，就只會想逃避而已。」，恰恰也是我現在的處境，只會逃避寫程式，甚至欺騙自己其實很厲害，要先對自己誠實，即使差距很大，但也要一步一腳印慢慢朝著頂尖邁進，或許日後的困難會更大也說不定，但能夠養成好的心態以及方法，會是一輩子受用無窮的。

自我評量 (1 ~ 10)： \[GEOMEAN=(8×7×8×8×10)^{1/5}=8.14467201856\]

方案 B：1+floor(GEOMEAN)=1+8=9