| RFC-0223：zx_vmo_transfer_data | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 推出名為 zx_vmo_transfer_data 的全新 syscall，能夠有效率地在 VMO 之間移動資料。 |
| 問題 |
|
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 2023-05-22 |
| 審查日期 (年/月) | 2023-08-14 |
摘要
建議您新增系統呼叫 zx_vmo_transfer_data，讓呼叫端可以在 VMO 之間移動頁面。這可以想成是能夠提高資料移動效率，而不會產生複製負擔。
提振精神
過往的富奇亞成效分析結果顯示，使用者查詢頁面時，將深層階層式的箱子複製鏈結在一起，導致搜尋頁面的時間過長。這項系統呼叫會把複製鏈結替換為包含 Bootf 個別項目的「手動複製」VMO，藉此減少這類負擔。
雖然「Bootfs」是目前動機，但日後或許有其他可移動頁面的能力可以改善效能。
相關人員
誰擔心是否接受這個 RFC？(本節為選填，但建議填寫)。
講師：cpu@
審查者：rashaeqbal@、jamesr@
顧問：mcgrathr@、maniscalco@、adanis@、eieio@
社交化：這份提案被視為 Zircon 團隊單頁簡介，
設計
我們將在 Zircon syscall API 中新增以下 syscall：
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是目前未使用的欄位，於日後允許擴充 API。offset是頁面移至目的地時的偏移值。length是要移至目的地的位元組數。src_vmo是來源 VMO 的控制代碼。這個帳號代碼必須包含ZX_RIGHT_READ和ZX_RIGHT_WRITE。src_offset是從來源擷取網頁時的偏移值。
這項系統呼叫會將 [src_offset, src_offset + length) 中的網頁從 dst_vmo 的 src_vmo 移至 [offset, offset + length)。它在功能上等同於從 src_vmo 到 dst_vmo 的 memmove，然後在 src_vmo 中停用相關頁面。但是，用來達到的機制不同；備份頁面實際上是在 VMO 之間移動，而不是複製資料。進而提升成效。儘管採用不同的機制，此系統呼叫與 memmove 顯示的語意相同，因為系統支援提供重疊的來源和目的地區域。
讀者可能會想知道系統呼叫為何稱為 zx_vmo_transfer_data，而不是如果會移動頁面，則為 zx_vmo_transfer_pages。這是刻意設定，以因應日後的嚴格頁面對齊要求。舉例來說，我們可能想支援使用者要求頁面和半個頁面轉移的用途。在這種情況下，我們會移動第一個頁面，然後複製其餘的半頁。這仍比使用者的一般副本更有效率，因為這樣我們就能略過將到達網頁預設為零的狀態。請注意，初始實作項目不支援這個使用情境，此處僅提及，只是提供有關命名選項的背景資訊。
目標範圍內的現有頁面將遭到覆寫。目標 VMO 的所有對應關係也會看到新內容。如果目的地 VMO 含有子項，則子項類型會影響子項看到的內容。ZX_VMO_CHILD_SNAPSHOT 和 ZX_VMO_CHILD_SNAPSHOT_MODIFIED 類型的子項會繼續看到舊內容。所有其他類型的子項都會看到新內容。移動完成後，src_vmo 中的頁面就會歸零。
移動失敗的原因有很多。請參閱下方的錯誤一節，其中完整列舉了可能的錯誤代碼，以及會傳回這些代碼的情境。
如果移動失敗，src_vmoVMO 中的任意頁面數量可能已移至 dst_vmo。我們無法保證移轉的資料量多寡。
不過，我們可以在符合下列條件時，確保呼叫成功：
- 不符合以下錯誤的條件。
- 在這項作業執行期間，任何其他執行緒並未修改
src_vmo和dst_vmo。
在這種情況下，「修改」是指直接在 VMO 上寫入/調整/固定，或是參照 VMO 參照 (例如配量、參照子項等)。修改任何種類的父項、子項或同層快照不會導致任何錯誤，但視您可能會執行的快照而定。如果您操控 SNAPSHOT_AT_LEAST_ON_WRITE VMO 的父項，因為實際移轉作業未保證不可分割性，就會發生寫入預告。請注意，如果是從 SNAPSHOT 子項轉移頁面，我們可能需要執行副本，亦即分配新的頁面，如果尚未寫入該特定網頁。
以下是這個 Sys 呼叫可能傳回的錯誤和代表的意義：
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 組合，因為我們現有的系統呼叫 zx_pager_supply_pages 會對呼叫器支援的 VMO 進行非常類似的操作。因此，我們可以重複使用許多支援系統呼叫的程式碼。不過，我們必須進行幾項變更，以支援這個新的應用實例：
zx_pager_supply_pages會驗證提供的 VMO 是否由指定的分頁器物件支援。因此，您需要在新的系統呼叫中移除這個金鑰。SupplyPages，zx_pager_supply_pages用來將頁面插入 VMO 的函式假設已有 Pager，（在程式碼中稱為page_source_）。我們必須新增 NULL 檢查，才能移除這項假設，然後才在page_source_上執行作業，並移除其存在的任何斷言。SupplyPages也會解壓縮所有壓縮頁面，並在頁面傳入目的地前新增標記，因為系統預期目的地會經過分頁驗證。匿名 VMO 不需要這麼做，因此我們需要做出條件來決定是否支援目的地。SupplyPages目前會略過目的地中的任何網頁，但仍會釋放來源中的頁面。如先前所述，我們會變更為一律覆寫目的地。SupplyPages目前並未將有父項的 VMO 納入考量。在大多數情況下，這不會造成問題。不過，如果目的地是ZX_VMO_CHILD_SNAPSHOT類型的子項，就需要更新父項中的分割位元，表明 VMO 與隱藏的父項無關。
效能
我們預期這麼做可以大幅改善 Bootfs 中的 VMO 頁面查詢效能。相反地，如果從目前使用的 CoW 本機副本鏈結為使用這項系統呼叫來移動頁面，則啟動啟動檔案系統查詢作業的效能會提升約 20%。請注意，我們可以建立 VMO 的副本，而非移動這類系統呼叫建議的頁面，進而獲得類似的啟動檔案系統查詢改善。不過，這個做法最多能將系統的啟動時間迴歸最多 70% (視執行的目標硬體目標而定)。使用這個 RFC 建議的方法可抵擋大部分的這種迴歸。
回溯相容性
我們不打算移除現有的 zx_pager_supply_pages 系統呼叫，因此預期回溯相容性沒有任何問題。
安全性考量
我們預期本提案不會內建任何安全性影響，因為新作業旨在在功能上與現有作業 (memcpy() + uncommit) 相等，但效能較佳。這個平台的用意是讓程序可以執行尚未實現的功能。
儘管如此，這種做法會增加受攻擊面。如果系統呼叫實作中有可遭利用的錯誤，則任何程序都可能會利用這些錯誤。
隱私權注意事項
我們預期這項提案不會對隱私權造成任何影響。
測試
我們將新增使用新系統呼叫的核心測試，並驗證上述所有行為 (頁面移動、限制和來源頁面移出零)。我們也將新增用於測量這個系統呼叫效能的基準，這個基準可以與副本的效能進行比較。
說明文件
我們將新增說明 zx_vmo_transfer_data 的文件。
缺點、替代方案和未知
我們可以將 zx_pager_supply_pages 一般化，以便與匿名 VMO 搭配使用。這會讓該 sys 呼叫的實作更加複雜，你可能還是需要修改 API，才能接受匿名 VMO 做為輸入內容。
如果只有一個目標是要改善啟動中 CoW 本機副本階層中網頁查詢的效能，也可以只使用 VMO 的副本，而不建立 CoW 本機副本。不過，由於額外的複製負擔，這會大幅迴歸啟動時間。