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.
