Re: [Qemu-devel] Re: [PATCH 2/7] Enable I/O thread and VNC threads by default

[Aurelien Jarno <aurelien@aurel32.net>]

Anthony Liguori a écrit :
> 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.

So the strategy is let's break everything and wait for the maintainer to
fix that? This strategy doesn't work, we have seen for example that with
the SeaBIOS switch. While it brings nice features, it has broken the
isapc machine. And it's still not fixed...

Also this strategy doesn't scale, then the maintainers are spending
their time fixing bugs introduced because others didn't care. Resources
are not unlimited, especially for those doing that on their free time.

> I think we've fixed all that we're aware of but we probably won't find 
> the rest unless we enable it universally.

I agree that we are going to discover bugs, and it's normal. QEMU is
quite complex and it's not possible to test every combination. That said
we are already aware of some bugs, why not fix them, or at least try to
fix them? For example we haven't fixed the performance regression with
TCG (at least it wasn't the case two weeks ago).

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net