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

[Stefan Hajnoczi]

On Sun, Mar 10, 2013 at 11:38 AM, Dietmar Maurer <address@hidden> wrote:
>> > 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?
>>
>> There are enough avenues to investigate better performance that I think the
>> solution is to just profile and optimize a little.
>
> I know that I can optimize, but I always thought it is better to avoid 
> overhead
> it is possible. Socket based IPC involves copying large amount of data, and 
> you
> cannot optimize that away.

I have attached the top of the perf -a -g profile for my RFC series.
Observations:

 * Disk encryption is the biggest CPU hog (19%)
 * QEMU memmove takes 4.64%, haven't figured out where it gets called from
 * buffer_is_zero() takes 1.47%, that's less than cpuidle (system has 4 cores).
 * Python and QEMU together only take 1.57% for
copy_user_enhanced_fast_string() (used for sendmsg/recvmsg)

Socket memcpy overhead is lower than the unidentified memmove() in QEMU.

The vma-writer.c code you posted has several memcpy(), I don't think
the socket memcpy makes up for a big percentage.  Rather, lowering the
frequency of messages and employing pipelining will let the system get
more work done with less communication.

Stefan

report.txt
Description: Text document