Features/Migration-Multiple-fds: Difference between revisions
(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