[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B32315C.1000006@codemonkey.ws>
Date: Wed, 23 Dec 2009 09:03:56 -0600
From: Anthony Liguori <anthony@...emonkey.ws>
To: Andi Kleen <andi@...stfloor.org>
CC: Avi Kivity <avi@...hat.com>, Ingo Molnar <mingo@...e.hu>,
Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
Gregory Haskins <gregory.haskins@...il.com>,
kvm@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>,
torvalds@...ux-foundation.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
netdev@...r.kernel.org,
"alacrityvm-devel@...ts.sourceforge.net"
<alacrityvm-devel@...ts.sourceforge.net>
Subject: Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/23/2009 06:14 AM, Andi Kleen wrote:
>> http://www.redhat.com/f/pdf/summit/cwright_11_open_source_virt.pdf
>>
>> See slide 32. This is without vhost-net.
>
> Thanks. Do you also have latency numbers?
They'll be along the lines of the vbus numbers.
But I caution people from relying too much on just netperf TCP_RR and
TCP_STREAM numbers. There's a lot of heuristics in play in getting this
sort of numbers. They really aren't good ways to compare different drivers.
A better thing to do is look more deeply at the architectures and
consider things like the amount of copying imposed, the cost of
processing an exit, and the mechanisms for batching packet transmissions.
The real argument that vbus needs to make IMHO is not "look how much
better my netperf TCP_STREAM results are" but "we can eliminate N copies
from the transmit path and virtio-net cannot" or "we require N exits to
handle a submission and virtio-net requires N+M".
It's too easy to tweak for benchmarks.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists