* Denis V. Lunev (d...@openvz.org) wrote: > On 6/15/20 3:17 PM, Dr. David Alan Gilbert wrote: > > * Denis V. Lunev (d...@openvz.org) wrote: > >> This series do standard basic things: > >> - it creates intermediate buffer for all writes from QEMU migration code > >> to QCOW2 image, > >> - this buffer is sent to disk asynchronously, allowing several writes to > >> run in parallel. > >> > >> In general, migration code is fantastically inefficent (by observation), > >> buffers are not aligned and sent with arbitrary pieces, a lot of time > >> less than 100 bytes at a chunk, which results in read-modify-write > >> operations with non-cached operations. It should also be noted that all > >> operations are performed into unallocated image blocks, which also suffer > >> due to partial writes to such new clusters. > > It surprises me a little that you're not benefiting from the buffer > > internal to qemu-file.c > > > > Dave > There are a lot of problems with this buffer: > > Flushes to block driver state are performed in the abstract places, > pushing > Â a) small IO > Â b) non-aligned IO both to > Â Â Â Â Â Â 1) page size > Â Â Â Â Â Â 2) cluster size > It should also be noted that buffer in QEMU file is quite small and > all IO operations with it are synchronous. IO, like ethernet, wants > good queues.
Yeh, for ethernet we immediately get the kernels buffer so it's not too bad; and I guess the async page writes are easier as well. Dave > The difference is on the table. > > Den > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK