Linux workqueue 如何建立 (API)？ 下列這五種為 workqueue 建立的 (API)： alloc_workqueue alloc_ordered_workqueue() create_workqueue() create_freezable_workqueue() create_singlethread_workqueue() 這些 API 雖然名稱不同，但底層實作邏輯最終都會呼叫 alloc_workqueue() ，因此 alloc_workqueue() 是核心唯一真正的函式，其餘的只是為了語意清楚或向後相容所包裝的宏。

kernel 中的電源管理可以分為以下兩類： Static PM主要處理的是系統長時間處於非活動狀態時如何節省電量 目前沒有主要的開發工作 Dynamic PM 主要處理的是系統處於活動狀態時如何配置系統設備 隨著 soc 的發展這個框架在不斷的發展跟調整

contributed by < wurrrrrrrrrr > :::danger 注意書寫規範，重視細節！ ::: 閱讀〈因為自動飲料機而延畢的那一年〉的啟發 看完文章後，我印象最深刻的是以下這兩句話：「大多數人一直活在本來就應該這樣嗎的童話世界裡，電視打開就可以看，機車買來就可以騎，手機買來就可以用，一切都理所當然，本來就應該這樣。偶爾買到不好用的商品我們就抱怨幾句，丟掉換其他更好用的牌子，卻很少意識到那個本來就該這樣，背後需要經過多少人月的投入與研發。」以及「你該學習的不是看到事情要完蛋了就去避免失敗，而是應該學習如何處理與承受失敗，你才能變得比以前更強大。」這兩句話讓我深深反思我們對日常事物的理所當然，其實背後藏著無數人的努力與付出，而我們卻常常忽略這些價值。同時，第二句話也提醒我，面對困難與挑戰時，與其一味逃避失敗，不如學會面對與承擔，因為真正的成長往往來自於一次次跌倒後的重新站起。這讓我意識到，改變自己的態度與思維，比逃避問題更為重要，失敗或許很難受但是每一次的失敗都能為自己帶來不一樣的啟發，就像在前六週的生活中，每天都有做不完的事，有實習面試的壓力，也有課業的負擔，一度讓我感到快要撐不下去、只想逃避。但後來我明白，就算真的失敗了也沒關係，重要的是，我在這些經歷中學到了什麼，並因此變得更加堅強。 研讀第 1 到第 6 週「課程教材」和 CS:APP 3/e

contributed by < wurrrrrrrrrr > 縮減使用者和核心層級的通訊成本 開始改進程式碼之前，深入了解現有的程式碼架構和邏輯是第一步要做的。由作業要求可以看到我的任務是縮減使用者和核心層級的通訊成本，因此，第一步我先檢視了判定勝利的程式碼區段，以了解它如何根據棋盤狀態判斷哪一方獲勝或是否平局。 const line_t lines[4] 這個 lines 陣列定義了四個方向（橫向、縱向、主對角線、副對角線）的檢查規則還有起始位置跟邊界範圍。 char check_win(const char *t) 這段函式主要邏輯是先遍歷所有四個方向，對每個方向的每個可能起點進行檢查，一旦找到連線則返回勝者；若都沒找到，再根據棋盤是否填滿來決定是遊戲未完成還是平局。

contributed by < wurrrrrrrrrr > Reviewed by nyraa 部分 inline code 前後沒有插入空白。 依照規範，在英文單字建議都要插入空白 q_free() 中可以使用對於刪除節點友善的巨集 list_for_each_safe 這個巨集可以刪除當個節點而不影響迭代， q_release_element 這個巨集可以釋放一個節點的記憶體空間。

contributed by < wurrrrrrrrrr > 第一週測驗題 測驗一 一開始先提到以下程式碼運用 "a pointer to a pointer" 技巧，於是我開始思考什麼叫做 "a pointer to a pointer"，於是我先閱讀了你所不知道的 C 語言: linked list 和非連續記憶體了解到間接指標的技巧，可以避免動態記憶體配置同時我也看了Linux 核心的 hash table 實作得知了間接指標也能用來消除特例使得程式碼更為優雅，比如說在上述文章中的例子： 探討針對典型雙向鏈結串列進行節點移去時，會產生的問題我們先使用典型的 doubly-linked list: struct dll_node { struct dll_node *next, *prev; }

contributed by < wurrrrrrrrrr > 測驗 1 AAAA = (n+d-1)/d BBBB = 0x7fffffff CCCC = n + m DDDD = 1 EEEE = mpi_gcd(rop, op2, r) 一開始：

contributed by < wurrrrrrrrrr > 還政於民的 sched_ext 及機器學習如何幫助 CPU 排程 在研讀過 Linux 核心專題: CPU 排程器 後我得知 Linux 排程器的演化，經歷了$O(n)$ $O(1)$ scheduler, CFS 到現在的 EEVDF。CPU 排程器的設計理念在於提供一種普遍適用的策略，以滿足各種不同的應用需求，但有些使用Linux 的公司來說，當他們的平台只涉及特定工作負載時，通用的排程器可能無法滿足他們的特殊需求，所以要是能自訂排程器的行為，將有機會帶來更多好處。 在閱讀過程中我看到了以下這段話：『開發人員探索在 Linux 中引入「可插拔」排程器的可能性』而要支持這向技術的基礎為 eBPF。 eBPF 不僅支持將程式碼動態加載到核心執行，還提供檢查器以減少程式對作業系統核心的損害風險。這樣一來，開發者便可輕鬆撰寫並植入客製化的 CPU 排程器。 在閱讀這篇文章之前，我一直認為一旦設定好 CPU 排程器後，就只能使用該排程方式，然而「可插拔」排程器的概念顛覆了我的想法，但 eBPF 到底是什麼呢？於是我先閱讀了 eBPF 在這篇文章中我了解到 eBPF 就是 BPF 的擴充，所以如果要如果了解 eBPF 是什麼的話就必須先了解什麼是 BPF 。

輸入/輸出（I/O）是指在==記憶體與外部設備==之間複製數據的過程。 輸入（Input）：將數據從 I/O 設備讀取到主記憶體中。 輸出（Output）：將數據從記憶體寫入 I/O 設備。 所有程式語言的 Run-time System 都提供 高階的 I/O 介面 來簡化 I/O 操作。例如： ANSI C 提供標準 I/O 函式庫，包含 printf 和 scanf 等函式，這些函式使用 緩衝 I/O（buffered I/O） 來提高效能。 C++ 提供類似功能，透過 <<（put to）和 >>（get from）運算子 來操作輸入輸出。 在 Unix 系統，這些高階 I/O 函式最終是透過系統核心（Kernel）提供的低階 Unix I/O 函式來實作的。