Try   HackMD

「Linux 核心設計」課程專題想法

歡迎編輯本頁面，增添你認為可利用 Linux 核心及其機制達到的效果，並附上相關資訊。

提案原則：

  1. 不見得能完整實作，只要能夠運用 Linux 核心的機制來解決問題，都值得列出
  2. 歡迎資訊安全、系統效能、儲存媒介/檔案系統、裝置驅動程式、視窗系統/圖形處理 (特別是 Linux framebuffer/DRM)、CPU 排程器、eBPF/XDP、虛擬化技術、電腦網路、多媒體、並行處理等題材
  3. 你沒空實作沒關係，課程有很多學員可幫你落實想法

加速 BitNet

在Linux上利用 huge pages 來提升 BitNet 大型語言模型的推理速度。

BitNet 藉由 1.58 bit 權重大幅降低記憶體需求，從而提高能源效率，其推理速度可達 FP16 的 2.7 至 4 倍。huga page 可減少 TLB miss、加速記憶體存取及降低 CPU page table 管理負擔，預期有以下益處：

  1. 降低推理延遲：因 2MB 或 1GB huge page 提升 TLB 覆蓋率，減少 page table 查詢，特別適合處理 BitNet 的大規模權重矩陣
  2. 提升吞吐量：改進記憶體頻寬利用
  3. 大模型擴展性提升：減少記憶體碎片化與 TLB 瓶頸

相關討論:

區塊裝置的快照

bdev-snapshot-service

藉由 Linux 核心模組，提供寫入時複製 (Copy-on-Write, CoW) 的快照機制與掛載前狀態還原能力，特別適合在需要保留區塊裝置原始狀態的情境下使用，例如以下：

  1. 測試或除錯時的暫時變更：當開發者或系統管理員需要在不永久修改區塊裝置內容的前提下，測試設定變更或安裝軟體時，此模組即可派上用場。作法是先將該裝置（例如 /dev/sda1）註冊至 bdev-snapshot-service，並在檔案系統掛載時建立 CoW 快照。使用者進行變更（如安裝軟體或修改設定），完成後卸載該裝置，模組即還原至掛載前狀態，僅復原被修改的區塊。這樣可在不需手動備份的情況下，安全進行實驗。
  2. 容器或虛擬化環境的重置需求：容器或虛擬機使用 loop 裝置或區塊裝置作為 rootfs，且每次執行後都希望還原為乾淨狀態。可將裝置註冊至快照服務，在容器或 VM 執行期間掛載並操作檔案系統。當卸載或停止執行時，裝置會自動被還原至原始狀態，無需重建映像檔或複製基底系統，特別適合 CI/CD、測試框架或短暫性任務。
  3. 教育或訓練環境的狀態重設：學員進行 Linux 操作練習，講師希望每次課程後能將系統還原。將每位學員的裝置或 loop 裝置註冊至快照服務，學生執行實作（如安裝套件、編輯檔案），結束後透過卸載還原其內容。此機制可大幅簡化實驗室管理工作，並維持各次課程的一致性。
  4. 鑑識分析或惡意程式測試：資訊安全研究人員在分析惡意程式或執行鑑識工作時，需保證原始磁碟狀態不被污染。可將分析環境所使用的區塊裝置或 loop 裝置註冊至快照服務，執行期間所有變動都經由 CoW 快照記錄。測試完成並卸載後，即可還原至分析前狀態，無需手動重建環境，也不會留下殘留副作用。

以下是典型測試案例的流程：

  1. 將 /dev/sdb1 或 /dev/loop0 註冊至快照服務
  2. 掛載檔案系統至 /mnt/test
  3. 執行操作，如安裝套件、修改設定或進行測試
  4. 卸載 /mnt/test
  5. 模組自動還原裝置狀態至掛載前版本，丟棄所有變更

監控和紀錄使用者命令的核心模組

R0DDY

