[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [PATCH 1/6] rdma: update documentation to reflect new unpin
From: |
mrhines |
Subject: |
[Qemu-devel] [PATCH 1/6] rdma: update documentation to reflect new unpin support |
Date: |
Thu, 27 Jun 2013 18:44:53 -0400 |
From: "Michael R. Hines" <address@hidden>
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 <address@hidden>
---
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
- [Qemu-devel] [PATCH 5/6] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition, (continued)
- [Qemu-devel] [PATCH 5/6] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition, mrhines, 2013/06/27
- [Qemu-devel] [PATCH 3/6] rdma: core logic, mrhines, 2013/06/27
- Re: [Qemu-devel] [PATCH 3/6] rdma: core logic, Peter Maydell, 2013/06/27
- Re: [Qemu-devel] [PATCH 3/6] rdma: core logic, Michael R. Hines, 2013/06/28
- Re: [Qemu-devel] [PATCH 3/6] rdma: core logic, Peter Maydell, 2013/06/28
- Re: [Qemu-devel] [PATCH 3/6] rdma: core logic, Michael R. Hines, 2013/06/28
- Re: [Qemu-devel] [PATCH 3/6] rdma: core logic, Peter Maydell, 2013/06/28
- Re: [Qemu-devel] [PATCH 3/6] rdma: core logic, Michael R. Hines, 2013/06/28
Re: [Qemu-devel] [PATCH 3/6] rdma: core logic, Paolo Bonzini, 2013/06/28
[Qemu-devel] [PATCH 1/6] rdma: update documentation to reflect new unpin support,
mrhines <=
[Qemu-devel] [PATCH 4/6] rdma: allow state transitions between other states besides ACTIVE, mrhines, 2013/06/27