2025q1 Homework1 (ideas)

contributed by < BigMickey69 >
所有紀錄來自觀看「成果展示錄影 (上)」與「成果展示錄影 (下)」

1. 從 CFS, EAS, 到 EEVDF : Kuanch, devarajabc

Feb 23, 2025

別說理解了，看之前對 CFS, EAS, EEVDF, Kuanch, devarajabc 等專有名詞一無所知。這是第一個報告的專題，所以我相信大多數人ideas作業也都會紀錄這題。

CFS - Complete Fair Scheduler

EEVDF - Earliest Eligible Virtual Deadline First

EAS - Energy Aware Scheduling

知道了本專題探討的應該是排程器。

CFS

CFS如同英文名會盡可能的依任務權重比例去平分 CPU 資源，最小 vruntime(virtual runtime) 的任務優先獲得 CPU

問題：
這樣的分配資源或許在處理程序上問題不大，但對使用者的體驗可能會很差，會感覺卡頓、不舒服。

只使用 vruntime 無法表達 CPU 時間的偏好

EEVDF

看到這個排程器的英文名大概就猜得出它的邏輯，優先分配 CPU 給 deadline 最為緊迫的任務

Nice 與 Latency-nice
Nice -> 表達任務大概要耗多少 CPU 時間
Latency-nice -> 表達任務對 CPU 頻率上的需求（AKA 應多常被 CPU 顧及）

簡報中 Deadline = Nice + Latency-nice
猜測實際上公式絕對不會這麼簡單，要找到一個能套在大多數情況，這件事本身也可以是一個專題了

問題：
簡報中並未提到任何潛藏的問題，有點奇怪

我預想可能的問題：
假設同時擁有很多 deadline 緊迫的小程序與一個deadline 比較寬鬆的大程序，那大程序就一直不會被處理，直到它的deadline逼近， CPU 資源可能會卡在那邊無法顧及其他程序，危害到使用者體驗

EAS

！！！不是排程器！！！
同樣看英文明就能理解它想成的目的。考量程序的難易度、緊迫程度，再決定交給哪一個 CPU 核心處理。

大核比較強大，但也會需要消耗更多功耗
小核的能耗比會比較好

TL;DR 就是選核啦

結論：

我認為這個報告太短也講太淺，只有非常概略的解釋幾個排程器的邏輯與目標，沒有入解釋實現方式、探討更多潛在問題與情境，也沒有提到任何或許能優話排程器的方式。報告中沒有出現"聽不懂"的狀況，而是同學講的過於淺導致我們只能很表層的理解。

這組的下兩組的報告：「還政於民的 sched_ext 及機器學習如何幫助 CPU 排程」與「EEVDF 相較於 CFS 的量化比較 」就精闢了一點。若能深入探討邏輯、原理，並在這些基礎上再加上自己的想法，並提供許多數據與想法等（幾乎重作一個報告），就能更好。

2. EEVDF 相較於 CFS 的量化比較 : ShawnXuanc

Feb 23, 2025
一開始先解釋 CFS 與 EEVDF 分別是什麼。
EEVDF 中提到了 Lag value ，第一組沒講到的概念。 Lag value 表示預計與實際得到時間的差
有看到一則留言補充 EEVDF 除了 weight 還會根據request size(time slice) 來決定 CPU 資源的分配

報告講的比較詳細，發現自己有時會倒帶重聽。EEVDF 跟 CFS 一直讓我聯想到公民中的形式平等v.s.實質平等 。

這組有真的去做實驗並搬出數據，在一個好的報告中這是理所當然的，但還是值得鼓勵。

報告中的實驗數據，使用Schbench
後面又用到了Schedgraph來看排程器的排程表現

結論：

這個報告前面不錯，但還是過於隴長。他們想表達的 EEVDF 與 CFS 大概第二組數據就已經很明確了，但後面又搬出了好幾組乍看之下不一樣但實際上差不多的圖表。一直有種鬼打牆的感覺。

講了很多也確實很明確，但到頭來並沒有提供任何新東西，沒有創新沒有優化，我認為此專題還有進步的空間。

3. 開發具體而微的 Linux 檔案系統 : HotMercury, jason50123

Feb 23, 2025

專題名稱是 SimpleFS（Simple FileSystem）

簡報中的圖

第一次看到 VFS、Block I/O Layer、I/O Scheduler等名詞，報告中並未解釋。

查到的粗略解釋：

• VFS (Virtual File System) Layer
  – The medium for applications to interact with files uniformly
• Block I/O Layer
  – Translates Filesystem Requests into Block Device Operations
• I/O Scheduler
  – Optimizes Disk I/O Requests

