Il 19/03/2013 19:40, Paolo Bonzini ha scritto:
That however gives me an idea... Instead of the full drain at the end
of an iteration, does it make sense to do a "partial" drain at every
chunk full, so that you don't have > N bytes pending and the downtime is
correspondingly limited?
Sure, you could do that, but it seems overly complex just to avoid
a single flush() call at the end of each iteration, right?
Would it really be that complex? Not having an extra QEMUFile op
perhaps balances that complexity (and the complexity remains hidden in
rdma.c, which is an advantage).
You could alternatively drain every N megabytes sent, or something like
that. But a partial drain would help obeying the maximum downtime
limitations.
On second thought: just keep the drain operation, but make it clear that
it is related to the new save_ram_page QEMUFileOps field. You could
call it flush_ram_pages or something like that.
Paolo