On 31.10.2012, at 17:46, Anthony Liguori wrote: > Alexander Graf <ag...@suse.de> writes: > >> On 31.10.2012, at 17:00, Anthony Liguori wrote: >> >>> Alexander Graf <ag...@suse.de> 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