qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] Add a memory barrier to DMA functions


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] Add a memory barrier to DMA functions
Date: Tue, 22 May 2012 16:40:54 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 05/22/2012 07:03 AM, Michael S. Tsirkin wrote:
On Tue, May 22, 2012 at 09:41:41PM +1000, Benjamin Herrenschmidt wrote:
On Tue, 2012-05-22 at 14:14 +0300, Michael S. Tsirkin wrote:
The baseline is the laptop without kvm talking to the server. The
TCP_STREAM test results are:

It's not a good test. The thing most affecting throughput results is
how
much CPU does you guest get. So as a minumum you need to measure CPU
utilization on the host and divide by that.

The simple fact that we don't reach the baseline while in qemu seems to
be a reasonably good indication that we tend to be CPU bound already so
it's not -that- relevant. It would be if we were saturating the network.

But yes, I can try to do more tests tomorrow, it would be nice if you
could contribute a proper test protocol (or even test on some machines)
since you seem to be familiar with those measurements (and I have a very
limited access to x86 gear ... basically just my laptop).

Cheers,
Ben.

I have a deja vu. Amos sent perf results when you argued about
exactly the same issue in guest virtio. Delta was small but
measureable. At the moment I have no free time or free hardware
to redo the same work all over again. It's a well known fact that
actual memory barrier is slow on x86 CPUs. You can't see
it with network on your laptop? Write a microbenchmark.

The latest patch doesn't put a barrier in map(). I have an extremely hard time believing anything that uses _rw is going to be performance sensitive.

There is a correctness problem here. I think it's important that we fix that and then we can focus on improving performance later.

Regards,

Anthony Liguori






reply via email to

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