RFC-0223：zx_vmo_transfer_data

摘要

建議您新增 syscall zx_vmo_transfer_data，讓呼叫端可以 在不同 VMO 之間移動頁面可以視為效率 改善資料遷移功能，在不產生複製作業的情況下遷移資料。

提振精神

Fuchsia 成效過去分析後，發現深層、階層結構中的 CoW 團隊 因為 Bootfs 重複點選連結，導致查詢網頁的搜尋時間過長。 這個系統呼叫會把複製鏈替換為 「簡化」包含 Bootfs 個別項目的 VMO。

雖然 Bootfs 是目前動機，但未來可能還有其他情況 移動網頁的能力有助於提升效能。

相關人員

誰會負責確認 RFC 是否已獲接受？(這個部分為選填，但 encouraged.)

講師：cpu@

審查人員：rashaeqbal@、jamesr@

顧問：mcgrathr@、maniscalco@、adanis@、eieio@

社交：這項提案被社交化為 Zircon 單頁簡介 。

設計

我們會將下列 syscall 新增至 Zircon syscall API：

zx_status_t zx_vmo_transfer_data(zx_handle_t dst_vmo,
                                 uint32_t options,
                                 uint64_t offset,
                                 uint64_t length,
                                 zx_handle_t src_vmo,
                                 uint64_t src_offset);

其中：

• dst_vmo 是目的地 VMO 的控制代碼。這個帳號代碼必須包含 ZX_RIGHT_WRITE。
• options 是目前未使用的欄位，允許在 未來的發展方向
• offset 是頁面移至目的地的偏移值。
• length 是移至目的地的位元組數。
• src_vmo 是來源 VMO 的控制代碼。這個帳號代碼必須包含 《ZX_RIGHT_READ》和《ZX_RIGHT_WRITE》。
• src_offset 是網頁從來源擷取時的偏移值。

這場 Syscall 會移動「[src_offset, src_offset + length)」的網頁 從 src_vmo 到 dst_vmo 的 [offset, offset + length)。可以正常運作 相當於 src_vmo 到 dst_vmo 的 memmove，後面跟著 「src_vmo」的相關網頁。不過，每次曝光的機制 但這些成就並不相同備用頁面實際上是在 VMO 之間移動 而非複製資料進而提高效能。儘管如此 此 syscall 表示與 memmove 相同的語意， 系統支援提供來源和目的地區域重疊的資料來源。

讀者可能會想知道為什麼系統呼叫了 zx_vmo_transfer_data 而非 zx_vmo_transfer_pages。這個選擇太刻意了 排除嚴格的網頁對齊規定 例如，在使用者用途中 要求移轉一頁和半個頁面。在這個例子中，我們會把 然後複製剩餘的半頁這就算是 更有效率 到達網頁。請注意，初始實作不支援 用途這只是為了提供名稱的背景資訊 就是用哪一種烤箱或刀子都可以 那麼預先建構的容器或許是最佳選擇

目的地範圍內的現有網頁會遭到覆寫。下列所有對應項目： 目的地 VMO 也會看到新內容如果目的地 VMO 子項的類型會影響孩子看到的內容。 ZX_VMO_CHILD_SNAPSHOT 和 ZX_VMO_CHILD_SNAPSHOT_MODIFIED 類型的子項 仍會看到舊內容其他所有類型的孩童會看到 新的內容移動完成後，「src_vmo」中的頁面將會是零 。

移動失敗的原因有很多。請參閱錯誤部分 下方列有可能的錯誤代碼，以及 傳回。

如果遷移失敗，表示 src_vmo VMO 中可能沒有任何頁面數量 已移至 dst_vmo。我們無法保證移轉的資料量， 但是，我們可以保證在符合下列條件的情況下，呼叫成功 條件相符：

1. 所有會導致下列錯誤的條件都不成立。
2. 在此期間，其他執行緒不會修改 src_vmo 和 dst_vmo 作業執行中。

