---
title: willy-liu (劉威麟)
categories: User
...

## 簡介

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

* [GitHub](https://github.com/willy-liu)

* [HackMD](https://hackmd.io/@willy-liu)

# 2025 Linux 核心實作 春季班 自我評量
## 成果發表和貢獻
自評分數：5分

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

### 一、貢獻至 Linux 核心相關專案
我針對 sysprog21/lab0-c 專案共完成兩筆經合併的實質貢獻：

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

2. 改進 Git hooks 的 fork 驗證機制（[#268 PR](https://github.com/sysprog21/lab0-c/pull/268)）
針對課程作業倉庫的 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](https://hackmd.io/@willy-liu/linux2025-homework1) - lab0-c
這次經歷讓我深刻認知到自身的許多不足，包括：
程式碼風格 (Coding Style)：過去習慣的寫法在 Linux Kernel 風格下顯得冗餘且不夠規範。
邊界條件優化 (Code Smell)：處理鏈結串列的頭尾等邊界情況時，我發現自己常會寫出特殊的判斷邏輯，導致程式碼不夠通用和優雅。
基礎演算法掌握度：即便是像鏈結串列的基本操作，以及相對複雜的 merge sort，我都發現自己寫得不夠好，缺乏效率和精煉度。
2. [hw2](https://hackmd.io/@willy-liu/linux2025-homework2) - 2025q1 第 1 週和第 2 週測驗題回顧
在 hw2 我學會了，即使沒有大量動手寫程式，光是深入理解測驗題目的設計原理，也能帶來非常深刻的收穫。我重新理解了「指標的指標」(**p和pprev) 的巧妙之處，消除了處理鏈結串列頭部節點時的「邊界條件特例」寫法。


3. [hw5](https://hackmd.io/@willy-liu/linux2025-homework5) - 2025q1 Homework5 (assessment)


## 期末專題
自評分數：4分

[Linux 核心專題: 分析 BitNet 的系統效能表現](https://hackmd.io/AMfZACnXSaSxOvhWf_85Aw?view)
[Tiled Matrix Multiplication 筆記](https://hackmd.io/@willy-liu/ryh9rcJree)


這次專題主要在分析 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 命中率的變化。


## 與授課教師的互動
自評分數：分

## 所見所聞所感
自評分數：分


## 修課心得
自評分數：分