Revision tags: v8.2.3, v7.2.11, v9.0.0, v9.0.0-rc4, v9.0.0-rc3, v9.0.0-rc2 |
|
#
5ef7e26b |
| 01-Apr-2024 |
Yuan Liu <yuan1.liu@intel.com> |
migration/multifd: solve zero page causing multiple page faults
Implemented recvbitmap tracking of received pages in multifd.
If the zero page appears for the first time in the recvbitmap, this pag
migration/multifd: solve zero page causing multiple page faults
Implemented recvbitmap tracking of received pages in multifd.
If the zero page appears for the first time in the recvbitmap, this page is not checked and set.
If the zero page has already appeared in the recvbitmap, there is no need to check the data but directly set the data to 0, because it is unlikely that the zero page will be migrated multiple times.
Signed-off-by: Yuan Liu <yuan1.liu@intel.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240401154110.2028453-2-yuan1.liu@intel.com [peterx: touch up the comment, as the bitmap is used outside postcopy now] Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
Revision tags: v8.2.3, v7.2.11, v9.0.0, v9.0.0-rc4, v9.0.0-rc3, v9.0.0-rc2 |
|
#
5ef7e26b |
| 01-Apr-2024 |
Yuan Liu <yuan1.liu@intel.com> |
migration/multifd: solve zero page causing multiple page faults
Implemented recvbitmap tracking of received pages in multifd.
If the zero page appears for the first time in the recvbitmap, this pag
migration/multifd: solve zero page causing multiple page faults
Implemented recvbitmap tracking of received pages in multifd.
If the zero page appears for the first time in the recvbitmap, this page is not checked and set.
If the zero page has already appeared in the recvbitmap, there is no need to check the data but directly set the data to 0, because it is unlikely that the zero page will be migrated multiple times.
Signed-off-by: Yuan Liu <yuan1.liu@intel.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240401154110.2028453-2-yuan1.liu@intel.com [peterx: touch up the comment, as the bitmap is used outside postcopy now] Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
Revision tags: v9.0.0-rc1 |
|
#
8fa1a21c |
| 21-Mar-2024 |
Fabiano Rosas <farosas@suse.de> |
migration/multifd: Fix clearing of mapped-ram zero pages
When the zero page detection is done in the multifd threads, we need to iterate the second part of the pages->offset array and clear the file
migration/multifd: Fix clearing of mapped-ram zero pages
When the zero page detection is done in the multifd threads, we need to iterate the second part of the pages->offset array and clear the file bitmap for each zero page. The piece of code we merged to do that is wrong.
The reason this has passed all the tests is because the bitmap is initialized with zeroes already, so clearing the bits only really has an effect during live migration and when a data page goes from having data to no data.
Fixes: 303e6f54f9 ("migration/multifd: Implement zero page transmission on the multifd thread.") Signed-off-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240321201242.6009-1-farosas@suse.de Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
#
bd4480b0 |
| 19-Mar-2024 |
Fabiano Rosas <farosas@suse.de> |
migration: Revert mapped-ram multifd support to fd: URI
This reverts commit decdc76772c453ff1444612e910caa0d45cd8eac in full and also the relevant migration-tests from 7a09f092834641b7a793d50a3a2610
migration: Revert mapped-ram multifd support to fd: URI
This reverts commit decdc76772c453ff1444612e910caa0d45cd8eac in full and also the relevant migration-tests from 7a09f092834641b7a793d50a3a261073bbb404a6.
After the addition of the new QAPI-based migration address API in 8.2 we've been converting an "fd:" URI into a SocketAddress, missing the fact that the "fd:" syntax could also be used for a plain file instead of a socket. This is a problem because the SocketAddress is part of the API, so we're effectively asking users to create a "socket" channel to pass in a plain file.
The easiest way to fix this situation is to deprecate the usage of both SocketAddress and "fd:" when used with a plain file for migration. Since this has been possible since 8.2, we can wait until 9.1 to deprecate it.
For 9.0, however, we should avoid adding further support to migration to a plain file using the old "fd:" syntax or the new SocketAddress API, and instead require the usage of either the old-style "file:" URI or the FileMigrationArgs::filename field of the new API with the "/dev/fdset/NN" syntax, both of which are already supported.
Signed-off-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240319210941.1907-1-farosas@suse.de Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
Revision tags: v9.0.0-rc0 |
|
#
303e6f54 |
| 11-Mar-2024 |
Hao Xiang <hao.xiang@bytedance.com> |
migration/multifd: Implement zero page transmission on the multifd thread.
1. Add zero_pages field in MultiFDPacket_t. 2. Implements the zero page detection and handling on the multifd threads for n
migration/multifd: Implement zero page transmission on the multifd thread.
1. Add zero_pages field in MultiFDPacket_t. 2. Implements the zero page detection and handling on the multifd threads for non-compression, zlib and zstd compression backends. 3. Added a new value 'multifd' in ZeroPageDetection enumeration. 4. Adds zero page counters and updates multifd send/receive tracing format to track the newly added counters.
Signed-off-by: Hao Xiang <hao.xiang@bytedance.com> Acked-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240311180015.3359271-5-hao.xiang@linux.dev Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
#
c3cdf3fb |
| 11-Mar-2024 |
Fabiano Rosas <farosas@suse.de> |
migration/multifd: Allow clearing of the file_bmap from multifd
We currently only need to clear the mapped-ram file bitmap from the migration thread during save_zero_page.
We're about to add suppor
migration/multifd: Allow clearing of the file_bmap from multifd
We currently only need to clear the mapped-ram file bitmap from the migration thread during save_zero_page.
We're about to add support for zero page detection on the multifd thread, so allow ramblock_set_file_bmap_atomic() to also clear the bits.
Signed-off-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240311180015.3359271-3-hao.xiang@linux.dev Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
#
61dec060 |
| 05-Mar-2024 |
Fabiano Rosas <farosas@suse.de> |
migration/multifd: Don't fsync when closing QIOChannelFile
Commit bc38feddeb ("io: fsync before closing a file channel") added a fsync/fdatasync at the closing point of the QIOChannelFile to ensure
migration/multifd: Don't fsync when closing QIOChannelFile
Commit bc38feddeb ("io: fsync before closing a file channel") added a fsync/fdatasync at the closing point of the QIOChannelFile to ensure integrity of the migration stream in case of QEMU crash.
The decision to do the sync at qio_channel_close() was not the best since that function runs in the main thread and the fsync can cause QEMU to hang for several minutes, depending on the migration size and disk speed.
To fix the hang, remove the fsync from qio_channel_file_close().
At this moment, the migration code is the only user of the fsync and we're taking the tradeoff of not having a sync at all, leaving the responsibility to the upper layers.
Fixes: bc38feddeb ("io: fsync before closing a file channel") Reviewed-by: "Daniel P. Berrangé" <berrange@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240305195629.9922-1-farosas@suse.de Link: https://lore.kernel.org/r/20240305174332.2553-1-farosas@suse.de [peterx: add more comment to the qio_channel_close()] Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
Revision tags: v9.0.0-rc0 |
|
#
303e6f54 |
| 11-Mar-2024 |
Hao Xiang <hao.xiang@bytedance.com> |
migration/multifd: Implement zero page transmission on the multifd thread.
1. Add zero_pages field in MultiFDPacket_t. 2. Implements the zero page detection and handling on the multifd threads for n
migration/multifd: Implement zero page transmission on the multifd thread.
1. Add zero_pages field in MultiFDPacket_t. 2. Implements the zero page detection and handling on the multifd threads for non-compression, zlib and zstd compression backends. 3. Added a new value 'multifd' in ZeroPageDetection enumeration. 4. Adds zero page counters and updates multifd send/receive tracing format to track the newly added counters.
Signed-off-by: Hao Xiang <hao.xiang@bytedance.com> Acked-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240311180015.3359271-5-hao.xiang@linux.dev Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
#
c3cdf3fb |
| 11-Mar-2024 |
Fabiano Rosas <farosas@suse.de> |
migration/multifd: Allow clearing of the file_bmap from multifd
We currently only need to clear the mapped-ram file bitmap from the migration thread during save_zero_page.
We're about to add suppor
migration/multifd: Allow clearing of the file_bmap from multifd
We currently only need to clear the mapped-ram file bitmap from the migration thread during save_zero_page.
We're about to add support for zero page detection on the multifd thread, so allow ramblock_set_file_bmap_atomic() to also clear the bits.
Signed-off-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240311180015.3359271-3-hao.xiang@linux.dev Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
#
61dec060 |
| 05-Mar-2024 |
Fabiano Rosas <farosas@suse.de> |
migration/multifd: Don't fsync when closing QIOChannelFile
Commit bc38feddeb ("io: fsync before closing a file channel") added a fsync/fdatasync at the closing point of the QIOChannelFile to ensure
migration/multifd: Don't fsync when closing QIOChannelFile
Commit bc38feddeb ("io: fsync before closing a file channel") added a fsync/fdatasync at the closing point of the QIOChannelFile to ensure integrity of the migration stream in case of QEMU crash.
The decision to do the sync at qio_channel_close() was not the best since that function runs in the main thread and the fsync can cause QEMU to hang for several minutes, depending on the migration size and disk speed.
To fix the hang, remove the fsync from qio_channel_file_close().
At this moment, the migration code is the only user of the fsync and we're taking the tradeoff of not having a sync at all, leaving the responsibility to the upper layers.
Fixes: bc38feddeb ("io: fsync before closing a file channel") Reviewed-by: "Daniel P. Berrangé" <berrange@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240305195629.9922-1-farosas@suse.de Link: https://lore.kernel.org/r/20240305174332.2553-1-farosas@suse.de [peterx: add more comment to the qio_channel_close()] Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
Revision tags: v9.0.0-rc0 |
|
#
303e6f54 |
| 11-Mar-2024 |
Hao Xiang <hao.xiang@bytedance.com> |
migration/multifd: Implement zero page transmission on the multifd thread.
1. Add zero_pages field in MultiFDPacket_t. 2. Implements the zero page detection and handling on the multifd threads for n
migration/multifd: Implement zero page transmission on the multifd thread.
1. Add zero_pages field in MultiFDPacket_t. 2. Implements the zero page detection and handling on the multifd threads for non-compression, zlib and zstd compression backends. 3. Added a new value 'multifd' in ZeroPageDetection enumeration. 4. Adds zero page counters and updates multifd send/receive tracing format to track the newly added counters.
Signed-off-by: Hao Xiang <hao.xiang@bytedance.com> Acked-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240311180015.3359271-5-hao.xiang@linux.dev Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
#
c3cdf3fb |
| 11-Mar-2024 |
Fabiano Rosas <farosas@suse.de> |
migration/multifd: Allow clearing of the file_bmap from multifd
We currently only need to clear the mapped-ram file bitmap from the migration thread during save_zero_page.
We're about to add suppor
migration/multifd: Allow clearing of the file_bmap from multifd
We currently only need to clear the mapped-ram file bitmap from the migration thread during save_zero_page.
We're about to add support for zero page detection on the multifd thread, so allow ramblock_set_file_bmap_atomic() to also clear the bits.
Signed-off-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240311180015.3359271-3-hao.xiang@linux.dev Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
#
61dec060 |
| 05-Mar-2024 |
Fabiano Rosas <farosas@suse.de> |
migration/multifd: Don't fsync when closing QIOChannelFile
Commit bc38feddeb ("io: fsync before closing a file channel") added a fsync/fdatasync at the closing point of the QIOChannelFile to ensure
migration/multifd: Don't fsync when closing QIOChannelFile
Commit bc38feddeb ("io: fsync before closing a file channel") added a fsync/fdatasync at the closing point of the QIOChannelFile to ensure integrity of the migration stream in case of QEMU crash.
The decision to do the sync at qio_channel_close() was not the best since that function runs in the main thread and the fsync can cause QEMU to hang for several minutes, depending on the migration size and disk speed.
To fix the hang, remove the fsync from qio_channel_file_close().
At this moment, the migration code is the only user of the fsync and we're taking the tradeoff of not having a sync at all, leaving the responsibility to the upper layers.
Fixes: bc38feddeb ("io: fsync before closing a file channel") Reviewed-by: "Daniel P. Berrangé" <berrange@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240305195629.9922-1-farosas@suse.de Link: https://lore.kernel.org/r/20240305174332.2553-1-farosas@suse.de [peterx: add more comment to the qio_channel_close()] Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
Revision tags: v8.2.2, v7.2.10 |
|
#
1a6e217c |
| 01-Mar-2024 |
Peter Xu <peterx@redhat.com> |
migration/multifd: Document two places for mapped-ram
Add two documentations for mapped-ram migration on two spots that may not be extremely clear.
Reviewed-by: Fabiano Rosas <farosas@suse.de> Link
migration/multifd: Document two places for mapped-ram
Add two documentations for mapped-ram migration on two spots that may not be extremely clear.
Reviewed-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240301091524.39900-1-peterx@redhat.com Cc: Prasad Pandit <ppandit@redhat.com> [peterx: fix two English errors per Prasad] Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
#
decdc767 |
| 29-Feb-2024 |
Fabiano Rosas <farosas@suse.de> |
migration/multifd: Add mapped-ram support to fd: URI
If we receive a file descriptor that points to a regular file, there's nothing stopping us from doing multifd migration with mapped-ram to that f
migration/multifd: Add mapped-ram support to fd: URI
If we receive a file descriptor that points to a regular file, there's nothing stopping us from doing multifd migration with mapped-ram to that file.
Enable the fd: URI to work with multifd + mapped-ram.
Note that the fds passed into multifd are duplicated because we want to avoid cross-thread effects when doing cleanup (i.e. close(fd)). The original fd doesn't need to be duplicated because monitor_get_fd() transfers ownership to the caller.
Signed-off-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Peter Xu <peterx@redhat.com> Link: https://lore.kernel.org/r/20240229153017.2221-23-farosas@suse.de Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
#
a49d15a3 |
| 29-Feb-2024 |
Fabiano Rosas <farosas@suse.de> |
migration/multifd: Support incoming mapped-ram stream format
For the incoming mapped-ram migration we need to read the ramblock headers, get the pages bitmap and send the host address of each non-ze
migration/multifd: Support incoming mapped-ram stream format
For the incoming mapped-ram migration we need to read the ramblock headers, get the pages bitmap and send the host address of each non-zero page to the multifd channel thread for writing.
Usage on HMP is:
(qemu) migrate_set_capability multifd on (qemu) migrate_set_capability mapped-ram on (qemu) migrate_incoming file:migfile
(the ram.h include needs to move because we've been previously relying on it being included from migration.c. Now file.h will start including multifd.h before migration.o is processed)
Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240229153017.2221-22-farosas@suse.de Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
#
f427d90b |
| 29-Feb-2024 |
Fabiano Rosas <farosas@suse.de> |
migration/multifd: Support outgoing mapped-ram stream format
The new mapped-ram stream format uses a file transport and puts ram pages in the migration file at their respective offsets and can be do
migration/multifd: Support outgoing mapped-ram stream format
The new mapped-ram stream format uses a file transport and puts ram pages in the migration file at their respective offsets and can be done in parallel by using the pwritev system call which takes iovecs and an offset.
Add support to enabling the new format along with multifd to make use of the threading and page handling already in place.
This requires multifd to stop sending headers and leaving the stream format to the mapped-ram code. When it comes time to write the data, we need to call a version of qio_channel_write that can take an offset.
Usage on HMP is:
(qemu) stop (qemu) migrate_set_capability multifd on (qemu) migrate_set_capability mapped-ram on (qemu) migrate_set_parameter max-bandwidth 0 (qemu) migrate_set_parameter multifd-channels 8 (qemu) migrate file:migfile
Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240229153017.2221-21-farosas@suse.de Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
#
2dd7ee7a |
| 29-Feb-2024 |
Fabiano Rosas <farosas@suse.de> |
migration/multifd: Add incoming QIOChannelFile support
On the receiving side we don't need to differentiate between main channel and threads, so whichever channel is defined first gets to be the mai
migration/multifd: Add incoming QIOChannelFile support
On the receiving side we don't need to differentiate between main channel and threads, so whichever channel is defined first gets to be the main one. And since there are no packets, use the atomic channel count to index into the params array.
Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240229153017.2221-19-farosas@suse.de Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
#
b7b03eb6 |
| 29-Feb-2024 |
Fabiano Rosas <farosas@suse.de> |
migration/multifd: Add outgoing QIOChannelFile support
Allow multifd to open file-backed channels. This will be used when enabling the mapped-ram migration stream format which expects a seekable tra
migration/multifd: Add outgoing QIOChannelFile support
Allow multifd to open file-backed channels. This will be used when enabling the mapped-ram migration stream format which expects a seekable transport.
The QIOChannel read and write methods will use the preadv/pwritev versions which don't update the file offset at each call so we can reuse the fd without re-opening for every channel.
Contrary to the socket migration, the file migration doesn't need an asynchronous channel creation process, so expose multifd_channel_connect() and call it directly.
Note that this is just setup code and multifd cannot yet make use of the file channels.
Signed-off-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Peter Xu <peterx@redhat.com> Link: https://lore.kernel.org/r/20240229153017.2221-18-farosas@suse.de Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
#
a8a3e710 |
| 29-Feb-2024 |
Fabiano Rosas <farosas@suse.de> |
migration/multifd: Add a wrapper for channels_created
We'll need to access multifd_send_state->channels_created from outside multifd.c, so introduce a helper for that.
Reviewed-by: Peter Xu <peterx
migration/multifd: Add a wrapper for channels_created
We'll need to access multifd_send_state->channels_created from outside multifd.c, so introduce a helper for that.
Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240229153017.2221-17-farosas@suse.de Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
#
d117ed06 |
| 29-Feb-2024 |
Fabiano Rosas <farosas@suse.de> |
migration/multifd: Allow receiving pages without packets
Currently multifd does not need to have knowledge of pages on the receiving side because all the information needed is within the packets tha
migration/multifd: Allow receiving pages without packets
Currently multifd does not need to have knowledge of pages on the receiving side because all the information needed is within the packets that come in the stream.
We're about to add support to mapped-ram migration, which cannot use packets because it expects the ramblock section in the migration file to contain only the guest pages data.
Add a data structure to transfer pages between the ram migration code and the multifd receiving threads.
We don't want to reuse MultiFDPages_t for two reasons:
a) multifd threads don't really need to know about the data they're receiving.
b) the receiving side has to be stopped to load the pages, which means we can experiment with larger granularities than page size when transferring data.
Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240229153017.2221-16-farosas@suse.de Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
#
06833d83 |
| 29-Feb-2024 |
Fabiano Rosas <farosas@suse.de> |
migration/multifd: Allow multifd without packets
For the upcoming support to the new 'mapped-ram' migration stream format, we cannot use multifd packets because each write into the ramblock section
migration/multifd: Allow multifd without packets
For the upcoming support to the new 'mapped-ram' migration stream format, we cannot use multifd packets because each write into the ramblock section in the migration file is expected to contain only the guest pages. They are written at their respective offsets relative to the ramblock section header.
There is no space for the packet information and the expected gains from the new approach come partly from being able to write the pages sequentially without extraneous data in between.
The new format also simply doesn't need the packets and all necessary information can be taken from the standard migration headers with some (future) changes to multifd code.
Use the presence of the mapped-ram capability to decide whether to send packets.
This only moves code under multifd_use_packets(), it has no effect for now as mapped-ram cannot yet be enabled with multifd.
Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240229153017.2221-15-farosas@suse.de Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
#
9db19125 |
| 29-Feb-2024 |
Fabiano Rosas <farosas@suse.de> |
migration/multifd: Decouple recv method from pages
Next patches will abstract the type of data being received by the channels, so do some cleanup now to remove references to pages and dependency on
migration/multifd: Decouple recv method from pages
Next patches will abstract the type of data being received by the channels, so do some cleanup now to remove references to pages and dependency on 'normal_num'.
Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240229153017.2221-14-farosas@suse.de Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
#
4aac6b1e |
| 29-Feb-2024 |
Fabiano Rosas <farosas@suse.de> |
migration/multifd: Cleanup multifd_recv_sync_main
Some minor cleanups and documentation for multifd_recv_sync_main.
Use thread_count as done in other parts of the code. Remove p->id from the multif
migration/multifd: Cleanup multifd_recv_sync_main
Some minor cleanups and documentation for multifd_recv_sync_main.
Use thread_count as done in other parts of the code. Remove p->id from the multifd_recv_state sync, since that is global and not tied to a channel. Add documentation for the sync steps.
Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240229153017.2221-2-farosas@suse.de Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
Revision tags: v8.2.2, v7.2.10 |
|
#
1a6e217c |
| 01-Mar-2024 |
Peter Xu <peterx@redhat.com> |
migration/multifd: Document two places for mapped-ram
Add two documentations for mapped-ram migration on two spots that may not be extremely clear.
Reviewed-by: Fabiano Rosas <farosas@suse.de> Link
migration/multifd: Document two places for mapped-ram
Add two documentations for mapped-ram migration on two spots that may not be extremely clear.
Reviewed-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240301091524.39900-1-peterx@redhat.com Cc: Prasad Pandit <ppandit@redhat.com> [peterx: fix two English errors per Prasad] Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|