第一次看不知道 IOPS、Issued rwts 等名詞是什麼的縮寫

IOPS -> Input/Output Operations Per Second
Issued rwts -> Issued Read/Write Transactions

所以這位同學的 SimpleFS 的 IOPS 與 rwts 較大，表面上較快，但 CPU 使用率卻高不少，代表效率上會略輸一些

感覺在講檔案系統的結構，但這邊整個都沒學過，不理解

查的資料：
Superblock → Stores filesystem metadata (block size, number of inodes, etc.).

Inode Store → Contains inodes that map filenames to storage locations.

Inode & Block Bitmaps → Track free/used inodes and blocks.

Extent Blocks → Point to where actual file data is stored.

Data Blocks → Contain the raw data written by the user.

Journel

我認為 Journel 就好比一個 priority queue ，執行動作時都是根據 Journel 並 FIFO 。我暑假時有實做過個非常沒品味但勉強能用的雲端硬碟系統/網站，利用 Discord, Discord bot, Python 跟 sql 做的，當中也有用到很類似的概念。

講者有講到已知 BUG 跟未來的規劃，最後還有個 QA，做的很好。

結論：

我覺得目前最有趣的一個專題，讓我對 Filesystems 燃起了一點興趣。我 Google Keep 中有個記事本紀錄著 這堂 Linux 期末專題的任何想法,看完這個後有個電燈泡亮了便寫了以下這條（先不論實際行不行或是合不合理） —
"A simple and intuitive File system with the goal of streamlining connections between files through the web and locally. Using a simple set of rules and instructions that's open source to actually connect, making it easy for anyone to modify or use."

4. 高性能網頁伺服器 : fatcatorange

Feb 23, 2025

本專題重點：CMWQ

問題：
每當有新連線時，創建一個新的執行緒來服務該連結。若有大量連接需求時就得花大量時間創建執行緒。

講者說 CMWQ 事先建立好一些執行緒，在任務需要時再配過去，從而省略建立執行緒的成本。

功能之 - Directory listing

網頁伺服器想當然需要能穿梭各個 Directory ，講者講到原本會一個一個檢查子目錄並依序回傳給連接端，但這樣很沒效率。

所以後來引用了快取的概念，因此只要載入一遍，但這樣第一次打開還是得一個一個傳，而且若目錄中有變更就得重新快取。

是我的話可能會有個檔案或紀錄之類的把子目錄全部包起來，任何變更也會變更這東西。當 request 進來時再整個傳過去。

講者自己有提到很多地方使用 spinlock 而拉垮了整體速度，勇於指出自己的缺點。

結論：

與我之前做過的雲端硬碟系統/網站非常相似，也跟我自己遇到的問題有些重疊，但當時我並不是重視性能，許多地方都有偷工減料、能不做就不做，反正能用就好。最後導致整個專案的程式碼宛如義大利麵，若要扎實的做好就得整個打掉重來。

整體介紹的不錯，目標與原理明確，但我自己覺得簡報有些小無聊，我會多加一點顏色或是圖片。

我認為此專題最大的問題是少了個「賣點」，沒有一個特別突出的特點或是花樣，沒辦法另聽眾感到新奇。

若我期末真的做了個 Filesystem，我會想盡量讓它跟我之前的那個破專案做個連結看看。

整體而言我認為沒有什麼特別亮眼的地方，但每件事都有交待好，也很清楚解釋了原理與邏輯，也看了一點點程式碼，不錯！

5. 建構 RISC-V 相容處理器並運作 Linux 核心 : millaker

Feb 23, 2025

看到這個，我的第一印象是覺得「哇好牛逼阿」，但更多是「how」? 這位同學是想從0設計並做出一顆處理器嗎？