開發運行於 Linux 核心層級 (Ring 0) 的 rootkit，具備命令記錄與隱匿功能，能在系統中悄無聲息地追蹤所有執行過的命令。其主要功能如下：

  • 隱匿模式：模組會自我隱藏，不會出現在 lsmod 等常見管理工具的輸出中，難以被偵測
  • 命令記錄：所有透過使用者空間執行的命令都會被記錄至 /var/log/cmd.log，紀錄內容包含：
    • 執行該命令的終端機 (TTY)
    • 當下工作目錄 (CWD)
    • 執行時間 (時間戳記)
    • 所執行的可執行檔或腳本
    • 完整命令列 (含參數)
  • 系統呼叫攔截：透過攔截 execve 與 execveat 系統呼叫以攔截程式執行操作，並額外攔截 init_module 與 finit_module 系統呼叫，以阻擋其他 rootkit 模組的插入

藉由 WiFi 訊號達成動作追蹤

2015 年 MIT CSAIL 發表〈Capturing the Human Figure Through a Wall〉和後繼的 Through-Wall Human Pose Estimation Using Radio Signals，將 Wi-Fi 當作聲波使用，藉而來定位某個人的身形、動作，也能透過顯示的影像來辨識他人，能準確辨識人體形狀、手勢移動等。這項應用的原理，是先使用 3D 空間掃描，來接收某空間中所有物體的 Wi-Fi 訊號反射，包含人體，再在人體移動的情況下繼續重複操作，如此過程下來就能辨識某個移動物體的特定反射訊號，並重建成單一影像，再加入身高、身形等變因，就能獲得特定人物的所屬的「Wi-Fi 訊號紋路」，進行身份辨識。

本任務嘗試修改現有的 Wi-Fi 裝置驅動程式，以達成動作追蹤的基礎建設。

基於電腦視覺方法利用無線網路訊號實現動作辨識 (2016 年)

由於無線網路訊號的普及性，低成本及不侵犯隱私性，利用無線網路訊號實現動作辨識在近幾年來受到相當程度的重視。通道狀態訊息(Channel State Information, 簡稱 CSI) 是一種可從接收到的無線網路訊號預估出來的資訊，提供了詳細的環境如何影響訊號的訊息 … 基於奇異值分解(Singular Value Decomposition) 的方法，能夠將地點資訊從 CSI 中移除，使得留下的資訊就是人的動作的影響。實驗結果顯示，在跨房間(地點)的動作辨識上，我們的方法在分類 6 個不同動作能夠達到 90% 的準確率。

無線通道資訊 (CSI) 定位技術

定位環境建立在使用者原本的使用方式上，以一般使用 WiFi 上網的習慣，不需要安裝任何軟體程式，或配戴額外任何裝置，就能精準找出手機、平版等行動裝置的位置。目前已成功導入國內大型企業、國營企業及國內大型醫療院所，用以進行人員及設備定位與管理。未來也將應用於大型零售業賣場環境，提供發展人流追蹤分析與顧客購買習慣分析，可優化消費者實體通路購物體驗。

People counting using WIFI and Bluetooth

WIFI and Bluetooth scanning data can be used directly to develop insights directly or to support, enhance or reinforce data sources derived through other means. We highlight many potential applications of the technology below.

  • WiFi People and Crowd Counting
  • Vehicle Counting
  • Commute Times and Traffic Flow
  • Vehicle Passenger Occupancy
  • Event Attendance
  • Sporting Event and Stadium Attendance
  • Outdoor Sport Events

Origin Wireless

We use existing WiFi waves in an environment to detect motion and send meaningful alerts or notifications.

利用 Wi-Fi 訊號，對靜止坐著的人群進行計數

這項創新建立在 Mostofi 實驗室先前的研究基礎上，該實驗室自 2009 年以來率先使用日常生活中的射頻訊號 (如 Wi-Fi) 進行感測。例如，研究人員在 2018 年的論文中即展示 Wi-Fi 訊號如何計算移動中人群的數量。然而，人們必須四處走動才能被計算到。
研究人員們將「人群煩躁期」(Crowd Fidgeting Periods; CFP) 定義為在一個 Wi-Fi 區域中至少有一個人煩躁的時間長度，並定義「人群沉默期」(Crowd Silent Periods; CFP) 為完全無人煩躁的時間長度。

ESP-WIFI-CSI detects humans with WiFi signals only, no sensor needed

論文

