From: Paolo Bonzini <pbonzini@redhat.com>
To: Luigi Rizzo <rizzo@iet.unipi.it>
Cc: qemu-devel <qemu-devel@nongnu.org>, Alex Bligh <alex@alex.org.uk>
Subject: Re: [Qemu-devel] commit b1bbfe72 causes huge slowdown with no kvm
Date: Wed, 20 Nov 2013 12:19:15 +0100 [thread overview]
Message-ID: <528C9AB3.905@redhat.com> (raw)
In-Reply-To: <20131120110000.GD20821@onelab2.iet.unipi.it>
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
next prev parent reply other threads:[~2013-11-20 11:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-19 23:00 [Qemu-devel] commit b1bbfe72 causes huge slowdown with no kvm Luigi Rizzo
2013-11-20 9:41 ` Paolo Bonzini
2013-11-20 11:00 ` Luigi Rizzo
2013-11-20 11:19 ` Paolo Bonzini [this message]
2013-11-20 13:47 ` Alex Bligh
2013-11-20 13:55 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=528C9AB3.905@redhat.com \
--to=pbonzini@redhat.com \
--cc=alex@alex.org.uk \
--cc=qemu-devel@nongnu.org \
--cc=rizzo@iet.unipi.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).