這讓我聯想到一個我非常喜歡的老外yt頻道: JDH (https://www.youtube.com/@jdh)
其中有兩部影片就在講這個，從0開始設計一臺 8-bit 電腦，從電路設計到寫 CPU 指令集、作業系統、自製程式語言、編譯器、IDE
最後再寫個 PONG 並在上面遊玩
當時看完這部影片我下巴掉到了地上，是個我很崇拜的人，但這就有些扯遠了
（整個頻道都是些很酷的小專案，基本上都只用C語言）

第一頁看不懂的名詞： rv64/32, OpenSBI

RISC-V:

• RV32 is used in embedded systems, low-power devices, and microcontrollers.
• RV64 is used in high-performance computing, desktops, and servers (similar to x86-64).

OpenSBI:

• Provides a firmware interface (SBI) between the OS and hardware. (AKA BIOS)

qemu -> free & opensource 硬體模擬器

這邊一口氣好幾個沒看過的名詞縮寫 👇

- ZSBL (Zero-Stage Bootloader) (影片中有解釋)
- UART (Universal Asynchronous Receiver-Transmitter): 
    - Serial communication protocol used for early debug messages and logging.
- SPI (Serial Peripheral Interface): 
    - High-speed serial communication protocol used to connect microcontrollers with peripherals.
- SD/MMC Init:	
    - The process of preparing an SD card or MMC storage for data access by the bootloader.

講者提到這是他遇到的大大難關，一直遇到 Timeout 問題，自己又不熟 C# 。最後解決方法是直接把 retry 次數限制刪掉，聽到時我是覺得蠻好笑的。不只是寫程式，只要扯到電腦很多時候會遇到一些不應該出錯而出錯的地方，也很多時候解法的邏輯也非常奇怪，因為太貼近現實所以覺得好笑。

結論：

這個專題感覺規模很大，一定花了非常多時間嘗試再嘗試。就如同講者所言，硬體方面（CPU）宛如黑箱，即便在腦袋中邏輯上是通的也不代表現實中不會有問題，出問題時還得猜是硬體還是軟體出問題。

最後他還有提到未來願景、可能改進的地方，這點很好。

我非常佩服這個專題，也自己對這個也蠻有興趣的，即便只是聽也能感覺到背後的心血與所需工程量，中間究竟熬過了幾個夜晚才能有這樣的結果。但也因為這專題這麼好，才會顯得簡報有些不足。感覺還是過於單調，得更有色彩、圖片才好，某些地方再講細一點才好（CPU 部份更是直接被跳過）。

6.打造具備網路連線的精簡虛擬機器 : jimmylu890303

Feb 24, 2025

KVM -> Kernal-based Virtual Machine

講者有講到本專題是建立在他人的專題之上，有些人擴充他的作品後會宣稱整個為自己的作品

雖然報告中一直出現新的概念與名詞，膽講者總是會依依解釋清楚，我自然也不用再去查資料

結論：

講者口條清晰、簡報精緻也富有有色彩，報告中每件事都交待得很清楚，不會太深入去講任何細節，把重點放在正確的地方。

講的太順導致我也沒紀錄些什麼，只是心中覺得他報告得很不錯。結束時教授有補充到一點，說講者他原本對 Linux 還蠻陌生的，當時5月初在討論題目時有點怕怕的，但一個多月就順利解決了。

「只要有心學習，即便只有一個多月，很快就能弄出來！」

7. 開發無線網路裝置驅動程式 : jychen0611

Feb 24, 2025

本專案原是2021年教授為了 Linux 暑期課程寫了個300多行給同學當練習，而後續有越來越多同學投入，讓專案變得有趣，而在2023年的 Linux 基金會發表成果。

以上是講者為此專案所作的貢獻

更新至 Linux 6.8

• 我的理解：講者編譯程式後出錯，再去把錯誤修正好，不論是語法更新還是已棄用的程式

Emulate rates and MCS

• MCS (Modulation and Coding Scheme):
  • MCS defines the data rate and error correction coding used in Wi-Fi (802.11) networks.
• 電磁波利用波形來表示 bits
  0° → "00"
  90° → "01"
  180° → "10"
  270° → "11"

  另一種標準是45°, 135°, 225°, 315°

implement vwifi_{set, get}_tx_power

• 用公式表示訊號強度與距離＆障礙物的關係，應該是從自弗里斯傳輸方程推導而來的

Implement ad-hoc(IBSS)mode

IBSS -> Independent Basic Service Set

這邊應該是本專題的精髓了，ad-hoc 又稱 IBSS ，在進入 IBSS 網路後它就能看到同個網路下的 IBSS 裝置溝通，不需要特別做連線。

接下來講著 ad-hoc interface type，再來是 IBSS 怎麼加入與離開，join 跟 leave 的函式。

再來是封包傳遞的部份，得確保 source 與 destination 存在於同一個 BSS(Basic Service Set) 之中

裝置掃描

這些地方講者都交待的很好，只是我自己背景知識實在不足，大致原理與架構都懂，但實際上的任何細節和如何實現等還不明白。查一個不懂的概念的資料，就會多兩到三個不懂的概念與名詞。我想剛開始學都是這樣的，只是有時多少會覺得有些無助。

結論：

簡報精美，富有圖片與顏色，內容豐富、解釋完善，專題本身也蠻有趣的，實在無可挑替。
其中有些內容與張燕光教授曾經也有非常概略的講過，當時在討論專題可能的方向，明年開始實做。