工具和實作

  • Nexmon Channel State Information Extractor

    This project allows you to extract channel state information (CSI) of OFDM-modulated Wi-Fi frames (802.11a/(g)/n/ac) on a per frame basis with up to 80 MHz bandwidth on the Broadcom Wi-Fi Chips.
    支援 Raspberry Pi 3B+/B4 (bcm43455c0 晶片)

  • Wi-Fi-channel-sounder

    This testbed records Wi-Fi traffic and retrieves the channel state information (CSI). For this purpose, the RF signal is passively tapped at one of the network nodes, i.e. access point (AP) or client, and decoded in Matlab.

  • CSI-Activity-Recognition

    Human Activity Recognition using Channel State Information for Wifi Applications.
    A simple Tensorflow 2.0+ model using Bidirectional LSTM stacked with one Attention Layer.

  • ESP-CSI

    The main purpose of this project is to show the use of ESP-WIFI-CSI. The human body detection algorithm is still being optimized. You can get more accurate results through machine learning, neural network and other algorithms based on the original CSI data.

  • DeepSeg

    These are the code and data for the paper: DeepSeg: Deep Learning-based Activity Segmentation Framework for Activity Recognition using WiFi, IEEE Internet of Things Journal, 2020.

  • ESP32 CSI Tool

    The purpose of this project is to allow for the collection of Channel State Information (CSI) from the ESP32 Wi-Fi enabled microcontroller. By collecting this data rich signal source, we can use this information for tasks such as Wi-Fi Sensing and Device-free Localization directly from the small, self contained ESP32 microcontroller. (web)

在 Linux 核心運作 WebAssembly 作為擴充和安全機制

camblet-driver 將 WebAssembly 模組引入核心層級，強化傳統 UNIX TCP socket 的安全能力，並達成 zero-trust 的加密通訊。該設計讓應用開發者無需修改原有應用程式碼、重新編譯或重新部署，就能享有現代化的安全保障，將心力集中於業務邏輯的實作。Camblet 主要應用與特點如下：

  • 為 UNIX TCP socket 提供 mTLS 驗證機制，達成 zero-trust 身分認證，將 WebAssembly 模組作為可動態載入的信任源頭
  • 結合 Open Policy Agent (OPA)，進行細粒度的存取控制、授權與認證決策，可動態更新政策邏輯
  • 自動進行 TLS 加密終止，無需修改應用程式，亦無需在使用者空間額外部署 TLS proxy
  • 所有安全邏輯與封裝皆可透過 WebAssembly 模組載入與執行，兼具沙箱隔離與靈活擴充能力

相關專案:

運作在核心模式的 SFTP

kFTP

kSFTP 是個運作於 Linux 核心層的 SFTP 伺服器，提供低延遲的安全檔案傳輸機制。它基於 SSH 通訊通道，將 SFTP 協定的資料操作端點下沉至核心空間，藉此降低 context switch 成本，提升效能並加強系統隔離能力。

kSFTP 採用內建於核心模組的協定解析器，能直接處理如 OPEN、READ、WRITE、STAT、OPENDIR 等 SFTP 子命令，並呼叫對應的 VFS 操作介面來執行實際檔案讀寫。所有檔案操作均限定在個別 mount namespace 中，透過與使用者空間協助程式協同初始化，可防止目錄竄逃與未授權存取，並支援結合 cgroup、AppArmor、seccomp 等安全機制。

在連線建立方面，kSFTP 不直接處理完整 SSH handshaking，而是與使用者空間之 SSH server (如 OpenSSH 或 dropbear) 協作，由後者建立安全 channel，並透過 netlink 或 io_uring 將該 channel 的 payload 委派給核心模組處理。該設計保留現有 SSH 工具的相容性，並將資料面操作完全轉由核心處理。

此外，kSFTP 支援 TLS offload，可選配 kernel TLS (kTLS) 達成效能改進。

相關專案:

核心模式的 QUIC

QUIC

