Message ID | 1372373098-5877-2-git-send-email-mrhines@linux.vnet.ibm.com |
---|---|
State | New |
Headers | show |
On 06/27/2013 04:44 PM, mrhines@linux.vnet.ibm.com wrote: > 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(-) > > +++ 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: 10 != ... > 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) ...12. Also, is it worth indenting things with extra spaces in your original series, so that this series (and even future follow-on series) have more space to use without having to reindent? That is, why not leave room after your current longest command: 12. Unregister finished (confirmation that unpin completed) and adjust the remaining lines to line up.
On 06/27/2013 07:09 PM, Eric Blake wrote: > On 06/27/2013 04:44 PM, mrhines@linux.vnet.ibm.com wrote: >> 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(-) >> >> +++ 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: > 10 != ... > >> 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) > ...12. > > Also, is it worth indenting things with extra spaces in your original > series, so that this series (and even future follow-on series) have more > space to use without having to reindent? That is, why not leave room > after your current longest command: > > 12. Unregister finished (confirmation that unpin completed) > > and adjust the remaining lines to line up. > Understood. (I got your other corrections in as well - just sent this series out too fast before I read your other emails.)
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.