Features/Migration-Multiple-fds: Difference between revisions

From QEMU
(Created page with '== Feature Name == Use multiple FD's for migration == owner == * '''Name:''' Juan Quintela…')
 
No edit summary
Line 11: Line 11:


== Summary ==
== Summary ==
Currently there is a single stream for migration, this causes several problems:
* CPU that does the reception is a bottleneck on 10Gigabit and faster
* We copy all the pages for migration, even when we can send directly
* We make Transparent HugePages more difficult to use
So, the idea here is to split the migration stream in two, one for the current code, and the other for the content of the RAM pages.  This avoids the copies altogether.


== Scope ==
== Scope ==
Only needs changes in QEMU.  It can be configured if used or not for the cases where the destination don't know about it.


== How to use ==
== How to use ==
To enable the feature:
  migrate_set_capability x-multiple-fds on
And it would be use from there.  Notice that it needs to be enabled in both sides.


== Added commands / state ==
== Added commands / state ==
* Migration capability: x-multiple-fds
* Migration capability: x-multiple-fds
== Design ==


=== Major components ===
=== Major components ===


== Future Enhancements ==
== Future Enhancements ==
* Enable the use of more than one fd
* Use a different fd for postcopy page faults
* Use a different fd for postcopy page faults
* Use a different fd for each compression/decompression cpu
* Use a different fd for each compression/decompression cpu

Revision as of 12:21, 16 December 2015

Feature Name

Use multiple FD's for migration

owner

  • Name: Juan Quintela
  • Email: quintela@redhat.com
  • IRC: quintela (oftc/freenode)

Current Status

WIP

Summary

Currently there is a single stream for migration, this causes several problems:

  • CPU that does the reception is a bottleneck on 10Gigabit and faster
  • We copy all the pages for migration, even when we can send directly
  • We make Transparent HugePages more difficult to use

So, the idea here is to split the migration stream in two, one for the current code, and the other for the content of the RAM pages. This avoids the copies altogether.

Scope

Only needs changes in QEMU. It can be configured if used or not for the cases where the destination don't know about it.

How to use

To enable the feature:

 migrate_set_capability x-multiple-fds on

And it would be use from there. Notice that it needs to be enabled in both sides.

Added commands / state

  • Migration capability: x-multiple-fds

Design

Major components

Future Enhancements

  • Enable the use of more than one fd
  • Use a different fd for postcopy page faults
  • Use a different fd for each compression/decompression cpu