[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 04/20] qemu-file: We only call qemu_file_transferred_* on
From: |
Peter Xu |
Subject: |
Re: [PATCH v2 04/20] qemu-file: We only call qemu_file_transferred_* on the sending side |
Date: |
Mon, 5 Jun 2023 14:18:26 -0400 |
On Tue, May 30, 2023 at 08:39:25PM +0200, Juan Quintela wrote:
> Remove the increase in qemu_file_fill_buffer() and add asserts to
> qemu_file_transferred* functions.
>
> Signed-off-by: Juan Quintela <quintela@redhat.com>
The read side accounting does look a bit weird and never caught my notice..
Maybe worth also touching the document of QEMUFile::total_transferred to
clarify what it accounts?
Reviewed-by: Peter Xu <peterx@redhat.com>
Though when I'm looking at the counters (didn't follow every single recent
patch on this..), I found that now reading transferred value is actually
more expensive - qemu_file_transferred() needs flushing, even if for the
fast version, qemu_file_transferred_fast() loops over all possible iovs,
which can be as large as MAX_IOV_SIZE==64.
To be explicit, I _think_ for each guest page we now need to flush...
ram_save_iterate
migration_rate_exceeded
migration_transferred_bytes
qemu_file_transferred
I hope I'm wrong..
Does it mean that perhaps we simply need "sent and put into send buffer"
more than "what really got transferred"? So I start to wonder what's the
origianl purpose of this change, and which one is better..
--
Peter Xu
- Re: [PATCH v2 04/20] qemu-file: We only call qemu_file_transferred_* on the sending side,
Peter Xu <=