運作於 Linux 核心中的 QUIC 通訊協定實作，是為了回應越來越多核心層應用需求所提出的現代化通訊解決方案。主體想法是，TLS 交握流程應保留於使用者空間，並透過 up-call 機制由核心呼叫使用者空間來完成資料流程。儘管 TLS 交握過程仍由使用者空間處理，但 QUIC 協定的主要邏輯與封包處理則完全位於核心空間，以兼顧效能與安全性。考量因素：

  • 核心層服務如 SMB (Server Message Block) 與 NFS (Network File System) 等日益仰賴高效、低延遲的網路傳輸協定。傳統的 TCP 雖然穩定，但在 I/O multiplexing重傳控制與延遲回復方面較難調校。QUIC 具備更細緻的控制機制 (如 per-stream flow control) 與內建加密特性，成為核心服務理想的傳輸層替代方案。
  • 將 QUIC 封裝為核心層級的 socket API，並支援標準操作如 listen, accept, connect, sendmsg, recvmsg, close, get/setsockopt 及 getsockname()/getpeername()，可讓開發者使用熟悉的 socket 介面撰寫應用，無需重新學習新介面。此設計也方便核心模組與使用者空間程式無縫對接。
  • QUIC 原生支援 ALPN (Application-Layer Protocol Negotiation) 協調機制，若能直接於核心中進行 ALPN 比對，即可快速將來自不同客戶端的請求導引至對應行程或容器，提升多使用者系統下的應用層導流效率，並避免額外 proxy 造成的延遲與開銷。

相關專案:

改進 semu: 視窗系統的 Guest / Host 剪貼簿共享

提案人: 鄭聖文

剪貼簿共享是主流虛擬機軟體必備功能, 需要 Host OS 以及 Guest OS 之間的合作以及許多基礎建設, 此題目需要以下貢獻:

  1. semu 在 Host 端對剪貼事件的捕捉 (X11, Wayland 等)
  2. Guest OS 上常駐服務程式的設計, 用於捕捉剪貼簿事件 (X11, Wayland 等)
    • 類似於 VirtualBox 的 Guest Additions 軟體
  3. VirtIO Socket Device 的實作, 用於 Host 與 Guest 的通訊
  4. Host 與 Guest 之間交換剪貼簿資訊的 Software Protocol 設計

此題目僅在概念層面上發想, 實際設計上較大機率需要再行調整,。因作為期末專題不一定能完成所有工作事項，建議有興趣學員挑選出可行部份在本學期內協助實作。

改進 semu: 實作 VirtIO File System Device

提案人: 鄭聖文

The virtio file system device provides file system access. The device either directly manages a file system or it acts as a gateway to a remote file system. The details of how the device implementation accesses files are hidden by the device interface, allowing for a range of use cases.

目標: 透過實作 virtio-fs 達成 Host / Guest 之間的無縫/即時檔案操作

改進 semu: 改進 VirtIO GPU 視窗處理

提案人: 鄭聖文

目前 semu 僅支援:

  1. 單螢幕顯示
  2. 固定解析度顯示 (且螢幕視窗不可伸縮)

此題目需要學員進一部完善 semu 的 virtio-gpu 實作。

改進 semu: 改進 VirtIO Input 鍵盤事件處理

提案人: 鄭聖文

virtio-input 是 semu 上搭配 virtio-gpu 所需要的輸入裝置虛擬化程式, 可以將鍵盤/滑鼠資訊輸入 Guest OS 中。目前 semu 的鍵盤事件處理並不完整, 需要學員協助實作更多鍵盤事件。

改進 semu: 實作 VirtIO Crypto Device

提案人: 鄭聖文

  1. 在 semu 中實作 VirtIO Crypto Device
  2. 尋找合適 Benchmark 軟體對引入前後執行效率分析
  3. 適合同時對密碼學以及系統軟體有興趣的同學 (找工作的熱點之一)

評估並改進 Mesa 中提交 GPU 工作的 MPMC Queue

提案人：簡志瑋

一個 GPU 工作的產生可以粗略的分成兩個部份，首先是 Shader 或解碼工作被編譯器編譯成 GPU 命令[1] 後，再來會被打包為命令封包 (command packet) 送往 GPU 執行。為了盡可能塞滿 GPU pipeline 不使其飢餓，在繪圖引擎 (或是影片播放器) 以及 mesa 中會使用多個執行緒盡可能增加發送工作量的 throughput。第一個部份中，其實整個過程與網頁瀏覽器向伺服器發送請求十分相仿，有多個執行緒在發送 GET 請求給伺服器 (在這裡是 GPU)，且請求是非同步的，即發送完不會停頓在原地等資源回傳，會繼續準備發送更多請求。在 mesa 中這與命令打包並發送拆成兩個部份主要有以下幾個考量

  • gallium driver (shader compiler 和解碼器) 可以是獨立於不同平台的，第二部份的 winsys 再負責送往不同平台如 drm (for linux), gdi (for Windows), xlib (for indirect rendering on X Window System)
  • gallium driver 可以是和發送命令封包不同調的，shader compiler 可以全速產出工作給 GPU，不必管到底送出去了沒

