aboutsummaryrefslogtreecommitdiff
path: root/tests/functional/qemu_test/linuxkernel.py
diff options
context:
space:
mode:
authorFabiano Rosas <farosas@suse.de>2024-08-27 14:45:59 -0300
committerFabiano Rosas <farosas@suse.de>2024-09-03 16:24:35 -0300
commita71ef5c7f329533a49ab164b92945267be864ede (patch)
tree6f18fef4432497f2875ecf29406df9f75de5107d /tests/functional/qemu_test/linuxkernel.py
parentd7e58f412cf6c5426efda60558f0ccfbf709f646 (diff)
downloadqemu-a71ef5c7f329533a49ab164b92945267be864ede.zip
qemu-a71ef5c7f329533a49ab164b92945267be864ede.tar.gz
qemu-a71ef5c7f329533a49ab164b92945267be864ede.tar.bz2
migration/multifd: Replace multifd_send_state->pages with client data
Multifd currently has a simple scheduling mechanism that distributes work to the various channels by keeping storage space within each channel and an extra space that is given to the client. Each time the client fills the space with data and calls into multifd, that space is given to the next idle channel and a free storage space is taken from the channel and given to client for the next iteration. This means we always need (#multifd_channels + 1) memory slots to operate multifd. This is fine, except that the presence of this one extra memory slot doesn't allow different types of payloads to be processed at the same time in different channels, i.e. the data type of multifd_send_state->pages needs to be the same as p->pages. For each new data type different from MultiFDPage_t that is to be handled, this logic would need to be duplicated by adding new fields to multifd_send_state, to the channels and to multifd_send_pages(). Fix this situation by moving the extra slot into the client and using only the generic type MultiFDSendData in the multifd core. Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
Diffstat (limited to 'tests/functional/qemu_test/linuxkernel.py')
0 files changed, 0 insertions, 0 deletions