Re: [Qemu-devel] commit b1bbfe72 causes huge slowdown with no kvm

[Alex Bligh]

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