|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] Re: [PATCH 2/7] Enable I/O thread and VNC threads by default |
Date: | Tue, 08 Feb 2011 13:17:50 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10 |
On 02/08/2011 05:15 AM, Aurelien Jarno wrote:
Anthony Liguori a écrit :On 02/08/2011 04:06 AM, Aurelien Jarno wrote:Yes, it's slow. But is it a problem? You assume that people use QEMU only for emulating SMP platforms. This is a wrong assumption. Beside the x86 target, only sparc really supports SMP emulation.It's *not* just about performance. TCG requires a signal to break out of a tight chained TB loop. If you have a guest in a tight loop waiting for something external (like polling on a in-memory flag), the device emulation will not get to run until a signal is fired. Unless you set SIGIO on every file descriptor that selects polls on (and you can't because there are a number that just don't support SIGIO), then you have a race condition.In practice you will get a signal when the next timer event expire. I agree it's suboptimal, but it works, and has been like that for here.
During early boot up before the periodic timer is enabled can cause quite a noticable issue here.
I think it's cris specifically that does polling I/O in the early startup before any periodic timer is enabled.
Having that fixed through an I/O thread is actually quite nice, however it should not be done ignoring all the *current* drawbacks of the iothread mode. We know them (at least for some of them), so let's try to solve them.
Yes, agree 100%.
And now, I don't buy the argument "it's been there for years", it was *disabled* by default.
Yeah, I think we need to enable it by default and commit to fixing all of the outstanding issues.
I think we've fixed all that we're aware of but we probably won't find the rest unless we enable it universally.
Regards, Anthony Liguori
[Prev in Thread] | Current Thread | [Next in Thread] |