[Top][All Lists]

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]