[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 0/4] block: seriously improve savevm performance
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [PATCH v3 0/4] block: seriously improve savevm performance |
Date: |
Mon, 15 Jun 2020 13:49:13 +0100 |
User-agent: |
Mutt/1.14.0 (2020-05-02) |
* Denis V. Lunev (den@openvz.org) wrote:
> On 6/15/20 3:17 PM, Dr. David Alan Gilbert wrote:
> > * Denis V. Lunev (den@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 / dgilbert@redhat.com / Manchester, UK
- Re: [PATCH 2/4] block/aio_task: allow start/wait task from any coroutine, (continued)