分享到plurk 分享到twitter 分享到facebook

版本 6b7491d37b209783a362adbf48e3e695501e7ddd

User/Stanley0915

Changes from beginning to 6b7491d37b209783a362adbf48e3e695501e7ddd

## 2026 年 Linux 核心設計課程自我評量
姓名: 劉冠頡
GitHub 帳號: Stanley0915

本自我評量依據課程要求,分別整理成果發表與貢獻、作業與隨堂測驗、期末專題、與授課教師互動,以及本課程所見所聞所感。所有評分皆為 1 到 10 之間的整數,並以公開紀錄、commit log、pull request、討論串、issue、課程頁面或期末專題頁面作為佐證。



---
### 成果發表與貢獻
自評分數:10 / 10

Linux 核心設計: 
* Scheduler(4): PELT教材中:
    *  解說**accumulate_sum**那段:用來計算計算 sched_entity 對 load 的貢獻,在進入程式碼前,讓我們先來看看註解提到的考量點。這一行多了一個計算,應該修改成PELT中:accumulate_sum 用來計算 sched_entity 對 load 的貢獻,在進入程式碼前,讓我們先來看看註解提到的考量點。

    * 在**PELT 的額外考量**那段:系統除了維護所有 runaable task 造成的 load(runnable load) 之外,runaable應該改為runnable
    * **PELT 的額外考量**那段:其 load 會再轉轉移到 runnable。更細節的運算流程我們會在後續的程式碼中去探討。多了一個轉,語意不對。
    * **PELT 的效益**:那一段:`load balacing`拼錯,應修正為`load balancing`
    * __update_load_avg_cfs_rq:下方的程式碼部分`cfq_rq:` 應該改為`cfs_rq`
    * ___update_load_sum:下方解釋的文字中: ___update_load_sum 會將 shced_avg 的 _sum 相關數據進行更新,`shced_avg`拼錯應改為`sched_avg`

以上為對於老師教材做出的貢獻。

---
### 作業 / 隨堂測驗
自評分數:9 / 10
課程作業每日規定自己投入3小時,一周七天總計是21小時。高於老師在自我評量範例中的20小時標準。
* 閱讀你所不知道的C語言指標篇,並回答所有題目,為了熟練指標篇的知識,多去練習指標相關頭腦體操
* 你所不知道的 C 語言:數值系統篇,關於`0.1 + 0.2 ≠ 0.3`的細節藉由教材得知其原因,是因為mantissa 在表示 0.1 時最後一位因為 Rounding變成了 1這份細小的誤差就會導致0.1+0.2不會等於0.3
* 你所不知道的 C 語言: bitwise 操作,去了解如何推導 $abs(n) = ((n >> 31) ^ n) - (n >> 31)$ 能正確計算絕對值,並了解branchless寫法的優勢何在。

在模擬驗是中:檢討當時無法答出的問題,包括:False Sharing、FPU State、SIMD State、哪些內容可能採用 Lazy Switch?PELT 如何估算。


