Bug 1038563

Summary:	Higher host cpu usage on achi driver compared ide driver
Product:	Red Hat Enterprise Linux 7	Reporter:	Xiaomei Gao <xigao>
Component:	qemu-kvm	Assignee:	John Snow <jsnow>
Status:	CLOSED WONTFIX	QA Contact:	Yanhui Ma <yama>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0	CC:	hhuang, juzhang, kwolf, michen, qzhang, rbalakri, virt-maint, wquan, yama
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-11-16 22:21:44 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Comment 3 John Snow 2014-07-17 20:42:19 UTC

Pushing back to 7.2.

AHCI is currently in a tech-preview state and is not feature-complete. As such, it's likely to undergo some major refactoring in the near-future as I try to bring this feature into a stable state. I won't be focusing on optimizations in the immediate time frame, so this is more likely a 7.2 target.

Comment 5 John Snow 2015-06-25 18:33:56 UTC

AHCI support is nearly shored up upstream, but performance enhancements will have to wait until QEMU 2.5 and RHEV 7.3.

Comment 8 John Snow 2017-11-16 22:21:44 UTC

AHCI has never really been prioritized for performance improvements. Our official recommend has been that users seeking performance should use virtio-blk-scsi or virtio-blk-pci; that AHCI is perhaps slower than IDE is not of tremendous concern.

That said, if *severe* performance impediments can be observed, I'd like to fix them -- but I should stop pretending it's a priority for the enterprise product as *ATA devices are generally used only to install the OS, and then most management solutions clone their VMs from there.

ATA interfaces are hardly used for our downstream product, and that's the way it ought to be.

As such, I'm going to close this bug for now as "WONTFIX," but if you find anything obviously abhorrently wrong or prohibitively slow, please reopen and I will investigate it.

Further, if anyone manages to find this bug via google and you have good evidence for exactly _what_ is slow, or have new information to contribute, or would like this fixed upstream, please email me and cc the qemu-block list upstream and we will work on resolving this in the FOSS version of this package.

Thanks,
John