# 2025q1 Homework1 (ideas)

contributed by < `JUSTUSVMOS` >

---

## 一、從 CFS, EAS, 到 EEVDF : `Kuanch`, `devarajabc`

### 收穫

1. 發現「理想」和「現實」常常有落差。
比如 CFS 說要讓大家都公平用 CPU，但如果任務太多，還是有人會等很久，無法真的完全公平。

2. 評估排程器好壞不能只看一個數字。
除了「快不快」（throughput）、回應速度、也要注意「公平性」、「會不會有人被餓死」，還有省不省電、能不能好好分配 CPU 給不同使用者（group scheduling）。

3. 多核心和記憶體分區真的會影響 CPU 如何分配工作。
現在的電腦越來越複雜，要考慮很多硬體細節才能設計出好的排程演算法。

4. 用 trace 和 GDB 這些工具能「親眼看到」Linux 裡任務是怎麼排隊、怎麼搶佔，這讓我對系統內部更有感覺。

---

### 學會用「系統性」的角度想事情

* 不再只是死背排程演算法名字，而是會去想：

* 這個演算法是為了解決什麼問題？
* 現實裡跑起來真的如設計時想的那樣嗎？
* 不同硬體（單核、多核、不同記憶體結構）會不會有不同表現？

* 碰到問題，會想從設計、實作、現象三方面去查原因。

---

### 遇到的疑惑

* **CPU 分配方式到底有哪幾種？**
比如 kernel 的 CPU affinity、cpuset、isolation…這幾個有什麼差別？是一起用還是互相取代？什麼時候適合用哪一種？

* **big.LITTLE 和 NUMA 架構下，這些排程設定還管用嗎？**

---

### 改進

1. 用不同的 CPU 架構做比較
不只用 x86（PC），也可以用 ARM（手機、樹莓派）、RISC-V 這種新架構的機器。
用 QEMU 這種模擬器，可以在同一台電腦上跑不同 CPU 架構的 Linux。
比較 CFS、EEVDF、BORE 等不同排程器在這些平台上的表現，看誰在什麼情境下最好。

2. 測試不同硬體組合
嘗試單核、多核、8核、16核，甚至 NUMA、big.LITTLE 結構，看看這些排程器會不會在新硬體上表現不一樣。
可以設計不同的壓力測試（讓很多任務一起跑），然後記錄效能、反應速度、公平性、功耗等數據。

3. 進一步工具應用與改善
學會用 trace-cmd、perf、ftrace 等工具，做出更有說服力的實驗和比較。
如果遇到實驗數據或現象看不懂，可以結合 trace 結果和 kernel code trace，更快找出原因。

---

## 二、還政於民的 sched\_ext 及機器學習如何幫助 CPU 排程 : `vax-r`

### 過程中的認知

1. **設計和現實的差距**
學到的第一個重點，是排程器的理論（公平、即時回應…）和現實運作常常有落差。例如：CFS 強調公平，但只要負載太高還是會有人「卡住」。

2. **評估方式很多元**
一開始只會看 throughput、延遲，但其實還要考慮「耗電」、「資源分配」、「對不同任務的公平性」…這些新議題。

3. **硬體的進化帶來新挑戰**
像 big.LITTLE、NUMA、多核等架構，排程要顧的細節變多。單純的理論很難直接套用到現代電腦，需要硬體和軟體一起思考。

4. **trace 和 profiling 很重要**
學會用 trace-cmd、perf、ftrace，能看到任務怎麼排隊、切換，這讓我更直觀了解排程器裡發生什麼事。

5. **系統性思考**
從設計、實作到實際效能，三者必須串起來思考；單靠理論或單看數字都不夠。

---

### 遇到的疑惑

1. **不同層級的 CPU 分配機制很混亂**
Linux 有 CPU affinity、cpuset、isolation 等設定，這些到底什麼時候會互相影響？有時候改了 affinity，cpuset 又會打架，很難搞清楚。

2. **自訂排程器很難、也有風險**
要讓排程器適合特殊應用，直接改 kernel 很容易踩到坑，也不容易跟上主線 kernel 更新。這就是為什麼 eBPF 可插拔排程器（sched\_ext）這麼被看好。

3. **負載平衡很複雜**
有時候系統為了負載平衡搬來搬去，搬太多反而影響效能。什麼時候該追求極致平衡、什麼時候該適度妥協，這很難有標準答案。

4. **機器學習加進來會不會更好？**
有研究用 ML 來學 can\_migrate\_task() 的判斷，有時候搬遷次數變少、效能也變好，但有時候 overhead 又太大，還得考慮輕量化和實用性。

5. **cgroup 排程還沒搞懂**
只知道它跟資源控制有關，但它對排程器到底有多重要？如果想支援更複雜的場景，是不是一定要學會 cgroup 相關設定？

6. **怎麼分析一個 task 的特性**
除了「CPU 吃很重」或「IO 吃很重」，是不是還能分出更多細項？這會不會影響怎麼設計排程演算法？

---

### 改進

1. 比較不同 CPU 架構和平台
不只在 x86，還可以用 QEMU 跑 ARM、RISC-V，測試 CFS、EEVDF、BORE、sched\_ext 下各種 workload 的表現。

2. 導入機器學習試著改進排程器
參考論文用 ML 替換 can\_migrate\_task()，比較傳統和 ML 方法下的搬遷次數、效能，看看能不能找到更佳平衡。

3. 改善負載平衡的指標與決策
不要盲目追求所有 CPU load 一樣，考慮「任務實際完成速度」這個最重要的指標，思考什麼場景才需要 aggressive 的負載平衡。

4. 學會用各種工具輔助分析
MangoHud/vapormark 分析 FPS、perf 分析搬遷次數、mpstat 分析 CPU load，這些工具要能靈活運用。

5. 學會看 sched\_ext 新 branch
持續追蹤 Linux kernel 社群 sched\_ext 合併與進展，熟悉新架構與新功能。

---