---
### 期末專題
自評分數:8 / 10
我的期末專題聚焦於 Linux 核心在 Cortex-M / NOMMU的環境下測量系統資源開銷並改善,需要保有必serial console 可登入與互動 shell、noMMU + FDPIC userspace、shared uClibc-ng 與動態連結、BusyBox 最小 shell / coreutils、NPTL 或 pthread 相關可行性驗證
[Linux 核心設計專題: 測量系統資源開銷並改善](https://hackmd.io/@sysprog/B1ImJFdRbe) 專題筆記連結
**baseline測量:**
* 測量vmlinx的baseline
    ```
       text    data     bss     dec     hex filename
     599088  402804   32128 1034020   fc724 vmlinux
    ```
* 在/proc/zoneinfo裡可以看到開機到 shell 後,kernel managed memory 中已使用約 1.29 MiB。
* 驗證動態連結 (Shared uClibc-ng) 與 FDPIC` # cat /proc/1/maps`
* 使用 validate-qemu.sh 搭配 metrics 輸出量測。本次結果為
boot_marker_ms = 285 ms,shell_ready_ms = 298 ms。

**關閉功能:**

從rollup找可以減少的地方,在printk中分析剩下的功能
rollup 顯示 nbcon.c 佔 3352 bytes,Makefile 顯示 CONFIG_PRINTK=y 就會編 nbcon.o
在思考或許可以多新增一個config標籤在確保printk其他功能正常的情況下,關必nbcon的編譯
```
 Before:
text = 599,088
data = 402,804
bss  = 32,128
dec  = 1,034,020

After CONFIG_PRINTK_NBCON=n:
text = 592,660
data = 402,612
bss  = 29,024
dec  = 1,024,296

Saving:
text -6,428 bytes
data -192 bytes
bss  -3,104 bytes
total -9,724 bytes
```
CONFIG_PRINTK 保留,serial console 仍可用;
CONFIG_PRINTK_NBCON 關閉,移除 MPS2 target 不需要的 nbcon infrastructure;
實際 boot artifact linux.axf 減少 8 KiB。

**後續作業:**
預計到8/31以前都會持續更新此專題,上次和老師討論後發現自己有很多基本知識的不足,目前以補充記憶體管理與slab記憶體配置器方面的知識,位後續改進專題鋪路。

**關於實驗設計**
Linux 核心相關實驗中擁有明確的baseline是實驗中最重要的一環,以此才可以分辨是否在系統優化的過程中,有達到正確的效果。在期末專題中,光是測量baseline就有很多資料,包跨開機的時間,runtime RAM,vmlinux 區段與開機記憶體對,照功能覆蓋率都需要測量,在改進整個系統後也要比較之間的差距,是瑣碎但重要的事。

**觀摩同儕專題並提問:**
1. clare8151214-在文中1.3.10 The Multiprocessing Challenge部分,圖片無法顯示。
2. seallllllllll-使用hrtime已達成更高精度。hrtimer的精度為為多少,是否可以涵蓋實驗所需的範圍。
3. PinkNekoFist-題目說量化效能瓶頸並展現,想看到改善後的差異,或是baseline的數據。在筆記中不太知道哪些是baseline數據。
4. rainbow0212-UEFI段落圖片顯示有問題。
5. kstoko02-在測試二中為何選擇4 個三角錐 v.s. 4000 個三角錐進行測量呢,設定這樣的比例跟數字背後有什麼特殊的原因嗎。

---
### 與授課教師的互動

自評分數:9 / 10

在6/23進行模擬面,問題為面試問題中第三題,第五題與第11題。
關於False Sharing、FPU State、SIMD State、哪些內容可能採用 Lazy Switch?PELT 如何估算。這些題目當時沒有回答出來(參考當時的錄音內容。)
更正的內容更新在模擬[面時回答](https://hackmd.io/@ZU1tZZz8RSWZjRM0B3zdHg/ByXJT3_QGe)的筆記裡。

跟老師的互動除此之外都是課後當面找他討論所以沒有日期與紀錄。
但在討論時老師有分配給我問題,是關於在no FPU的系統中,如何計算expm1(X)函式,在一開始繳交筆記時被老師說沒以嚴謹的實驗跟程式碼證明,學習到對於回答問題的嚴謹態度。並根據老師[歐拉數 :描述連續變化的基石](https://hackmd.io/@sysprog/euler-number)的筆記重新學習




---
### 所見所聞所感
自評分數:10 / 10

閱讀〈因為自動飲料機而延畢的那一年〉後,我感受到他對於目標的覺悟跟在解決冰塊機時詢問老師後的答案,為了完成想要的專題甚至延畢半年,這讓我了解到了對於一件事如果沒有決心跟願意失去時間和失去歡樂的勇氣那也無法成就什麼事,就像老師常常在課堂上說的幹大事or nothing,既然都深為工程師了那就要有這樣的自覺,要想辦法翻身。
而冰塊機解決方法對點醒我是老師說的,在漫長的歷史中,很多東西其實都已經有人解決了,讓我聯想到在跟老師討論期末專題時還有在跟老師討論一對一問答時,一開始都是自己埋頭苦幹想或是問AI,導致一直在原地打轉,但很多答案跟想法老師的教材中或是網路上的開放資源都其實有答案了,即使沒有答案也有相對應可參考的做法,應該要多攝取知識才可以解決問題。如期末專題中,要改善跑在stm32上nommu系架構的linux作業系統。勢必要先閱讀記憶體管理與slab的記憶體配置方式,才有想法來繼續改進。


**關於實驗設計**
Linux 核心相關實驗中擁有明確的baseline是實驗中最重要的一環,以此才可以分辨是否在系統優化的過程中,有達到正確的效果。在期末專題中,光是測量baseline就有很多資料,包跨開機的時間,runtime RAM,vmlinux 區段與開機記憶體對,照功能覆蓋率都需要測量,在改進整個系統後也要比較之間的差距,是瑣碎但重要的事。

**觀摩同儕專題並提問:**
1. clare8151214-在文中1.3.10 The Multiprocessing Challenge部分,圖片無法顯示。
2. seallllllllll-使用hrtime已達成更高精度。hrtimer的精度為為多少,是否可以涵蓋實驗所需的範圍。
3. PinkNekoFist-題目說量化效能瓶頸並展現,想看到改善後的差異,或是baseline的數據。在筆記中不太知道哪些是baseline數據。
4. rainbow0212-UEFI段落圖片顯示有問題。
5. kstoko02-在測試二中為何選擇4 個三角錐 v.s. 4000 個三角錐進行測量呢,設定這樣的比例跟數字背後有什麼特殊的原因嗎。







---
### 分數計算



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

幾何平均 (GEOMEAN) 計算:

$\text{GEOMEAN} = \sqrt[5]{10 \times 9 \times 8 \times 9 \times 10} = \sqrt[5]{68400} = 9.168$

方案選擇
選擇方案B
1+9=10
自我評量總分: 10 / 10