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
