針對 data page 的 Copy-on-Write/XIP (轉貼紀錄)

October 23, 2006

針對 data page 的 Copy-on-Write/XIP

CE Linux Forum 的 wiki 上，有一篇由 Panasonic Mobile Communications Co., Ltd. 所提出的新技術 [Data Read-In-Place]，不同以往針對 Linux kernel 的大幅修改，這個作法只修改了 dynamic loader (ld-linux.so)。在描述這個作法之前，先來觀察 ELF 執行檔的 .data section 在執行時期的行為，參考下圖：

對多數應用程式來說，Dynamic loader 必須將 .data section 予以 linear mapped 至 virtual address 中，於是我們可以發現，當進行 read 或 write 動作時，行為如下圖：

而 Application-level XIP (eXecution-In-Place) 會希望 .data section 能永久保存於 Flash 儲存裝置中，除非 .data section 本身發生變化 (被 write)，所以 [Data Read-In-Place] 提出一個簡單有效的機制，將原本 mmap 的範圍從：

mmap(..., PROT_READ | PROT_WRITE);

修改為：

mmap(..., PROT_READ);
mprotect(..., PROT_READ | PROT_WRITE);

當進行 mmap ELF segment 時，捨棄 PROT_WRITE 這個 bit，這使得 cramfs 行為變成「如同 XIP .text 一般，去 mapping 每個在 .data section 的 page 到 ROM pages」，而透過 mprotect 去設定 PROT_WRITE，這使得：

• vm_area_struct 允許作 write
• PTE (page table entry) 的 write 權限則被抑制

換言之，我們已經實做了 CoW (Copy-on-Write)，這之間微妙的變化，可參考之前的翻譯文章 [探索 Linux Memory Model (上)] 與 [探索 Linux Memory Model (下)]。在上述機制引入後，系統呈現的效果如下圖：

Panasonic Mobile Communications Co., Ltd. 提出的方法，在最低程度的修改下，實做 In-Place 的 data read，依據官方說法：

"The total effect for one system measured by Panasonic was a reduction of 26% of the page cache allocated to processes, when the product was in the stand-by state."

不過，這也引來額外的 ROM access latency，會導致程式執行時間拉長，對一般的消費性電子裝置來說是可以接受的 (single executable)。wiki 上提供的 patch 似乎不太完整，所以我弄了新 patch：[glibc-2.3.2-DRIP.patch]，加入 [OpenEmbedded] 一類的工具中即可。

cramfs 的 XIP 有許多可最佳化的空間，或許有機會等某個產品設計完畢後，可試著整理，而我也開始觀察 [AXFS - Advanced XIP File System] 的實做，相關的討論可見 LKML [RFC: Advanced XIP File System]。
由 jserv 發表於 October 23, 2006 10:07 PM