簡介

• 國立成功大學 資訊工程研究所

• GitHub

• HackMD

2025 Linux 核心實作 春季班 自我評量

成果發表和貢獻

自評分數：5分

在本學期「Linux 核心與系統程式設計」課程中，我積極參與了與 Linux 核心相關的實作與貢獻工作，期間從 2 月 18 日至 7 月 2 日，主要完成以下幾項具體成果：

一、貢獻至 Linux 核心相關專案

我針對 sysprog21/lab0-c 專案共完成兩筆經合併的實質貢獻：

1. 修正 cppcheck 靜態分析的誤報（#240 PR） 由於 cppcheck 在分析過程中無法取得預定義的編譯器巨集，導致錯誤地判定某些路徑，例如 list 巨集中出現未使用標籤等 false positives。我實作了 get_compiler_macros 函式，能自動偵測系統上使用的 C 編譯器（gcc 或 clang）及其對應標準版本，並補上必要的巨集（-D__GNUC__=1 等），成功改善靜態分析環境模擬的準確性。

2. 改進 Git hooks 的 fork 驗證機制（#268 PR） 針對課程作業倉庫的 Git hooks 安裝機制，我提出改進建議，讓系統能夠更正確地驗證學生是否 fork 自正確的主倉庫（sysprog21/lab0-c），並確保遠端倉庫名稱為 lab0-c。 我實作以下幾項變更：

• 動態取得帳號名稱與倉庫名稱，取代硬編碼；
• 改用 awk 及 Git 指令解析 repo URL，避免使用 jq，提高相容性；
• 驗證 GitHub API 回傳是否為 fork，並確認 parent.full_name 為預期主倉庫；
• 加入 API 回傳為空的錯誤檢查機制；

作業/隨堂測驗

自評分數：4分

我完成的內容比較少，只有hw1, hw2, hw5的部分問題

1. hw1 - lab0-c 這次經歷讓我深刻認知到自身的許多不足，包括： 程式碼風格 (Coding Style)：過去習慣的寫法在 Linux Kernel 風格下顯得冗餘且不夠規範。 邊界條件優化 (Code Smell)：處理鏈結串列的頭尾等邊界情況時，我發現自己常會寫出特殊的判斷邏輯，導致程式碼不夠通用和優雅。 基礎演算法掌握度：即便是像鏈結串列的基本操作，以及相對複雜的 merge sort，我都發現自己寫得不夠好，缺乏效率和精煉度。

2. hw2 - 2025q1 第 1 週和第 2 週測驗題回顧 在 hw2 我學會了，即使沒有大量動手寫程式，光是深入理解測驗題目的設計原理，也能帶來非常深刻的收穫。我重新理解了「指標的指標」(**p和pprev) 的巧妙之處，消除了處理鏈結串列頭部節點時的「邊界條件特例」寫法。

3. hw5 - 2025q1 Homework5 (assessment)

期末專題

自評分數：4分

Linux 核心專題: 分析 BitNet 的系統效能表現 Tiled Matrix Multiplication 筆記

這次專題主要在分析 BitNet b1.58 在 CPU 上推論的效能問題，過程中我花了不少時間學習怎麼用 Linux 的 perf 和 uftrace 這些工具來找出瓶頸。實際跑完分析後，我發現大部分時間都花在矩陣內積運算上（像 ggml_vec_dot_i2_i8_s 這種），還有不少時間浪費在執行緒同步（例如 ggml_barrier）。我有試著用 Huge Page 跟 CPU affinity 來優化，確實有一點點幫助，推論時間從 16 秒縮到 15 秒左右，IPC 也提高了，但 cache miss ratio 還是偏高。

我原本以為調整 chunk size 會有比較明顯的效能差異，結果觀察 ggml_compute_forward_mul_mat 時發現幾乎沒差，感覺可能是 GGML 裡面本來就做了不少優化，所以外面調參數反而動不了什麼東西。後來我決定自己來寫 tiled matrix multiplication，打算實驗不同 tile size 對 cache 使用的影響，只是這部分還沒來得及做完。

整體來說，這次專題讓我蠻有感的是：很多效能問題不是只看一兩個數據就能下結論，必須要從工具抓到的函式、CPU 訊號、快取、執行緒等層層去拆。然後也發現工具很好用沒錯，但有時候還是要自己動手實作，才真的能觀察出細節。這種從底層摸出來的理解，對我來說比單純 benchmark 模型還要有趣也有收穫。未來如果有時間，我會想把 tiled mul 的部分補完，看看能不能靠自己寫的版本，真的觀察出一些 cache 命中率的變化。

與授課教師的互動

自評分數：分

所見所聞所感

自評分數：分

修課心得

自評分數：分