# 2025q1 Homework5 (assessment)
contributed by < `TING0419` >

:::danger
注意細節
:::

## 因為飲料機而延畢的那一年 && 課程反思
以下這段反思皆是我一個字一個字打出來的，並無使用任何大語言模型協助。

**『 儘管世界如此殘酷，但人卻不一樣，當你真心想做到一件事，付出足夠的犧牲，這個世界會聽見並做出回應，周遭的人漸漸願意相信你、花時間幫助你，你的付出並不見得會有結果，但是加上許多人的幫助，可能一切就不一樣了。』**

這是我在這整篇文章中感觸最深刻的一段話，不知道是因為大學時待在舒適圈太久，還是因為已經忘記自己的理想與目標，越來越排斥學習新的東西，遇到難題就會想逃避。但本篇文章的作者卻是主動跳出舒適圈，主動延畢去實踐自己的理想，我認為就算最後他失敗了，但這段經歷也會成為他人生中成長的養分，

而在修習這堂課時我漸漸找回自己的學習熱忱，講師講的幾句話讓我猶如醍醐灌頂『我們做的東西是要給千千萬萬個人使用的。』以及『 你沒有什麼好跟我說對不起的，因為你該說對不起的人是那些納稅人。』，從第一堂課開始我就開始認知到自己的不足，但我這次選擇的並不是逃避，而是去面對問題及自己，遇到 Bug 不懂就查規格書，數學不懂就要去把公式弄懂，但也是因為這樣所以在作業的進度上面我始終落後，不過我知道現在的我在對的方向上，逐漸從理論走向實務，深刻感受到「融會貫通」的重要性。

在每一次的作業中我認為老師都不只是要讓我們練習 Coding ，而是要讓我們思考設計的完整性、錯誤處理、效能、以及可維護性，在作業中就連 Commit Message 都有嚴格的規定，這讓我們養成好習慣，因為一個大型的專案並不會只有一個作者，不能寫一個只有自己看得懂的 Commit Message ，養成這個好習慣才可以讓別人更容易了解這些程式碼的作用是什麼。

而觀摩其他同學的成果與程式碼風格也給我非常多的啟發，因為我在修習這堂課之前並無碰過任何大型專案，所以寫出來的程式碼基本是不會做任何優化，但在觀摩了其他同學的程式碼之後，我會有種恍然大悟的感覺，會心想：『原來這樣寫可以更節省記憶體空間和時間複雜度。』，有時候我對作業要求沒有方向的時候，我也會先選擇觀摩其他同學的想法，且思考有沒有更好的解法，再去完成自己的作業，我認為程式設計最一開始的學習方向就是模仿，但不是照抄，因為我自己在看到其他人的想法後，會激發出我更多的靈感。

總結到目前為止的學習歷程，我認為這堂課不只是在教我們 Linux 核心設計 ，更像是在教我們如何成為一個合格的工程師，所有事情都必須從小細節做起，不管能力好壞，但至少經手過的程式碼不能造成別人的困擾。

## 回顧學習狀況
### 第一週
在第一週的時候，接觸到第一份作業 lab0-c ，有將 queue.c 完成 ，且閱讀 `Dude, is my code constant time?` 該篇論文，學習使用 Git 與 GitHub 及 Linux 相關開發工具。

在讀完 `Dude, is my code constant time?` 這篇論文後，我就在想那如果我們把問題延伸到作業系統上，作業系統有沒有機會達成 constant time 的實作，但在查了相關資料後，發現這是不可行的。
原因如下：
1. **作業系統必須處理非預期事件**
* OS 的核心職責是對不確定的世界做出反應：
中斷（IRQ）隨時可能來自鍵盤、網卡、時鐘、IO 裝置
任務的執行時間不固定，可能被 preempt
使用者行為與輸入不可預測
2. **作業系統的邏輯依賴資料結構與執行時狀態**
* Linux 的 CFS scheduler 使用紅黑樹（O(log n)）
* 記憶體管理使用 page tables、slab/slub allocator
* 處理器資源管理依賴當前的核心數、task 數、load balance 情況
3. **作業系統依賴的硬體平台本身不穩定**
現代 CPU 的行為取決於：
* cache hit/miss
* branch prediction
* speculative execution
* power states (e.g. DVFS)
* SMT thread interference
4. **即使是 Real-Time OS，也只追求bounded-time 而非 constant-time**
如：FreeRTOS、Zephyr 等 RTOS 的目標是 Predictable worst-case latency 。

作業系統的本質是「處理變化、回應事件」，這與 constant-time 的固定行為、不依輸入變動設計原則相衝突。
因此，作業系統層級的 constant-time 實作，在理論上幾乎不成立，在實務上則缺乏意義。我們應追求的是：
1. Bounded latency
2. Worst-case analysis
3. Isolatable / rate-controlled behaviors