因此在這兩個部份之間，mesa 使用了一個 MPMC queue 來存放工作，繪圖引擎或解影片播放器使用多著執行緒作為多個生產者往 queue 塞工作，而另一個 thread pool 會有多個執行緒將工作取出，打包並送往 GPU 執行。MPMC queue 有一個顯著的挑戰是不管是 enqueue 還是 dequeue，多個執行緒對於 enqueue 的進度要同步，對於 dequeue 的進度也要同步，因此會對共享資源造成頻繁競爭，競爭某個 job slot 存取權的成本過高則會影響到 throughput。為了避免對於共享資源的競爭，那乾脆就不要共享資源，如老師在上課提到的 per-CPU 資料結構。以此為出發點，我們可以使用 SPMC, MPSC 或 SPSC 組合出符合需求的 MPMC，以下幾個問題可以思考

  • 打包並發送命令封包的執行緒數量是固定的還是動態調整的？繪圖引擎或解碼器的執行緒數量是固定的還是動態調整的？
  • 送進來 queue 的工作滿了怎麼辦？
  • 對於 index 這類的共享資源競爭是否有 false sharing 問題？

目前 mesa 的 MPMC queue 有以下幾個特性

  • queue 大小是動態的，但是在縮放期間不可以塞東西進來，而且工作是「複製」過去的 (有一些 non-blocking hashtable resize 研究也有探討這類問題)
  • 打包並發送命令封包的 thread pool 大小是動態的
  • 使用 C11 thread
  • thread 的 scheduling policy 是 SCHED_BATCH

目前我沒有找到對 mesa 這個 MPMC queue 的詳細 benchmark，CI 上也沒有相關的 monitoring，可以先從此處如何評估 throughput 下手，或許目前的就已經夠好了也說不定。這個 queue 會造成效能瓶頸的場景是 GPU 很強但 CPU 相對很弱，發送工作給 GPU 的速度不夠快使其飢餓 (不過現在桌面系統使用者普遍大家都有很強的 CPU 反而是 GPU 沒那麼強)，對此問題還有另一個解決的方向是 GPU hardware scheduler，不過那又是另一個很大的問題了

至於 vulkan，又是另一個完全不一樣的 runtime 了。一樣也有類似功能的基礎建設，近期也有維護者在 vulkan 解決類似問題

[1]: 你可能會覺的奇怪怎麼一下指令 (instruction) 一下命令 (command)，GPU 上每個 IP block 都有自己的 ISA，例如 AMD 剛上市的 RDNA4 GPU 9070XT 是使用 RDNA4 ISA，但整個 mesa 中我們還是稱之為命令，詳細典故我無法考證，但是就我推測早期的 GPU 或是現在其他比較簡單的 IP block 其 ISA 都偏向聲明式的形式，因此很像是在下命令。

繪圖引擎及 shader compiler 的非同步執行環境

前面提到 Shader 或解碼工作被編譯器編譯成 GPU 命令發送工作請求的過程很像網頁瀏覽器的行為，以多執行緒繪圖引擎為例，其中會使用到非同步 runtime 來發送請求。可以嘗試使用 coroutine 建構一個適合繪圖引擎使用場景的非同步執行環境

此處會需要注意的是整個 graphics stack 中 job synchronization 的方式，也就是對於一個送出的工作，我要如何知道他已經完成，並且有照著我期望執行順序執行 (我們允許 reorder 以最大化硬體使用率)？Android 的繪圖同步框架對此提出了 dma_fence，目前已經被整合進 kernel，也就是對於一塊即將被繪製的 buffer，提出請求者可以對其 wait，並等待繪製完成後來自 GPU 的中斷，由 kernel 對其 signal，對其等待的人則會收到當初註冊的 callback 的通知。在 install fence 時再搭配預期的工作 sequence number ，則可作為命令相依的檢查方式。目前 mesa 的 vulkan runtime 有在進行相關的重整及最佳化，gallium (OpenGL, VA-API) 這邊也可能尚有改進或借鏡 vulkan 的改進空間，並留意再更上層的繪圖引擎該如何配合此 job synchronization 方式，如繪圖工作排程，有效率且低延遲的呈現繪製結果並塞滿 GPU

Inlining kfuncs into BPF programs

提案人：林志恩

近期 eBPF 正在探討如何 inline kfuncs 來提昇效能，例如 Zingerman 提出 kfunc inlining 以減少 jumps 並有約 1.53x speed up。目前社群主要在討論要如何實作 kfunc inlining ，其中涉及到 security issues, architecture-specific code, eBPF verifier , auto-inlining 等。而目前最主要的議題在於哪些 functions 有益於 inlining 。

Borrow Checker for C

提案人：林志恩

近期 Linux Kernel 社群因為多語言（Rust+C）的開發流程而有一些衝突與討論。目前最主要討論的是現有開發者以及維護者不熟悉 Rust 語言並且可能會需要更多的心力來處理開發上語言之間的修改。而引入 Rust 語言的其中一個因素就是因為它的 memory safety feature (e.g., borrow checker)，因此，解決此問題的其中一個方法可以是引入 borrow checker for C 。這個想法，在當初 Rust 要引入進 Linux Kernel 時已經有人提出了，並且也有相對應的實作，如 Cake 。但是要整合進 Linux Kernel 裡還需要更多的討論與改進。

近期 gccrs 支援了 borrow checker [1, 2]，從其中的 Design goals 可以看到此 borrow checker 是 no language-specific information :

Rust GCC project aims to use the Polonius project as its borrow-checker. Polonius operates on a set of facts about the program to determine the actual lifetimes of borrows. As Polonius's primary analysis is location sensitive, the facts are tied to the program's control flow graph (CFG). Unlike rustc, which has its own three address language specific representation called MIR, gccrs uses gcc's AST based representation GENERIC. GIMPLE (the three address IR) is generated from GENERIC inside GCC and can carry no language-specific information. Therefore, we need to generate our own representation of the program's CFG. Since gccrs has no intention of having a MIR-like IR, the BIR is not to be used for code generation. Therefore, BIR carries only minimal information that is necessary for the borrow-checker and for BIR debugging.

然而此開發過程有點緩慢，要想把此機制用於 Linux Kernel 還需要一段時間。因此，我們可以先以 RCU pointer 以及 locking 檢測機制為例，以 Sparse 來開發一個 borrow checker for C 。

Kdump 與 crash 時間修正

提案人: RinHizakura

Kdump 是 Linux 核心的一個特殊功能。當核心出現異常而發生核心錯誤(kernel panic) 時，將觸發 Kdump。藉由 Kdump，核心可以匯出記憶體的 image，即所謂 Core Dump。Core Dump 可用於除錯和確定崩潰的原因。這個 image 會以 ELF 格式匯出，可以在處理核心崩潰時通過 /proc/vmcore 直接存取，或者可以也可將其自動儲存到本地或遠端檔案系統。關於 Kdump 的更多細節，可參閱 Linux 核心設計: Kernel Debugging(1): Kdump 的解說。

而對於產生的 Core Dump，一種常見的作法是使用 crash 工具分析。然而，當在最新版本的 Linux 使用這款工具時，我們會發現 DATE 一欄可能無法顯示正確的時間。其原因可能來自於 Linux 在 timekeeper 子系統之相關資料結構上隨版本的演進。

$ crash guest.img vmlinux
...
      KERNEL: vmlinux
    DUMPFILE: guest.img  [PARTIAL DUMP]
        CPUS: 20
+        DATE: Thu Jan  1 08:00:00 CST 1970
      UPTIME: 00:00:32
LOAD AVERAGE: 0.63, 0.17, 0.06
       TASKS: 214
    NODENAME: virtme-ng
     RELEASE: 6.13.0-rc2-00036-g231825b2e1ff
     VERSION: #11 SMP PREEMPT_DYNAMIC Sat Dec 28 22:21:23 CST 2024
     MACHINE: x86_64  (2916 Mhz)
      MEMORY: 1 GB
       PANIC: "Kernel panic - not syncing: sysrq triggered crash"
         PID: 507
     COMMAND: "sh"
        TASK: ffff919186519d80  [THREAD_INFO: ffff919186519d80]
         CPU: 8
       STATE: TASK_RUNNING (PANIC)

嘗試認識 Kdump 的運作，並了解 crash 是如何分析 Core Dump，以修正在最新版本的 Linux 中的上述時間錯誤，提交到 crash 專案中。

PCI 配置空間(Configuration Space) 的存取程式碼重構

提案人: RinHizakura

PCI 配置空間(Configuration Space) 是一段與 PCI 裝置的功能、設定相關的結構。硬體層面上，通常我們會以 Bus, Device, Function(BDF) 做為 PCI 裝置的唯一位址，並以此透過晶片廠商提供的方式存取之。以 Intel 的晶片組為例，其使用 I/O 空間的 0xCF8 來設定 Configuration Address Register 來決定要存取的 BDF，最後再以 0xCFC 位址來讀取或寫入 Configuration Data Register 以得到想存取的 Configuration Space 內容。關於 PCI Configuration Space 的更多細節，可閱讀 PCIe 規格書的相關章節，搭配 PCI/PCIe(1): 基礎篇的說明閱讀。

在 Linux 系統上，有兩種介面能提供 configuration space 的存取，一種是透過 sysfs，另一種則是 procfs。仔細觀察可以發現，兩段程式碼有需多重複之處。如此設計是否是受制於兩種檔案系統的限制，或者有可能重構來減少重複的程式碼，強化未來維護的方便性? 可能是有機會貢獻程式碼到核心的機會。

Linux Suspend/Resume

提案人: RinHizakura

除了在伺服器領域的應用，Linux 作業系統在移動式裝置上也佔有一席之地。針對移動式裝置，如何於達到合理效能的前提下，減少電源的耗損是相當重要的課題。因此在 Linux 中有電源管理(Power Management) 子系統來滿足該需求。

System Suspend/Resume 是電源管理中一個重要功能。
以筆記型電腦為例: 在觀賞影片到一半時，突然有事必須暫時離開，這時如果可以關閉顯示畫面和暫停 CPU 的運作等，就可以減少電源的損耗; 但同時使用者又不希望完全關閉電源，導致丟失影片的進度或是過長的復原時間。這時，Suspend/Resume 就可以作為比完全運作更為省電，同時能相對重新開機快速回復到完全運作的狀態，以滿足上述的需求。請閱讀 System Sleep States 和參考 Linux 核心設計: Power Management(1): System Sleep model 來得知更多細節。

在目前的 Linux 的設計中，Suspend/Resume 各自可以被分為數個小階段，以滿足不同的目的與限制:

  • Suspend:
    • enter(sync filesystem/freeze proceses)
    • prepare
    • suspend
    • suspend_late
    • suspend_noirq
  • Resume:
    • resume_noirq
    • resume_early
    • resume
    • complete
    • exit(thaw processes)

Suspend/resume 的流程除了需要運作正確，整體的速度也很重要，因為這影響了使用體驗。參考 Google 工程師 Saravana Kannan 在 LPC 上的演講: Optimizing suspend/resume，他發現了在當前 Linux 裡 suspend/resume 的諸多優化可能性。總結來說，大致有以下幾點發現:

  1. 在 suspend_enter 階段可能會做 sync filesystem，嘗試將 dirty page 寫回磁碟中。此時 userspace 沒辦法中斷此操作。換句話說，不能在過程中反悔並復原系統。而這個過程可能長達 25 秒。
  2. 在 suspend_enter 階段，將 task 暫停時(freeze proceses) 會因為未知原因出現多數 CPU 都閒置(idle)卻遲遲無法進入下個階段的狀況。
  3. Linux 中支援一種名為 Asynchronous suspend/resume 的機制，試圖將裝置的暫停和復原平行進行以獲得加速。但當前設計可能反而帶來龐大成本，讓平行(async) 比起序列進行(sync) 的延遲來得更長。
  4. 即使選擇 Asynchronous suspend/resume 機制，prepare 或 complete 階段整體仍需序列進行，或許可以探索平行化的可能性。
  5. suspend/resume 的每個小階段都有嚴格的界線。舉例來說，當所有 USB 裝置都完成它的 suspend_late 階段，必須要等待所有其他裝置也完成 suspend_late，才能進行接下來的 suspend_noirq，即便它彼此間可能沒有相依性。