「修改」這裡指的是 VMO 的寫入/調整大小/釘選作業 或參考 VMO 的參照 (例如切片、參照子項等) 如果任何快照類型的父項、子項或同層，均不得變更。 任何錯誤，但視快照而定，您可能會收到撕裂。 如果操控 SNAPSHOT_AT_LEAST_ON_WRITE VMO 實際轉移作業並未承諾 單元性請注意，如果要從 SNAPSHOT 子項目轉移網頁，我們會 而可能就需要複製新網頁 (如果該網頁含有 未複製。

以下是此 Syscall 可能傳回的錯誤及其含意：

• ZX_ERR_BAD_HANDLE：src_vmo 或 dst_vmo 不是有效的 VMO 控制代碼，
• ZX_ERR_INVALID_ARGS：offset、length 或 src_offset 不是頁面 對齊。如先前所述，我們可能會在
• ZX_ERR_ACCESS_DENIED：src_vmo不含 ZX_RIGHT_WRITE， ZX_RIGHT_READ，或 dst_vmo 沒有 ZX_RIGHT_WRITE。
• ZX_ERR_BAD_STATE：指定範圍內的網頁 (src_vmo 或 dst_vmo) 已固定。
• ZX_ERR_NOT_SUPPORTED：src_vmo 或 dst_vmo 可以是實體、 連續或經過呼叫的 VMO。我們可能得以支援呼叫網頁工具 VMO。
• ZX_ERR_OUT_OF_RANGE：dst_vmo 或 src_vmo 中指定的範圍是 無效。
• ZX_ERR_NO_MEMORY：因記憶體不足而失敗。

實作

這應為相對簡單明瞭的 CL 集合，因為我們已有 Sycall zx_pager_supply_pages 對呼叫器做出非常類似的動作 支援的 VMO因此，我們就可以重複使用許多支援系統呼叫的程式碼。 不過，我們需要進行幾項變更，以支援這個新的使用案例：

1. zx_pager_supply_pages 會驗證提供的 VMO 是否由 指定的呼叫器物件必須在新的 Syscall 中移除。
2. SupplyPages，zx_pager_supply_pages 函式可用來插入頁面 並假設該元件存在呼叫器 (在程式碼中稱為 page_source_。我們必須在 在 page_source_ 上運作，並移除其存在的所有斷言。
3. SupplyPages 也會解壓縮所有壓縮頁面，並在前面加上標記 將網頁套用至目的地，這應該是到達網頁 已支援呼叫器。匿名 VMO 並非如此，因此我們必須 比對到達網頁是否受到 Pager 支援。
4. SupplyPages 目前會略過目的地中的所有網頁，但 仍會釋出來源的網頁。如先前所述 即可一律覆寫目的地
5. SupplyPages 目前並未列入具有父項的 VMO。大多數 就不構成問題不過，如果目的地是 ZX_VMO_CHILD_SNAPSHOT 類型的子項，我們必須更新分割位元 來表示 VMO 與隱藏的父項不同

成效

我們預計這樣會大幅改善 Bootfs 中的 VMO 頁面查詢效能。 幸好，從目前使用的 CoW 複製鏈切換至移動頁面 就能將啟動檔案系統查詢量提升約 20%。 請注意，透過建立副本，我們可以達到類似的啟動檔案系統查詢改善 而非便捷的 VMO 策略不過 這種做法會使系統的啟動時間降低達 70% (取決於 執行操作)。採用此方法 此迴歸中大部分的迴歸問題 (RFC)。

回溯相容性

我們不會移除現有的 zx_pager_supply_pages Sycall，因此不會 可能不會預期任何回溯相容性問題。

安全性考量

我們預期本提案不會產生任何安全性風險， 新運算在功能上適用於 作業 (memcpy() + uncommit)，但效能較佳。不 這項工具專為眾所周知的作業方式，

然而，它卻會增加攻擊面。如果 Google Cloud 控制台中 任何程序都能利用系統呼叫的系統。

隱私權注意事項

我們預期這項提案不會造成任何隱私權影響。

測試

我們會新增核心測試，以使用新 syscall 來驗證所有 上文記錄的行為 (頁面移動、限制以及從來源中排除 網頁)。我們也會新增評估指標 以便與副本的成效比較。

說明文件

我們將新增說明 zx_vmo_transfer_data 的文件。

缺點、替代方案和未知

我們可以將 zx_pager_supply_pages 一般化，以與匿名的 VMO 合作。這個 會讓該 syscall 的實作方式更加複雜。 可能仍需要修改 API 才能接受匿名 VMO，因為 。

如果我們的唯一目標是改善 CoW 本機副本中的網頁查詢效能 如使用啟動檔案系統或 Bootf 建立 CoW 本機副本然而，這會大幅降低啟動時間 因此就會產生額外副本