Re: [Qemu-devel] Re: [PATCH 2/7] Enable I/O thread and VNC threads by default

[Marcelo Tosatti <mtosatti@redhat.com>]

On Wed, Feb 09, 2011 at 09:07:52PM +0100, Anthony Liguori wrote:
> On 02/09/2011 06:35 PM, Aurelien Jarno wrote:
> >On Tue, Feb 08, 2011 at 04:08:28PM +0100, Aurelien Jarno wrote:
> >>Aurelien Jarno a écrit :
> >>>Paolo Bonzini a écrit :
> >>>>On 02/08/2011 12:15 PM, Aurelien Jarno wrote:
> >>>>>however
> >>>>>it should not be done ignoring all the*current*  drawbacks of the
> >>>>>iothread mode. We know them (at least for some of them), so let's try to
> >>>>>solve them.
> >>>>Let's also enumerate them.
> >>>>
> >>> From what I know:
> >>>- performance regression in TCG mode
> >>I setup an x86_64 guest on an x86_64 host (Intel Xeon E5345). Nothing
> >>was running except the standard daemons and the CPU governor was set to
> >>"performance" on all CPU. I then compared the network performance using
> >>netperf in default mode, through a tap interface and a virtio nic. I got
> >>the following results (quite reproducible, std below 0.5):
> >>- without IO thread: 107.36 MB/s
> >>- with IO thread:     89.93 MB/s
> >>
> >And the same test on the code from september 2009:
> >- without IO thread: 141.8 MB/s
> virtio-net is super finicky regarding mitigation strategies and
> their relationship to the I/O thread.  Different benchmarks will
> behave differently.  virtio-blk is probably a better device to test
> as you'll get much more consistent results across different type of
> I/O patterns.

netperf server on guest, RHEL5.4 guest (e1000), uq/master branch, TCG:

iothread: 236MB/s
no iothread: 215MB/s

Also noticed scp was slightly faster with iothread earlier this week,
don't remember numbers.