針對此議題，學員可以嘗試從以下方向去突破:

  • 影片中，Saravana Kannan 使用 Perfetto 進行 Suspend/Resume 的分析。嘗試使用此工具分析自己電腦的 Suspend/Resume 過程!觀察是否有異常/可優化的地方?
    • 可搭配 pm-graph 進行分析，觀察兩個工具的差異
  • 針對 3，相關的修改正在社群被討論。嘗試閱讀相關改動帶來的好處，並思考是否有不足之處?
  • 針對 Saravana Kannan 提出其他改進點，嘗試提出相關實作

Extra: virtme-ng 的 Suspend/Resume 支援

另一方面，virtme-ng 是一款基於 QEMU，可以用來有效建立虛擬的 Linux 環境，加速 Linux 的開發與測試的工具。可以參考 Linux 核心設計: 開發與測試環境#virtme-ng 知道相關的使用方式。

參考 Linux 核心設計: Power Management(3): 測試工具#PM-on-QEMU，在 QEMU 上，我們可以根據文中所述的步驟讓 Linux 系統進入睡眠狀態，然後將之喚醒。而 virtme-ng 是基於 QEMU 打造的虛擬環境，理論上也要具備相同效果。然而實際使用時，我們會發現在喚醒系統之後，Resume 無法順利完成，無法觀察到 console 的復原。

探究 virtme-ng 的啟動方式，以理解其中所缺少的實作，並嘗試貢獻程式碼到原始專案中。

改進 mini-gdbstub

提案人: RinHizakura

mini-gdbstub 是一個針對模擬器開發的具體而微 Gdbstub/Gdbserber 實作。藉由整合此函式庫，能夠很容易地在模擬器上引入 GDB 的除錯功能。如 rv32emu 與 semu 皆導入此專案來獲得 GDB 的支援。

目前，mini-gdbstub 在功能性上大致正確，但仍有許多可行的優化與改進空間。舉例來說:

  • 為了檢察 host 端的 interrupt，我們建立額外的執行緒來監聽相關封包。然而目前採用的 polling 的方式會導致觀察到 100% 的 CPU 使用率。嘗試修正此問題。(issue#12)
  • 是否可能改為不依賴額外執行緒的實作，以減少同步的複雜性與成本?
  • mini-gdbstub 的 CI/CD 覆蓋範圍有限，這導致當任意的程式碼更新，使原本正常的功能出現錯誤時，可能無法被即使發現。(issue#11)
  • mini-gdbstub 設計 pktbuf 作為儲存接收到的封包之佇列，但此設計仰賴許多記憶體的移動與複製，可能造成較差效能。是否有更好的設計方式?
  • 是否存在需要除錯功能的模擬器專案，可以善用此函式庫? mini-gdbstub 目前提供的介面是否已足夠提供完整支援?(e.g. Vectorization (SIMD/SIMT) 是否可支援?)
  • 是否有甚麼是強大的 GDB 功能是 mini-gdbstub 尚無法支援的?(e.g. watchpoint?)

請留意: mini-gdbstub 作為與除錯功能相關，並且以具體而微為目標的函式庫，我們將程式碼的簡潔與易讀性放在第一位。引入艱澀的演算法卻只能提升些許效能的情況下，該改動可能不被接受。

嘗試整合 UsbIpd 進 WSL2

提案人: Damien

WSL2（Windows Subsystem for Linux version 2）是微軟提供的一項技術，讓使用者可以在 Windows 10 和 Windows 11 系統中原生執行 Linux 作業系統，無需使用虛擬機或雙系統。

然而原生的 WSL2 無法在其環境中存取 host 端 USB 裝置，必須透過第三方工具 UsbIpd ，重新編譯 WSL2 linux 核心後才可使用。

近期微軟開源 WSL2 的原始程式碼(並非 100% 開源)，根據其 Github Repo 的 Issue#12964 描述
可嘗試研究整合 UsbIpd 進 WSL2 的可行性，如此一來，WSL2 即可原生支援 USB 裝置。

Last changed by 
 
sysprog
System Software Programming
0
2
2071
Published on HackMD