Hyper-DERP：以 C++ 與 io_uring 重新實作 Tailscale DERP 中繼協定
hyper-derp.dev · 2026-04-26
DERP（Detoured Encrypted Routing Protocol）是 Tailscale 在點對點 WireGuard 連線無法建立時（如對稱 NAT、防火牆、CGNAT）啟用的中繼機制，透過 TCP 443 連線，由中繼節點轉發封包。Hyper-DERP（HD）是以 C++ 搭配 io_uring 從零重寫的 DERP 實作，目標是以更低的資源消耗達到更高的吞吐量。
架構設計
HD 採用 share-nothing、shard-per-core 架構，每個 CPU 核心綁定一個獨立的 io_uring 實例，消除核心間的 context switch。跨 shard 通訊使用無鎖定的 SPSC ring buffer。TLS 握手在 userspace 以 OpenSSL 完成；金鑰安裝後，加解密移交核心 TLS（kTLS）處理。熱路徑中使用 slab allocator 和 frame pool 避免 malloc 呼叫。轉發決策以 hash table 查找實作；同 shard 內的封包轉發無需任何鎖定原語。
效能數據
以 GCP c4-highcpu 執行基準測試：
- 8 vCPU 下 HD 達 12,316 ± 247 Mbps；Tailscale derper 需要 16 vCPU 才能達到 7,834 Mbps。
- 2 vCPU / 5 Gbps 負載下，HD 達 3,730 Mbps；Tailscale 在同條件下崩潰至 324 Mbps。
- 封包遺失率：Tailscale 在 16 vCPU / 25 Gbps 下遺失 19%，2 vCPU / 5 Gbps 下高達 93%；HD 在極端條件下峰值為 12%。
- p99 延遲（8 vCPU）：HD 維持 129–153 μs（負載無關）；Tailscale 從 129 μs 升至 218 μs（+69 μs 劣化）。
- 100 peers 擴展測試中 Tailscale 吞吐量下降 38%，HD 保持水平。
kTLS 快取邊際效應
在飽和負載下，LLC miss rate 從 2.6% 跳升至 40%，分析顯示 AES-GCM 的工作集超出 L3 快取容量。以 perf 剖析，HD userspace 中繼碼佔 CPU 週期 2%，kTLS 佔 25%。此為 kTLS 實作的已知瓶頸，計畫透過 NIC 硬體 TLS offload 解決。
後續計畫
規劃中的功能包括 UDP 快速路徑 + DERP fallback 雙路中繼、核心 WireGuard 整合、Client SDK 以及 eBPF 封包引導至 XDP 程式。
CPU 暫存器重命名：架構暫存器與物理暫存器的分離機制
fp32.org · 2026-04-26
現代超純量處理器中，程式碼看到的架構暫存器（AArch64 的 x0–x31 等共約 66 個）只是一層抽象；實際在矽晶片上執行的是數量遠多於此的物理暫存器。理解這個差距是理解亂序執行（out-of-order execution）的前提。
假相依性（False Dependency）問題
考慮以下指令序列：
add x1, x2, x3 ; write x1
mul x1, x4, x5 ; write x1 again（與第一條無資料相依）兩條指令都寫入 x1，但它們之間沒有真正的資料相依關係（Write-After-Write, WAW 假相依）。若處理器以靜態暫存器號碼調度指令，第二條必須等第一條完成才能執行，製造不必要的序列化。
Rename Unit 與 RAT
重命名單元（rename unit/map unit）在解碼後立即為每個目的地架構暫存器分配一個空閒的物理暫存器。暫存器別名表（Register Alias Table, RAT）維護從架構暫存器到當前物理暫存器的映射，本質上是一個鍵值對（架構暫存器編號 → 物理暫存器指標）。分配完成後，後續讀取 x1 的指令直接讀取最新分配的物理暫存器，前一次寫入的物理暫存器繼續保存其值直到不再被任何指令引用。
零週期指令（Zero-Cycle Instructions）
重命名階段也能實現「零週期」指令：orr x1, xzr, x2（等同 mov x1, x2）在重命名時直接將 x1 的 RAT 條目指向 x2 目前對應的物理暫存器，無需進入執行單元。ARM Neoverse V2 的解碼器每週期可分派 4 個 micro-op，其後端有 17 個執行單元。
與 ROB 的互動
重新排序緩衝區（Reorder Buffer, ROB）負責追蹤所有飛行中的指令，並按程式順序提交結果。提交（commit/retire）時，物理暫存器中的值被正式寫入架構狀態，而被替換的舊物理暫存器歸還給空閒池，供未來的重命名使用。
Linux 核心維護者考慮移除老舊網路驅動：AI 自動回報造成維護負擔
Phoronix · 2026-04-26
Linux 核心郵件列表（LKML）近期出現討論，部分維護者提出移除一批多年未有實際使用者的舊網路驅動程式。觸發這波討論的原因之一是 AI 工具大量自動產生的 bug report 和 patch，雖然目的是修復編譯警告或靜態分析問題，但卻讓人工維護者耗費大量時間辨別有效提交與機器生成的雜訊。
問題背景
Linux 核心中存在許多針對已停產硬體（如早期 ISA/EISA 乙太網卡、某些 PCMCIA 網路卡）的驅動程式，這類驅動的原始硬體早已從市面消失。由於這些程式碼仍在樹中，AI 工具在執行全樹掃描時會持續對其生成修改建議，形成「無人真正使用，但工具持續觸碰」的局面。
維護者立場
提議者的主要論點是，若驅動長期無人回報真實 bug 或提交功能性改動，維護成本（審查 AI 生成的 patch、處理編譯器新版本警告）已超過保留的邊際效益。反對意見則指出，移除可能對仍在使用舊硬體的嵌入式或工業場景造成意外中斷，且移除後若有人需要再加回，歷史脈絡將會遺失。
更廣泛的訊號
此討論折射出開源核心維護的新壓力點：AI 驅動的自動化程式碼生成工具提高了低品質提交的頻率，迫使社群在貢獻門檻設定與歡迎新貢獻者之間重新尋找平衡。Greg Kroah-Hartman 等核心維護者此前已多次公開表示 AI 生成 patch 的審查負擔問題。
Apple Metal 有損紋理壓縮格式的逆向工程分析
Ignacio Castaño's Blog · 2026-04-26
Ignacio Castaño 針對 Apple Metal GPU 管線所使用的有損紋理壓縮格式（Metal Lossy Compression Format）進行逆向工程，揭示其位元組結構與壓縮策略。
格式定位
Metal 的有損壓縮格式並非公開規格；Apple 僅在 Metal API 層面提供啟用選項，未公開底層位元佈局。這類格式被 GPU 顯示引擎在讀取 framebuffer 時透明解壓，目的是降低頻寬消耗。逆向工程的切入點是分析 Metal command buffer 中 blit 操作的輸出模式，與已知的 ASTC 和 BC 系列格式行為作比對。
位元結構觀察
分析顯示該格式在 4×4 像素 block 層級進行有損量化，保留高頻細節的方式類似 ASTC 的端點量化機制，但編碼路徑針對 Apple GPU 的 tile memory 存取模式最佳化。在某些幾何圖形邊緣附近，格式會退回較低壓縮比的模式以減少 artifact，這與 ASTC 的 weight grid 適應性調整有結構性相似之處。
工程意義
理解此格式有助於跨平台圖形引擎（如 WebGPU 後端、遊戲引擎）評估在 Apple Silicon 上啟用有損壓縮的品質風險，以及在截圖工具、RenderDoc 等 GPU 偵錯工具中正確解碼 Metal framebuffer 內容。
原始來源：Metal Lossy Compression Format — Ignacio Castaño's Blog