### 第二週
在 qtest 提供新的命令 shuffle ，透過小考內容更熟悉指標及 bitwise 操作，及記憶體配置。
### 第三週
嘗試理解 kxo 相關教材，學習 user-space 與 kernel-space 的通訊。
## 教材問題
[你所不知道的C語言: 未定義/未指定行為篇](https://hackmd.io/@sysprog/c-undefined-behavior)

:::info
在閲讀了這篇講義後，我有點疑惑在現代開發環境越來越注重安全性與穩定性的趨勢下，我很好奇 C 語言這種維持允許未定義行為以利最佳化的設計，是否仍然合理？還是未來語言應該更強調明確定義所有行為、甚至採用像 Rust 來取代 C 的部分角色？
:::

[現代處理器設計：原理和關鍵特徵](https://hackmd.io/@sysprog/cpu-basics)
[Arm 處理器筆記](https://wiki.csie.ncku.edu.tw/embedded/arm-smp-note.pdf)
[ARM架構](https://zh.wikipedia.org/zh-tw/ARM架構)
在傳統上 Intel 或 AMD 的 x86 架構為了追求高效能，採用極深的 pipeline、重度的 out-of-order execution 、強化 SMT、branch predictor 等手段，來克服指令層級平行度與記憶體瓶頸。
但近年 Apple 的 ARM 架構 M1/M2/M3 處理器，即便 pipeline 比較淺、核心相對簡化，卻透過設計上的整體協同（如強化 cache hierarchy、高效能 memory interface、以及合理的 core 數量與分工）實現了遠優於傳統 x86 的效能與功耗比。
:::info
這是否意味著現代處理器設計的主軸正在從「極限 ILP + 高時脈 + 深 pipeline」轉向「系統性思維下的效能最佳化 + 效能功耗平衡」？
那像 x86 這種傳統架構是否已經遇到架構上的發展瓶頸？
:::

## 專題發想
### 加速 BitNet
近年來大型語言模型如 GPT、LLaMA、Grok 等迅速成為 AI 推論核心技術。然而，隨著模型規模不斷擴大，其記憶體佔用與推論延遲成為部署瓶頸。傳統解法多仰賴 GPU，但 BitNet b1.58 主打極低位元權重（1.58 bits），使其可在 CPU 上有效運行，具備高度部署彈性與能源效率。

透過老師的在 [「Linux 核心設計」課程專題想法](https://hackmd.io/@sysprog/S18kgVDJex#加速-BitNet) 說明，我注意到 `BitNet` 雖然節省了權重空間，但其推論過程仍涉及大量權重資料的隨機存取，可能導致系統頻繁查詢 `page table`、產生大量 `TLB miss`。這將直接影響 `CPU` 的推論延遲與整體吞吐量。

因此，我希望透過 `Linux` 的 `Huge Pages` 機制，將 `BitNet` 權重映射至 2MB 或更大的 `page` ，藉此：
* 提升 `TLB` 命中率，降低 `page table` 查表開銷。
* 減少記憶體碎片，提升推論時的記憶體頻寬利用率。
* 評估此優化是否能實際改善推論延遲與 `throughput` 。

這個主題結合了我對人工智慧推論系統架構的興趣，以及在 `Linux` 記憶體管理與效能優化上的學習成果。期待能藉此深入了解系統資源對推論效能的影響，並提出可量化的優化方法。

### 模擬 GPU Telemetry 並整合至 OpenBMC 架構之實作

我會撰寫一個 kernel module，模擬 GPU 溫度與功耗感測器的行為。這些感測數據會透過 user daemon 收集並封裝為 D-Bus 感測器介面，供 CLI 工具查詢。整體系統將在 QEMU AST2500 模擬平台上運行，展現 kernel module、userspace daemon 與 D-Bus 的整合能力。

本想法旨在模擬 GPU Telemetry 感測器，並透過 OpenBMC 系統實作 kernel module、user daemon 與 D-Bus IPC 架構的整合，以建立一套完整的 Linux kernel 與使用者空間協作控制流程。透過此專題，我期望能達成以下學習目標：

* 熟悉 `Linux kernel module` 的撰寫與 `sysfs` 介面設計，模擬裝置行為並提供可查詢的系統層級資訊。
* 掌握 `D-Bus` 通訊機制與 `daemon` 的撰寫方式，實現 `kernel ↔ user-space` 資料流。
* 練習在 `Yocto` 架構中整合自訂模組與工具，理解嵌入式 `Linux` 系統的建構與部署流程。
* 強化系統整合與架構設計能力，建立跨 `kernel` 、 `user-space` 與 `IPC` 的功能性協作。
* 培養可重現、可展示、可擴充的模組化實作能力，提升後續投入 `OpenBMC` 、嵌入式系統或平台開發領域的基礎實力。

## 學習及工作效率低落
在接觸到這麼多新教材後，才發現這領域大的可怕也細的可怕，之前學習作業系統主要是使用 「恐龍書」這本書來幫助我理解作業系統，但現在卻覺得學以致用這句話離我越來越遠，就像是 **因為飲料機而延畢的那一年** 裡提到的那句話：「資工系的不會寫程式，機械系的不會機械，電機系的不會電工。」

這邊列出幾個我目前遇到的問題：
1. 數學程度不夠好
一篇論文要看到完全了解，需要大量的時間去理解數學式，甚至看懂數學式後還無法了解底層含義。
2. 實務經驗太少
一份專案裡面的一個小程式，約幾百到幾千行，就需要理解很長一段時間。
3. 遇到困難會想逃避