From: "Michael R. Hines" <mrhi...@us.ibm.com> As requested, the protocol now includes memory unpinning support. This has been implemented in a non-optimized manner, in such a way that one could devise an LRU or other workload-specific information on top of the basic mechanism to influence the way unpinning happens during runtime.
The feature is not yet user-facing, and is thus can only be enable at compile-time. Signed-off-by: Michael R. Hines <mrhi...@us.ibm.com> --- docs/rdma.txt | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/docs/rdma.txt b/docs/rdma.txt index 45a4b1d..c842da4 100644 --- a/docs/rdma.txt +++ b/docs/rdma.txt @@ -204,15 +204,17 @@ observations on the maximum future benefit of simultaneous page registrations. The 'type' field has 10 different command values: 1. Unused - 2. Error (sent to the source during bad things) - 3. Ready (control-channel is available) - 4. QEMU File (for sending non-live device state) - 5. RAM Blocks request (used right after connection setup) - 6. RAM Blocks result (used right after connection setup) - 7. Compress page (zap zero page and skip registration) - 8. Register request (dynamic chunk registration) - 9. Register result ('rkey' to be used by sender) - 10. Register finished (registration for current iteration finished) + 2. Error (sent to the source during bad things) + 3. Ready (control-channel is available) + 4. QEMU File (for sending non-live device state) + 5. RAM Blocks request (used right after connection setup) + 6. RAM Blocks result (used right after connection setup) + 7. Compress page (zap zero page and skip registration) + 8. Register request (dynamic chunk registration) + 9. Register result ('rkey' to be used by sender) + 10. Register finished (registration for current iteration finished) + 11. Unregister request (unpin previously registered memory) + 12. Unregister finished (confirmation that unpin completed) A single control message, as hinted above, can contain within the data portion an array of many commands of the same type. If there is more than @@ -413,3 +415,6 @@ TODO: the use of KSM and ballooning while using RDMA. 4. Also, some form of balloon-device usage tracking would also help alleviate some issues. +5. Use LRU or workload-specific information to provide more + fine-grained direction of UNREGISTER requests for unpinning + memory in an overcommitted environment. -- 1.7.10.4