版本 894a740690a984f4d7cc500ece64bbba78a6af33

User/c8763yee

Changes from 894a740690a984f4d7cc500ece64bbba78a6af33 to 2d79caf1147f4e07a648b67cb3e9174ca4df57d2

---
title: c8763yee (徐彥翔)
categories: User
description: backup and draft of https://wiki.csie.ncku.edu.tw/User/c8763yee
---

# 簡介

* 國立中正大學 資訊工程研究所 (2025/09 ~)
* GitHub: [`c8763yee`](https://github.com/c8763yee)
* HackMD: [`c8763yee`](https://hackmd.io/@c8763yee-)
* Linkedin: [`徐彥翔`](https://www.linkedin.com/in/%E5%BD%A5%E7%BF%94-%E5%BE%90-11792a212/)
* GitHub：[`c8763yee`](https://github.com/c8763yee)
* HackMD：[`c8763yee`](https://hackmd.io/@c8763yee-)
* Linkedin：[`徐彥翔`](https://www.linkedin.com/in/%E5%BD%A5%E7%BF%94-%E5%BE%90-11792a212/)

# 2026 Linux 核心設計 春季班 自我評量

## 成果發表和貢獻
本份自我評量遵循 [課程自我評量指引](https://hackmd.io/@sysprog/linux2024-assessment) 的書寫規範，避免「期許自己」、「已盡最大努力」等空泛承諾，所有產出皆附對應的公開軌跡 (Linux 上游 patch、GitHub PR、HackMD 開發紀錄、會議錄影)。各項自評分數皆為 1 到 10 的整數，最末以幾何平均計算總分並適用方案 B。


## 成果發表與貢獻

> 9 分

### Kernel patch (Trivial)

* [perf/x86/amd/ibs: Fix comment typo in ibs_op_data](https://lore.kernel.org/lkml/20260113141830.3204114-1-rrrrr4413@gmail.com/)

我在閱讀 AMD IBS 相關程式碼時發現其 bit-field 註解中 bit 範圍標示錯誤 (正確的範圍應該是 16-31)，考慮到可能有人被註解誤導 bit-field 範圍，因此「路見不平，拿 Patch 來補」，發送了我個人的第一個 Linux kernel patch。即使只是修了一行，但畢竟「勿以善小而不為」。
我在閱讀 AMD IBS 相關程式碼時發現其在 [arch/x86/include/asm/amd/ibs.h:80](https://github.com/torvalds/linux/blob/b2ea0f541d354c10186a894e8bf5bf83abf8a517/arch/x86/include/asm/amd/ibs.h#L80) 中 bit-field 註解中 bit 範圍標示錯誤 (正確的範圍應該是 16-31)，考慮到可能有開發者被註解誤導 bit-field 範圍，因此「路見不平，拿 Patch 來補」，發送了第一個 Linux kernel patch。

```diff=77
struct {
    __u64	comp_to_ret_ctr:16,	/* 0-15: op completion to retire count */
-    tag_to_ret_ctr:16,	/* 15-31: op tag to retire count */
+    tag_to_ret_ctr:16,	/* 16-31: op tag to retire count */
    reserved1:2,		/* 32-33: reserved */
    op_return:1,		/* 34: return op */
    op_brn_taken:1,		/* 35: taken branch op */
```
該 Patch 於 2026/03/06 [合併入 tip tree 中的 perf/core 分支](https://lore.kernel.org/lkml/177279205425.1647592.7044256597939949372.tip-bot2@tip-bot2/)，並在 2026/04/14 於 7.1 的 Merge window 中[合併入主線](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=33c66eb5e9844429911bf5478c96c60f9f8af9d0)

### 教材修改
* [形式化驗證 (Formal Verification)](https://hackmd.io/@sysprog/formal-verification)
* [〈形式化驗證 (Formal Verification)〉](https://hackmd.io/@sysprog/formal-verification)
    1. [更新失效連結](https://hackmd.io/-oIc-o9IS4OMOMEkbMyn9w?revisionAfter=1774597254536#)
* [Linux 核心設計: 記憶體管理](https://hackmd.io/@sysprog/linux-memory)
* [〈Linux 核心設計：記憶體管理〉](https://hackmd.io/@sysprog/linux-memory)
    1. [預設的 slab allocator -> 唯一的 slab allocator](https://hackmd.io/t_SzlKdqQKGk7VFYnZ2NKQ?view=&revisionAfter=1776772216974&revisionAuthorPath=c8763yee-#)

		> RIP SLOB allocator (2006 - 2023, removed at 6630e950d532)

		> RIP SLAB allocator (1996 - 2024, removed at 16a1d968358a)

    2. [更新失效連結](https://hackmd.io/t_SzlKdqQKGk7VFYnZ2NKQ?view=&revisionAfter=1776834615980&revisionAuthorPath=c8763yee-#)
    3. [補充 Ftrace 資訊](https://hackmd.io/t_SzlKdqQKGk7VFYnZ2NKQ?view=&revisionAfter=1778728520600&revisionAuthorPath=c8763yee-#)
        
		> Before 4.1, all ftrace tracing control files were within the debugfs file system, which is typically located at /sys/kernel/debug/tracing.
    4. [優化 -> 改善](https://hackmd.io/t_SzlKdqQKGk7VFYnZ2NKQ?view=&revisionAfter=1780282222518&revisionAuthorPath=c8763yee-#)

* [你所不知道的 C 語言：編譯器和最佳化原理篇](https://hackmd.io/@sysprog/c-compiler-optimization)
* [〈你所不知道的 C 語言：編譯器和最佳化原理篇〉](https://hackmd.io/@sysprog/c-compiler-optimization)
    1. [更新維基百科連結 Elf(Myth) -> Executable_and_Linkable_Format](https://hackmd.io/VerfJi2ZSIO0RbgeL2ppGQ?both=&revisionAfter=1776324622194&revisionAuthorPath=c8763yee-#)

* [Linux 核心設計: 透過 eBPF 觀察作業系統行為](https://hackmd.io/@sysprog/linux-ebpf)
* [〈Linux 核心設計：透過 eBPF 觀察作業系統行為〉](https://hackmd.io/@sysprog/linux-ebpf)
    1. [補充在 x86-64 與 arm 下 `read` system call 具體變更的符號名稱](https://hackmd.io/CJb5S2gxTCiX-__krLUFpg?revisionAfter=1777201814451&revisionAuthorPath=c8763yee-#)

* [並行程式設計: 執行順序](https://hackmd.io/@sysprog/concurrency-ordering)
* [〈並行程式設計：執行順序〉](https://hackmd.io/@sysprog/concurrency-ordering)
    1. [修改公式顯示格式](https://hackmd.io/1ibD9_jeSR6HW72YtKpdrg?revisionAfter=1778650820370#)

### 公開演講
* 2026/08/09 — COSCUP 2026 System Software 講題[「從個人電腦到資料中心：Linux 記憶體管理的演化」](https://pretalx.coscup.org/coscup-2026/talk/review/SEA79ZSNPYE9ZDXUEB9BSW3LSVKHFYLC)
* 2026/08/09 — COSCUP 2026 System Software 講題[「從個人電腦到資料中心：Linux 記憶體管理的演化」](https://pretalx.coscup.org/coscup-2026/talk/RES9MM/)

## 作業/隨堂測驗
## 作業與隨堂測驗

> 7 分

一開始因為就學期間忽略數學的重要性，導致光是做「探討〈解讀計算機編碼〉」題組在補充缺失的數學知識就花了 3 天。而後面因為 Deadline 接近，因此後面只能針對程式語言的題目進行作答並繼續把之前沒學好的數學重新學習，這樣的結果是在第三次作業時只能先紀錄閱讀教材時的發現與問題。

不過在撰寫作業期間我開始注重使用的詞彙以及對於 C 語言規格書的使用，並且在閱讀課程教材期間也會主動注意教材使用的詞彙並修正。

### 作業
* [Homework1 (warmup)](https://hackmd.io/@c8763yee-/linux2026-warmup)

* [Homework2 (stdc)](https://hackmd.io/@c8763yee-/linux2026-stdc)

* [Homework3 (basics)](https://hackmd.io/@c8763yee-/linux2026-basics)

### 隨堂測驗
由於部份測驗未收到表單回覆回條，因此僅列出有收到回條的測驗與其成績（未標記分數的測驗以「回答正確數/題目數」標記）。


- 期初考最高成績：41 分
- 第 6 週測驗題：70 分
- 第 8 週測驗題：17 / 29
- 第 10 週測驗題：34 / 35
- 第 13 週測驗題：12 / 15
- 第 15 週測驗題：16 / 18

課程初期由於可以上網查資料與本地撰寫執行程式，因此做題目時偏向直接從對應 Linux 核心程式碼與撰寫 Python 程式計算，導致的結果就是來不及做完全部題目。不過在課程期間由於對 C 語言規格的重視，使得後續測驗成績逐漸提昇。在後續授課教師與其他學生的問答也開始往問題的本質思考。


## 期末專題

> 5 分

未完成期末專題
未完成期末專題，由於無法說明 MGLRU 本身對 Linux 核心於個人電腦的改善，因此未登記於[課程期末專題](https://hackmd.io/@sysprog/linux2026-projects)。

預計題目: 針對 MGLRU 的 reclaim loop 統計 (PID Controller) 根據 Generation 存活時間衰減歷史權重。
題目：針對 MGLRU 的 refault feedback loop 統計 (PID Controller) 根據 Generation 存活時間衰減歷史權重。

本題目對照於 Yu Zhao 在 [[PATCH mm-unstable v15 06/14] mm: multi-gen LRU: minimal implementation](https://lore.kernel.org/lkml/20220918080010.2920238-7-yuzhao@google.com/) 中 refault feedback loop 部份程式提到的 Future optimizations[(vmscan.c:3144-3146)](https://github.com/torvalds/linux/blob/ac35a490/mm/vmscan.c#L3144-L3146)

$$S_{new} = \frac{S_{old}}{\Delta t}+\frac{\Delta t-1}{\Delta t}x_t$$
$\Delta t = jiffies-lrugen_{ts}[Gen_{min}]$

開發紀錄：[Github](https://github.com/c8763yee/linux-experiment/compare/vanilla...main)

在進行期末專題時我發現我會時常把問題與架構想得太複雜，導致後續花費過多時間在處理 Userspace 模擬架構本身以及觀察 MGLRU 相較於 Active/Inactive list 的具體改善指標。

## 與授課教師的互動
尚未釐清的是：我無法區分 Yu zhao 當初設計 Refault feedback loop 時省略 D term 是否基於雜訊考量的刻意設計，且上述推測在 MGLRU 對應檔案的 commit message 與 LKML 討論中均無明文佐證。

## 與授課教師的互動
> 7 分
一對一討論具體紀錄請參考 [2026 Linux 核心設計行事曆](https://calendar.google.com/calendar/embed?src=embedded.master2015%40gmail.com&ctz=Asia%2FTaipei) 中標記 `一對一討論：c8763yee` 的活動
- 2026/02/24: 課後向授課教師詢問上述 Kernel patch 提交與合併流程的疑問
- 2026/04/21: 課後向授課教師詢問 COSCUP 與期末專題的題目選擇
- 2026/04/27: 第一次一對一討論：詢問期末專題題目方向
在本次一對一時被問到如何使用位元運算來實作浮點數除二，當時由於對 IEEE 754 格式的 過度思考如何處理 Infinity 與 NaN 導致在實作與說明思路時無法準確說明，甚至把 exponent 的位數說成 10 位。

[後續 Follow up](/N4JLqbCyTtm4qrXw-oHGVg)
一對一討論共 2 次、課堂問答（進行議題後續追蹤） 2 次、課後討論 2 次，根據日期排序。

- 2026/05/15: 第二次一對一討論：回報期末專題相關研究發現
### 課堂問答軌跡
- 2026/03/31：課堂問答：ReLU bitwise 實作中 UB/IB 討論（Well defined / undefined behavior?）
    - [議題後續追蹤](https://hackmd.io/T9exGh0eRuuoVWkomO25wA?view#c8763yee)
- 2026/04/21：[向講者邱冠維與授課教師詢問 Maintainer 長時間不活躍時的處理方式與 Google 內部對於 MGLRU 的後續方向](https://hackmd.io/gdgKXMGYRdaNUgsEBKaypg#%E5%95%8F%E7%AD%94)
- 2026/05/07：課堂問答[(議題後續追蹤)](https://hackmd.io/fkFn7pWwR0i3E4Eo2-epuw#c8763yee)
    1. 為什麼 `pthread_create` 建立執行緒時要有對應的 Stack？
    2. Kernel preemption 對於 Consumer Electronics 的重要性
    3. `pthread_self()` 回傳值代表什麼？
### 課後討論

- 2026/03/03：課後向授課教師詢問上述 Kernel patch 提交與合併流程的疑問
- 2026/04/21：課後向授課教師詢問 COSCUP 與期末專題的題目選擇

### 一對一討論
具體紀錄請參考 [2026 Linux 核心設計行事曆](https://calendar.google.com/calendar/embed?src=embedded.master2015%40gmail.com&ctz=Asia%2FTaipei) 中標記 `一對一討論：c8763yee` 的活動


- 2026/04/27：第一次一對一討論：詢問期末專題題目方向

在本次一對一時被問到如何使用位元運算來實作浮點數除二，當時由於對 IEEE 754 格式的過度思考如何處理 Infinity 與 NaN 導致在實作與說明思路時無法準確說明，甚至把 exponent 的位數說成 10 位。

會後被要求將針對 Infinity/Nan 的 special case 檢查去除，與改用避免 UB/IB 的 union 實作來取代當下使用的 `memcpy` [(Follow up 紀錄)](https://hackmd.io/@c8763yee-/fdiv2-followup)。

- 2026/05/15：第二次一對一討論：回報期末專題相關研究發現


## 所見所聞所感

9 分
> 9 分

〈因為自動飲料機而延畢的那一年〉 心得 :
〈因為自動飲料機而延畢的那一年〉 心得：
> 為什麼會出問題呢？因為這裡是他媽的真實世界啊。
> 大多數人一直活在本來就應該這樣嗎的童話世界裡，電視打開就可以看，機車買來就可以騎，手機買來就可以用，一切都理所當然，本來就應該這樣。偶爾買到不好用的商品我們就抱怨幾句，丟掉換其他更好用的牌子，卻很少意識到那個本來就該這樣，背後需要經過多少人月的投入與研發。

## 自我評量 (1 ~ 10)：

$GEOMEAN = ( 9 \times 7 \times 5 \times 7 \times 9)^{1/5} = 7.236527563504052$
### 關於數學與謹慎用詞
一開始因為就學期間忽略數學的重要性，導致光是在進行作業一的「探討〈解讀計算機編碼〉」題組時在補充缺失的數論知識就花了 3 天，因此導致後面只能針對程式語言的題目進行作答，同時持續補充之前沒學好的數學知識。這樣的結果是在第三次作業時只能先紀錄閱讀教材時的發現與問題。

方案 B ：$1 + floor(GEOMEAN) = 1 + 7 = 8$
不過也是在進行作業撰寫時開始注重詞彙的使用，帶來的影響是在撰寫文章時，針對文章中可能有岐義的漢語用詞主動查詢[資訊科技詞彙翻譯](https://hackmd.io/@sysprog/it-vocabulary)與使用 [zhtw-mcp](https://github.com/sysprog21/zhtw-mcp) 檢查資訊科技詞彙翻譯中未提到的部份用語。因此意外發現不明使用者使用 AI 「抄襲」 zhtw-mcp GitHub repo 這件事並沒有那麼簡單，該使用者還在 repo 中放入病毒檔案並在 README.md 引導下載。
([Hexastrike 對於類似案例中攻擊行為的分析](https://hexastrike.com/resources/blog/threat-intelligence/cloned-loaded-and-stolen-how-109-fake-github-repositories-delivered-smartloader-and-stealc/))。

### 關於與上游開發者互動
第一次送出 LKML patch 時, Borislav Petkov 直接退回 Commit 並指出 Commit 訊息太過繁瑣的問題。修正 Commit 訊息後發布 v2 patch。不過後續即杳無音訊。在第二周課後向授課教師詢問相關問題時得知 maintainer 對於這種 trivial patch 不會太重視，並告知我可以向邱冠維詢問相關的問題。

> > This just fixes the misleading comment. No functional changes.
> > 
> s/This just fixes/Fix/



### 關於自身投入的回顧
即使只是修改 Typo 或是用語，但畢竟「勿以善小而不為」。
## 分數計算


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

幾何平均 (GEOMEAN) 計算 
$$ GEOMEAN \ = \sqrt[5]{9 \times 7 \times 5 \times 7 \times 9} \ = 7.236527563504052
$$

驗算: $| 7.236527563504052^5-(9 \times 7 \times 5 \times 7 \times 9)| \ll 1$, 符合定義

方案選擇:
- 方案 B: 1 + floor(GEOMEAN)
- 1 + floor(7.236527563504052) = 1 + 7 = 8

自我評量總分: 8 / 10