[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] commit b1bbfe72 causes huge slowdown with no kvm
From: |
Alex Bligh |
Subject: |
Re: [Qemu-devel] commit b1bbfe72 causes huge slowdown with no kvm |
Date: |
Wed, 20 Nov 2013 13:47:19 +0000 |
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 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.
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 yield the lock.
However, what if an arbitrary guest foolishly /does/ do a tight
spinlock without calling pause? If we have a multiprocessor
emulated guest perhaps it should be yielding every few thousand
instructions anyway?
--
Alex Bligh