Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular

[Alexander Graf]

On 31.10.2012, at 17:46, Anthony Liguori wrote:

> Alexander Graf <address@hidden> writes:
> 
>> On 31.10.2012, at 17:00, Anthony Liguori wrote:
>> 
>>> Alexander Graf <address@hidden> writes:
>>> 
>>>> On 31.10.2012, at 15:40, Paolo Bonzini wrote:
>>>> 
>>>>> Il 31/10/2012 15:20, Markus Armbruster ha scritto:
>>>>>> One more thing: on a *major* upgrade, I'd rather deal with immediately
>>>>>> obvious breakage (does not boot) than rotten performance.
>>>>>> 
>>>>>> If we make "q35 with compat IDE" the default, we'll have to tell users
>>>>>> many, many times not to use the default :(
>>>>> 
>>>>> Well, compat IDE is not on the same league as writethrough for bad
>>>>> performance, and virtio is anyway the better choice (and not available
>>>>> just with a different machine type).
>>>> 
>>>> Are you seriously considering to carry that IDE legacy around simply
>>>> because we are too dumb to create working command line options? AHCI
>>>> gets you at least parallel disk access, so in most cases it's a lot
>>>> more sane than IDE.
>>> 
>>> First, we only guarantee guest compatibility if -M with a versioned
>>> machine is used.
>>> 
>>> The absence of '-M XXX' means: newest whizz-bang features QEMU has to
>>> offer while giving reasonable guest support.
>>> 
>>> Knowing what the state of AHCI performance is compared to other options
>>> (like virtio), I wouldn't dream of telling someone who cares about
>>> performance to use AHCI.
>>> 
>>> The only advantage I see of AHCI today is that you can have more than 4
>>> disks.  We can do that with legacy mode and still support the full set
>>> of guests we support today.
>>> 
>>> It's a no brainer IMHO.
>>> 
>>> This has nothing to do with command lines.  This is simple a case of a
>>> user asking "give me a machine with two disks".  The question is, what
>>> should those disks be?  They should be IDE because compatibility trumps
>>> performance.
>> 
>> That's the same reasoning that we used for cache=writethrough. It just
>> plain sucks.
> 
> Simply not true.
> 
> The default was cache=writethrough because it was a simple matter of
> correctness.
> 
> *You will lose data with cache=writeback if the guest doesn't send
> FLUSHes*.
> 
> RHEL5.x vintage of Linux didn't issue FLUSH at all.
> 
> We were able to change to cache=writeback not because we decided we
> don't care about RHEL5.x but because we now support WCE toggling from
> the guest which let's a RHEL5.x guest set WCE=0 and more importantly,
> informs the guest of the fact that WCE=1 by default.
> 
>> Why can't we just drop Windows XP from the out of box
>> experience and get everyone to at least 80% performance, rather than
>> having a compatible, but completely useless VM.
> 
> We had 11,286 hits from WinXP last month on qemu.org
> 
> Compare that to 16,716 hits for 64-bit Linux and a mere 9,516 hits for
> 32-bit Linux.

So how many hits is that for Mac OS X? That one only works with AHCI, but 
breaks with PIIX IDE.

> WinXP is still an important guest.  And the real problem is that using
> SATA is a catostrophic failure.  The guest won't install or boot at all.
> 
> And more to the point, AHCI performance is not very good anyway.  You
> keep making assertions about how much better it is but I don't see data
> to back that up (especially compared to where we're at with state of the
> art virtio).

I would really like to see good numbers on that. Performance certainly did 
degrade over time. The biggest issue I've see is that the in-kernel APIC always 
issues an ioctl on qemu_irq_lower() which happens a lot in cases where the line 
is already down. But I'd be more than happy to see some actual performance 
analysis of the matter.


Alex