[Qemu-devel] [PATCH 1/6] rdma: update documentation to reflect new unpin support

[mrhines@linux.vnet.ibm.com]

From: "Michael R. Hines" <mrhines@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 <mrhines@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