Linux 核心醞釀「虛擬交換空間」，替 swap 子系統補上操作結構抽象層
LWN.net · 2026-07-23
LWN 於 2026-07-23 刊出的文章描述了核心 mm（記憶體管理）社群長期以來的痛點：swap 子系統從未有一層清楚的「操作結構」（ops struct）介面來對接底層儲存，導致每次要支援新的 swap 後端（壓縮式 zswap、多裝置、未來的分層儲存）都要動到散落各處的呼叫路徑。這個議題最早在 2026 年的 LSFMM+BPF（Linux 儲存、檔案系統、記憶體管理與 BPF 高峰會）上被提出。
背景
Nhat Pham 領銜的 Virtual Swap Space patch series（第三版，共 20 個 patch，發佈於核心郵件論壇 LKML）正是這個方向的具體實作。系列的核心想法是把「swap entry 的生命週期」與「實際的實體 swap 儲存後端」解耦——目前 swap cache 直接綁死在實體 swap slot 上，任何遷移、去碎片化或延遲配置都得直接操作底層結構。
核心改動
patch 系列引入一層虛擬 swap slot，讓 swap cache 只認得虛擬位址，實際寫入哪個實體裝置、哪個 offset 由下層決定並可延後決定。這也連帶簡化了 swapoff 路徑——過去 swapoff 需要同步搬移所有仍在使用中的 swap 分頁，改用虛擬層之後可以做到更漸進式的遷移，減少停頓時間。
影響範圍
目前系列仍在 RFC／早期 review 階段，尚未進入主線；但方向已經與另一項並行工作「swap tables」（swap_ops 抽象的前身討論）合流。若合併，未來要新增支援新型態儲存後端（例如針對持久記憶體優化的 swap 裝置）將不需要再改動核心 mm 的呼叫點，只需實作對應的 ops 結構。
原始來源：LWN: An operations structure for swap devices、Nhat Pham, [PATCH v3 01/20] mm/swap: decouple swap cache from physical swap infrastructure
C++26 標準函式庫收編 std::indirect／std::polymorphic，PIMPL 不用再手刻五個特殊成員函式
WG21 P3019 · Marius Bancila 部落格文章 2026-07-23
C++ 提案 P3019（indirect<T> 與 polymorphic<T>）已在 2025 年 Hagenburg 會議通過至最新修訂 P3019R14，確定進入 C++26 標準函式庫 <memory> 標頭。7 月 23 日的一篇部落格文章重新梳理了這兩個型別如何直接解決 PIMPL（Pointer to Implementation）慣用法長年的痛點。
背景
PIMPL 的目的是把類別的實作細節搬到一個只在 .cpp 檔可見的不完整型別（incomplete type）身上，藉此降低標頭相依、加速編譯。但要正確實作它，得手動撰寫解構子、複製建構子、複製指派、移動建構子、移動指派共五個特殊成員函式，還要小心處理 const 語意——用 unique_ptr 存放實作物件時，const 存取路徑並不會自動傳遞到被指向的物件上。
規格細節
indirect<T> 讓一個自由儲存（free-store）配置的物件擁有值語意：複製 indirect 會複製底層的 T，透過 const 路徑存取會正確傳遞 const 到 T 身上。polymorphic<T> 則是給多型情境用的版本，可以持有任何公開繼承自 T 的衍生類別物件，不需要手動實作 clone 介面。兩者都支援分配器感知（allocator-aware）建構與 valueless_after_move() 偵測移動後狀態。
影響範圍
對現有程式碼而言，最直接的改變是 PIMPL 類別可以把 std::unique_ptr<Impl> 換成 std::indirect<Impl>，然後直接刪掉手寫的五個特殊成員函式定義，交給編譯器產生的預設版本——因為 indirect 本身已經正確處理深複製與 const 傳遞。程式庫作者今天若要在標頭中隱藏實作細節同時保留值語意，也多了一個不需要外部依賴（如 value_types 這類第三方函式庫）的標準選項。
原始來源：P3019R6: indirect and polymorphic: Vocabulary Types for Composite Class Design、Marius Bancila: The PImpl idiom and the C++26 std::indirect type