[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] commit b1bbfe72 causes huge slowdown with no kvm
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] commit b1bbfe72 causes huge slowdown with no kvm |
Date: |
Wed, 20 Nov 2013 12:19:15 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9 |
Il 20/11/2013 12:00, Luigi Rizzo ha scritto:
>
> WITHOUT THE PATCH, booting becomes slow as soon as the timer tick starts
> and we load dummynet (which also starts a kernel thread every
> millisecond).
> You should be able to see how the printing of kernel messages slows down
> terribly around this point:
>
> ...
> Timecounters tick every 1.000 msec
> ipfw2 initialized, divert loadable, nat loadable, default to accept,
> logging disabled
> DUMMYNET 0 with IPv6 initialized (100409)
> ....
>
> and then it takes a long/varible time to reach the login prompt,
> easily a couple of minutes or more.
> If you start pkt-gen now, you should see a much lower rate,
> around 300-500Kpps
>
>
>
> Since the problem seems timer-related, it makes sense that you are
> not seeing much difference in linux which is probably tickless,
> and that the trouble comes out on FreeBSD after the timers are
> initialized.
Saw it now with your FreeBSD guest.
> But again I have no idea if my patch (which simply reverts part of
> the offending commit) makes sense.
No, the patch is wrong. :(
Before Alex's patch, setting a timer did a timer_settime system call.
After, setting the timer exits QEMU's event loop (which uses poll) and
reenters it with a new deadline. This wouldn't be a problem; the
difference is between one system call (timer_settime and a signal
delivery (SIGALRM) before the patch, and two system calls afterwards
(write to a pipe or eventfd + calling poll again when re-entering the
event loop).
Unfortunately, the exit/enter causes the main loop to grab the iothread
lock, which in turns kicks the VCPU thread out of execution.
The problem happens with "-smp 2" because FreeBSD uses a "pause"
instruction in its idle loop, and QEMU does not implement it. Thus
a lot of time is wasted running the second, idle VCPU rather than
the first.
The fix could be to implement the pause instruction.
Paolo
Paolo