# 2026-05-05/07 問答簡記

:::success
5 月 5 日討論專題、5 月 7 日晚間回顧測驗題並討論
:::

## rota1001
> [Optimize Linux Kernel Size for STM32F429](https://hackmd.io/@rota1001/linux-stm32f429)
> [demo](https://www.facebook.com/groups/system.software2026/posts/1377012974543503)

---

> [cellphone demo](https://www.youtube.com/shorts/LBg6tltV4Ek)

- lvgl
- tslib
- DMA2D
- cellphone prototype

## weiso131
> [Customize CPU scheduler with scx_ext](https://hackmd.io/@weiso131/r18BJxLpbx)
> [demo](https://www.facebook.com/groups/system.software2026/posts/1374404781470989)

使用情境: 同時跑 cpu bound 和注重延遲的任務，目標要透過機器學習分類讓注重延遲的任務延遲降低

- [遊戲 FPS 改進](https://hackmd.io/NE6PN7QPQc6xqbscDGqNDw)
- [移除多餘的 feature](https://hackmd.io/@weiso131/HJCZQfYsWe)
- 移除高度相關的 feature
- task_struct 的 in_iowait
- 使用變異係數
- 使用 ratio
- iowait 佔睡眠次數的比例
- [(runtime) / (runtime + sleeptime)](https://hackmd.io/TGGzBRrmTDy0-sAGYz9QbQ#runtime-ratio)
- 是否能替代 runtime_ms 與 sleep_ms?
- 平均造成標準化出問題(應該用中位數？)
- [圖像化 latency 表現並減少自訂排程器 cpu 佔用](https://hackmd.io/@weiso131/r18BJxLpbx)

---

## ericlin1231
在 Linux kernel 中，長期用於偵測 deadlock 的機制是由 Ingo Molnar 主導設計的 [lockdep](https://docs.kernel.org/locking/lockdep-design.html)。其方法是建立 lock acquisition order graph，將每次 lock 的取得關係視為一條有向邊，並透過檢測 ordering cycle 來識別潛在的 deadlock。這種方法對於典型的「鎖取得順序反轉」問題相當有效，例如二個執行緒以相反順序取得同一組鎖時，會形成循環依賴並觸發警告。然而，lockdep 的能力邊界也正源於其模型本身：它僅關注 lock acquisition 的順序，而未能涵蓋更廣義的同步事件與資源依賴。
> 延伸閱讀: [Linux 核心設計: Scheduler(10): PREEMPT_RT](https://hackmd.io/@sysprog/linux-scheduler-10)

lockdep 在每次觀察到「已持有 Lock A → 再取得 Lock B」，就會建立一條邊 (edge)：

A → B

代表一個 ordering constraint：系統曾經允許 A 在 B 之前被取得

假設程式中只出現以下順序：
* Thread 1：A → B
* Thread 2：A → C
* Thread 3：B → C

則 lock dependency graph 為：

    A
   / \
  v   v
  B → C

這是一個 DAG（沒有 cycle），代表：
* 所有 lock acquisition 順序彼此一致
* lockdep 不會報錯

deadlock 情境 (cycle 出現)。假設：
* Thread 1：A → B
* Thread 2：B → A

則 graph 變成：

A → B
↑   ↓
└───┘

或寫成：

A → B → A

出現 cycle，lockdep 會立即警告：
> possible circular locking dependency detected

這正是典型 deadlock：
* Thread 1：持有 A 等 B
* Thread 2：持有 B 等 A

稍複雜案例（多節點 cycle）

Thread 1: A → B
Thread 2: B → C
Thread 3: C → A

圖形：

A → B → C
↑       ↓
└───────┘

這種同樣會被 lockdep 偵測。

簡化的 Linux 核心的案例 (nested locking)

mutex_lock(&inode->i_mutex);   // A
spin_lock(&mapping->tree_lock); // B

建立：

A → B

若另一條路徑出現：

B → A

就會形成 cycle。

為什麼是 DAG？lockdep 的隱含假設是：
> 正確的 locking discipline 應該能形成一個「全域一致的偏序關係（partial order）」。

亦即
* 所有 lock 都應該有「一致的取得順序」
* 這個順序可以被拓撲排序（topological sort）

若無法拓撲排序 → 一定有 cycle → 潛在 deadlock

可看出 lockdep 的限制：

lockdep graph：

Lock-level graph
A → B → C

但實際系統可能是：

Thread A:
  hold L1 → wait(event)

Thread B:
  wake(event) → need L1

亦即，事件依賴 cycle

L1 → wait → wake → L1

「不會」出現在 lockdep graph 中。
> [Hoare Logic and Model Checking: Linear temporal logic (LTL)](https://www.cl.cam.ac.uk/teaching/1617/HLog+ModC/slides/lecture-8.pdf)

在 Linux Kernel Summit 相關討論以及 LWN.net 的報導中，來自 LG 的工程師 Byungchul Park 提出了名為 [DEPT](https://lwn.net/Articles/1036222/) (Dependency Tracker) 的新機制，試圖突破 lockdep 的限制。DEPT 的關鍵創新在於將 dependency 從「鎖的取得順序」提升為「事件層級的因果關係」，其追蹤範圍不僅包含 acquire，還涵蓋 release、wait、wakeup 等各類同步事件，並以此建構一個更一般化的 dependency graph。這樣的模型使 DEPT 能夠捕捉跨不同的同步 primitives 之間的依賴鏈，例如一個執行緒在持有鎖的情況下進入等待狀態，而另一個執行緒雖然負責喚醒該事件，卻同時依賴前者所持有的資源，最終形成一種不涉及傳統 lock ordering cycle、但仍然導致系統停滯的 dependency cycle。這類情境正是 lockdep 無法處理的盲點。

DEPT 確實能偵測部分 lockdep 無法覆蓋的複雜 deadlock，甚至曾被用於分析實際 kernel 問題，其能力也引起核心開發者的關注。然而，截至 2025 年，DEPT 仍未被納入 Linux 核心：DEPT 採用的事件導向模型雖然更具表達力，但也導致 dependency 關係的過度近似，增加 false positive 的機率，使得輸出的訊號品質不如 lockdep 穩定。其次，為了追蹤更廣泛的事件類型，DEPT 在執行期與記憶體上的開銷顯著提高，對於本就對效能高度敏感的 kernel 而言是一大顧慮。此外，DEPT 的導入需要對 kernel 多個子系統進行額外的 annotation 與介面調整，整合成本遠高於既有機制。相較之下，現實開發流程中許多工程師更傾向使用如 bpftrace 之類的動態 tracing 工具進行問題定位，雖然這些工具並不提供形式化的 deadlock 偵測，但在靈活性與即時性上更符合實務需求。

值得注意的是，DEPT 所處理的問題範疇與 priority inversion 並不相同。後者屬於排程與優先權管理問題，而 DEPT 關注的是同步事件之間的依賴關係與可能形成的循環。儘管如此，DEPT 所建立的 dependency graph 確實有助於揭示執行緒之間的阻塞鏈，從而間接提供分析優先權反轉或長時間等待的線索。DEPT 並非對 lockdep 的簡單替代，而是提出一種更一般化的同步關係模型。若未來能在降低誤報、控制效能開銷以及簡化整合成本方面取得進展，這類事件導向的 dependency tracking 機制，仍有機會成為未來 Linux 核心偵錯工具。

---

https://wiki.csie.ncku.edu.tw/embedded/SPI
https://docs.kernel.org/devicetree/usage-model.html
https://github.com/torvalds/linux/blob/master/arch/arm/mach-stm32/board-dt.c
https://sysprog21.github.io/cpumemory-zhtw/