Il 20/11/2013 14:47, Alex Bligh ha scritto:
> I think you are saying this sounds like another underlying bug
> (no pause instruction) uncovered by the timer patches rather than
> a bug in the timer patches.
>
> Reading
> http://software.intel.com/file/27087
> perhaps the answer is for pause to yi
Paolo,
On 20 Nov 2013, at 11:19, Paolo Bonzini wrote:
> 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
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
> te
On Wed, Nov 20, 2013 at 10:41:22AM +0100, Paolo Bonzini wrote:
> Il 20/11/2013 00:00, Luigi Rizzo ha scritto:
> > I recently found out that without kvm enabled, and especially
> > with -smp 2 or greater, qemu becomes incredibly slow
> > (to the point that you can see kernel messages in the
> > ques
Il 20/11/2013 00:00, Luigi Rizzo ha scritto:
> I recently found out that without kvm enabled, and especially
> with -smp 2 or greater, qemu becomes incredibly slow
> (to the point that you can see kernel messages in the
> quest print one character at a time).
>
> This happens with a Linux host (ev
I recently found out that without kvm enabled, and especially
with -smp 2 or greater, qemu becomes incredibly slow
(to the point that you can see kernel messages in the
quest print one character at a time).
This happens with a Linux host (even with -smp 1)
and with FreeBSD host (in this case -smp
