← Back to branch summary

~ubuntu-branches/ubuntu/vivid/qemu/vivid

« back to all changes in this revision

Viewing changes to docs/rdma.txt

  • Committer: Package Import Robot
  • Author(s): Serge Hallyn
  • Date: 2014-02-25 22:31:43 UTC
  • mfrom: (1.8.5)
  • Revision ID: package-import@ubuntu.com-20140225223143-odhqxfc60wxrjl15
Tags: 2.0.0~rc1+dfsg-0ubuntu1
https://launchpad.net/bugs/1294823
https://launchpad.net/bugs/1295072
* Merge 2.0.0-rc1
* debian/rules: consolidate ppc filter entries.
* Move qemu-system-arch64 into qemu-system-arm
* debian/patches/define-trusty-machine-type.patch: define a trusty machine
  type, currently the same as pc-i440fx-2.0, to put is in a better position
  to enable live migrations from trusty onward.  (LP: #1294823)
* debian/control: build-dep on libfdt >= 1.4.0  (LP: #1295072)
* Merge latest upstream git to commit dc9528f
* Debian/rules:
  - remove -enable-uname-release=2.6.32
  - don't make the aarch64 target Ubuntu-specific.
* Remove patches which are now upstream:
  - fix-smb-security-share.patch
  - slirp-smb-redirect-port-445-too.patch 
  - linux-user-Implement-sendmmsg-syscall.patch (better version is upstream)
  - signal-added-a-wrapper-for-sigprocmask-function.patch
  - ubuntu/signal-sigsegv-protection-on-do_sigprocmask.patch
  - ubuntu/Don-t-block-SIGSEGV-at-more-places.patch
  - ubuntu/ppc-force-cpu-threads-count-to-be-power-of-2.patch
* add link for /usr/share/qemu/bios-256k.bin
* Remove all linaro patches.
* Remove all arm64/ patches.  Many but not all are upstream.
* Remove CVE-2013-4377.patch which is upstream.
* debian/control-in: don't make qemu-system-aarch64 ubuntu-specific

Show diffs side-by-side

added added

removed removed

Lines of Context:
docs/rdma.txt
66
66
high-performance RDMA hardware using the following command:
67
67
 
68
68
QEMU Monitor Command:
69
 
$ migrate_set_capability x-rdma-pin-all on # disabled by default
 
69
$ migrate_set_capability rdma-pin-all on # disabled by default
70
70
 
71
71
Performing this action will cause all 8GB to be pinned, so if that's
72
72
not what you want, then please ignore this step altogether.
93
93
 
94
94
Next, on the destination machine, add the following to the QEMU command line:
95
95
 
96
 
qemu ..... -incoming x-rdma:host:port
 
96
qemu ..... -incoming rdma:host:port
97
97
 
98
98
Finally, perform the actual migration on the source machine:
99
99
 
100
100
QEMU Monitor Command:
101
 
$ migrate -d x-rdma:host:port
 
101
$ migrate -d rdma:host:port
102
102
 
103
103
PERFORMANCE
104
104
===========
120
120
active use and the VM itself is completely idle using the same 40 gbps
121
121
infiniband link:
122
122
 
123
 
1. x-rdma-pin-all disabled total time: approximately 7.5 seconds @ 9.5 Gbps
124
 
2. x-rdma-pin-all enabled total time: approximately 4 seconds @ 26 Gbps
 
123
1. rdma-pin-all disabled total time: approximately 7.5 seconds @ 9.5 Gbps
 
124
2. rdma-pin-all enabled total time: approximately 4 seconds @ 26 Gbps
125
125
 
126
126
These numbers would of course scale up to whatever size virtual machine
127
127
you have to migrate using RDMA.
407
407
 
408
408
TODO:
409
409
=====
410
 
1. 'migrate x-rdma:host:port' and '-incoming x-rdma' options will be
411
 
   renamed to 'rdma' after the experimental phase of this work has
412
 
   completed upstream.
413
 
2. Currently, 'ulimit -l' mlock() limits as well as cgroups swap limits
 
410
1. Currently, 'ulimit -l' mlock() limits as well as cgroups swap limits
414
411
   are not compatible with infinband memory pinning and will result in
415
412
   an aborted migration (but with the source VM left unaffected).
416
 
3. Use of the recent /proc/<pid>/pagemap would likely speed up
 
413
2. Use of the recent /proc/<pid>/pagemap would likely speed up
417
414
   the use of KSM and ballooning while using RDMA.
418
 
4. Also, some form of balloon-device usage tracking would also
 
415
3. Also, some form of balloon-device usage tracking would also
419
416
   help alleviate some issues.
420
 
5. Move UNREGISTER requests to a separate thread.
421
 
6. Use LRU to provide more fine-grained direction of UNREGISTER
 
417
4. Use LRU to provide more fine-grained direction of UNREGISTER
422
418
   requests for unpinning memory in an overcommitted environment.
423
 
7. Expose UNREGISTER support to the user by way of workload-specific
 
419
5. Expose UNREGISTER support to the user by way of workload-specific
424
420
   hints about application behavior.