qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 0/8] block: Live backup prototype


From: Dietmar Maurer
Subject: Re: [Qemu-devel] [RFC 0/8] block: Live backup prototype
Date: Sun, 10 Mar 2013 09:14:35 +0000

> The objection to this approach has been performance.  Exporting vmstate and
> disk data over UNIX domain sockets to an external process incurs IPC overhead.
> This prototype shows that even Python code hacked up in a day achieves decent
> performance.
> 
> I'm leaving benchmarking as an exercise for the reader.  I tested a single 
> scenario
> with a 16 GB raw disk and 1 GB RAM, backup time was 28% longer (+30
> seconds) than Dietmar's series.  Below are a few starting points:

I already have an implementation based on nbd.c, and that also shows 
considerable overhead.
A Backup task is extremely performance critical, so any additional overhead is 
bad.
I can see the advantage to move the code out of qemu, but I want to avoid that 
overhead
by all means. So are there any other ideas to avoid the overhead of a socket 
based IPC?

>  * I moved the buffer_is_zero() check from the VMA writer into the block job.
>    We now skip writing zero clusters and the file contains no extents for 
> them.

With VMA we track zero blocks at 4KB level. If you move that code, you need to
test for zero regions two times, because NBD offers no way to pass that 
information (sending
multiple discard message at 4KB level is no option because that adds to much 
overhead).

NBD does not allow to pass additional infos, and it is quite slow. So it would 
be even faster
to write to a pipe and define our own backup protocol instead (less syscalls). 
But I have not done
any performance measurement for that.

Many thanks for your efforts on that topic. It would be great if we can get at 
least the first
patch "add basic backup support to block driver" into qemu. This is the basic 
framework, and
a starting point for anyone who want to play around with backup.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]