On 04/14/2011 04:59 PM, Anthony Liguori wrote:
On 04/14/2011 08:45 AM, Avi Kivity wrote:
On 04/14/2011 10:14 AM, Jan Kiszka wrote:
On 2011-04-13 22:16, Aurelien Jarno wrote:
> On Mon, Apr 11, 2011 at 10:27:41PM +0200, Jan Kiszka wrote:
>> These patches were posted before. They bring down the overhead
of the
>> io-thread mode for TCG here, specifically when emulating SMP.
>>
>> The major change in this version, besides rebasing, is the
exclusion of
>> KVM from the main loop polling optimization.
>>
>>
>>
>> Jan Kiszka (3):
>> Do not drop global mutex for polled main loop runs
>> Poll main loop after I/O events were received
>> Do not kick vcpus in TCG mode
>>
>> cpus.c | 2 +-
>> sysemu.h | 2 +-
>> vl.c | 22 ++++++++++++++++------
>> 3 files changed, 18 insertions(+), 8 deletions(-)
>>
>
> Thanks for working on improving the io-thread with TCG. Your patches
> make sense, but they don't seems to fix the slowdown observed when
> enabling the io-thread. Well maybe they were not supposed to.
This is
> for example the results of netperf between guest and host using
virtio:
>
> no io-thread 122 MB/s
> io-thread 97 MB/s
> io-thread + patches 98 MB/s
>
Can you capture ftraces of io-thread enabled& disabled runs? They just
need to cover a hand full of frames.
Also interesting would be the context switch rates on the host.
If they're large, perhaps using user-space threading instead of
native threads would help.
I still suspect mitigation as the culprit here. Select is going to
get to run more often which means more interrupt generation.
I bet if you count the number of packets per interrupt/notify you'll
find that less batching is occurring.
Can you clarify? Which mitigation? virtio-net interrupt mitigation?
virtio-net interrupt mitigation is time-based, no? so why should
threading affect it? and why would select() run more often? since we
make all fds generate a signal, we ought to run a similar number same
number of select()s.
--
error compiling committee.c: too many arguments to function
