[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: Alex Bligh
Subject: Re: [Qemu-devel] commit b1bbfe72 causes huge slowdown with no kvm
Date: Wed, 20 Nov 2013 13:47:19 +0000


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.

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

reply via email to

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