Linux 核心：將透明大頁擴展至 1 GB PUD 層級的補丁提案
LWN.net · 2026-05-12
一位核心開發者在 2026 年五月向 linux-kernel 郵件清單提交了讓透明大頁（Transparent Huge Pages, THP）支援 1 GB PUD 層級頁面的系列補丁，挑戰社群長期以來對此功能「代價過高」的保守態度。目前 Linux 核心的 THP 預設在 PMD 層級操作，對應 x86-64 架構下的 2 MB 頁面；1 GB 對應 PUD 層級。
背景
THP 的設計目的是透過自動合併小頁面來減少 TLB 壓力，在大記憶體工作負載（HPC、資料庫、虛擬機器）中降低頁表遍歷成本。x86-64 處理器在硬體上已支援 1 GB 頁面，但傳統的靜態 Hugepages 需要系統管理員預先分配，無法動態合併。1 GB THP 的目標是讓這個層級也能享受 THP 的動態管理機制，消除靜態預分配的運維負擔。
核心改動
提案補丁修改了 mm/khugepaged.c 中的掃描邏輯，讓核心可以在 512 個連續的 2 MB PMD 頁面都屬於同一個匿名映射且均為 THP 時，嘗試將它們提升為單一 1 GB PUD 頁面。回退路徑是主要的設計挑戰：一旦應用程式對 1 GB 區域的任一子頁面進行寫入導致 CoW（Copy-on-Write）分裂，整個 PUD 頁面必須被拆解回 PMD 層級，這個操作的成本遠高於拆解 2 MB 頁面。補丁同時修改了 mm/huge_memory.c 以支援 PUD 層級的 split_huge_pud() 路徑，並更新了 /sys/kernel/mm/transparent_hugepage/ 下的 sysfs 介面，讓管理員可以獨立控制 PMD 和 PUD 層級的 THP 行為。
影響範圍
社群討論的焦點集中在記憶體碎片化問題：1 GB 的連續實體記憶體在長時間運行的系統中越來越難以分配，核心的記憶體壓縮機制目前尚未針對 PUD 層級最佳化。NUMA 系統中跨節點的 1 GB 頁面可能帶來不可預測的存取延遲。預期適用場景主要是大型資料庫（PostgreSQL 的 shared_buffers、Oracle SGA）和 HPC 應用，在這些場景中記憶體存取模式足夠規律，TLB 效益可以穩定超過碎片化代價。
原始來源：LWN.net
Linux dma-buf 新提案：讓 DMA 緩衝區支援使用者空間的 read/write 操作
LWN.net · 2026-05-12
一份針對 Linux DMA 緩衝區子系統的核心補丁提案在 2026 年五月提交，目標是允許使用者空間程式透過標準的 read() 和 write() 系統呼叫直接存取 dma-buf 檔案描述符，繞過目前需要透過 mmap 或 CPU/GPU 間複製的間接路徑。
背景
dma-buf 是 Linux 核心中用於裝置間共享記憶體緩衝區的框架，讓 GPU、相機、顯示器、網路卡等不同子系統可以無需 CPU 參與地傳遞大型資料。目前 dma-buf 的主要使用者空間介面是 mmap()：應用程式映射緩衝區後直接讀寫虛擬位址。這個模式要求 CPU 必須取得緩衝區的寫入所有權，在 GPU 渲染管線中，這往往意味著必須先執行昂貴的 GPU cache flush 和同步屏障（fence）操作。
核心改動
補丁在 drivers/dma-buf/dma-buf.c 中新增 .read 和 .write file operation callback，並要求 dma-buf exporter 實作對應的 dma_buf_ops 函數。同步語義是實作的關鍵難題：dma-buf 本身透過 dma_fence 追蹤 GPU 操作的完成狀態，新的 read/write 路徑需要在操作前等待所有待完成的 GPU fences，操作後再觸發 CPU cache invalidation。提案同時在 include/linux/dma-buf.h 中新增 DMA_BUF_IOCTL_SYNC_RW ioctl，讓呼叫者可以明確控制 CPU-GPU 同步時間點。
影響範圍
主要受益場景包括：視訊解碼器輸出直接被使用者空間後處理程式讀取、零拷貝網路傳輸（讓網路卡 DMA 緩衝區直接 write() 到 socket）、以及 AI 加速器與 CPU 之間的資料交換。現有驅動程式（i915、amdgpu、v4l2）需要實作新的 ops callback 才能啟用此功能，核心補丁本身只提供框架，不強制要求現有驅動遷移。
原始來源：LWN.net
Debian 強制要求可重現建置：封鎖不符合標準的套件遷移
LWN.net · 2026-05-11
Debian 發行團隊在 2026 年五月宣布，其套件遷移系統現在封鎖未達到可重現建置（Reproducible Builds）標準的套件，阻止它們從 unstable 進入 testing 分支。這是可重現建置倡議自 2013 年啟動以來，在主要 Linux 發行版中最具約束力的政策落地。
可重現建置的技術原理
可重現建置的核心定義是：相同的原始碼在相同的建置環境中，無論何時、由誰執行，都應產生位元組完全相同的二進位輸出。阻礙可重現性的常見問題包括：建置時間戳記（__DATE__、__TIME__ 巨集）、隨機記憶體位址洩漏進二進位、檔案系統目錄迭代順序不固定、以及建置路徑被嵌入除錯資訊。Debian 透過 SOURCE_DATE_EPOCH 環境變數（設定為原始碼最後修改時間）等標準化技術讓建置工具使用固定時間值。Debian 的 debrebuild 工具讀取 .buildinfo 檔案——其中記錄了完整的建置環境快照，包含所有建置依賴的精確版本——讓任何人可以在本機重現官方建置並比對雜湊值。
政策細節
Debian 強調此次要求的範圍是「在 Debian 建置環境內部的可重現性」，不要求跨不同作業系統或不同 CPU 架構。棘齒機制（ratchet mechanism）是政策執行的核心：一旦套件達到可重現標準，任何導致其退步的更新都將被封鎖；但尚未達標的套件仍可繼續遷移（帶有警告），直至整個套件庫完成轉換。這個漸進式策略避免了一次性封鎖大量套件造成的遷移危機。
影響範圍
可重現建置對供應鏈安全具有直接意義：如果建置基礎設施被入侵，可重現建置讓使用者可以獨立驗證官方發行的二進位是否確實由公開原始碼產生，而非遭植入惡意程式碼。Debian 的強制化為其他發行版（Fedora、Ubuntu、Arch）樹立了政策先例，而 Reproducible Builds 專案的成果也被 NixOS 的建置系統廣泛採用。
原始來源：LWN.net