Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1161805 - Bad IO performance on SSD MacBookPro 13 late 2013 model [NEEDINFO]
Summary: Bad IO performance on SSD MacBookPro 13 late 2013 model
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-11-07 22:44 UTC by Fred van Zwieten
Modified: 2015-02-24 16:13 UTC (History)
8 users (show)

Fixed In Version: kernel-3.17.3-200.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-24 16:13:49 UTC
Type: Bug
Embargoed:
jforbes: needinfo?


Attachments (Terms of Use)
This iostat is during the install of only 1 package: tzdata -. package 5/238) (deleted)
2014-11-08 09:39 UTC, Fred van Zwieten
no flags Details

Description Fred van Zwieten 2014-11-07 22:44:45 UTC
Description of problem:
I have very bad IO performance with Fedora 20 and 21 beta on a MacBookPro 13" late 2013 model. Where it is visible is during install and during yum update with large rpm's, like a kernel update or kernel-devel package. The hardware is reported like this:

04:00.0 SATA controller: Samsung Electronics Co Ltd Apple PCIe SSD (rev 01) (prog-if 01 [AHCI 1.0])
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 256 bytes
	Interrupt: pin A routed to IRQ 47
	Region 5: Memory at b0700000 (32-bit, non-prefetchable) [size=8K]
	Expansion ROM at b0710000 [disabled] [size=64K]
	Capabilities: [40] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] MSI: Enable+ Count=2/2 Maskable+ 64bit+
		Address: 00000000fee00398  Data: 0000
		Masking: 00000002  Pending: 00000000
	Capabilities: [70] Express (v2) Endpoint, MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 5GT/s, Width x4, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us
			ClockPM+ Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk+
			ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 5GT/s, Width x2, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR+, OBFF Not Supported
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF Disabled
		LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
			 EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
	Capabilities: [d0] Vital Product Data
pcilib: sysfs_read_vpd: read failed: Connection timed out
		Not readable
	Capabilities: [100 v2] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		AERCap:	First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
	Capabilities: [140 v1] Device Serial Number 00-00-00-00-00-00-00-00
	Capabilities: [150 v1] Power Budgeting <?>
	Capabilities: [160 v1] Latency Tolerance Reporting
		Max snoop latency: 3145728ns
		Max no snoop latency: 3145728ns
	Kernel driver in use: ahci


Version-Release number of selected component (if applicable):
3.17.2-300.fc21.x86_64

How reproducible:
Use the same HW

Steps to Reproduce:
1. Install fedora on this
2. yum update
3.

Actual results:
Very low performance during yum/rpm. I don't see any resource having problems in top, so i think it is more something with locking or something like that. 

Expected results:
Stellar performance (512 SSD, 16GB mem)

Additional info:
Pls let me know what additional info must be provided or which tests i should run

Comment 1 Fred van Zwieten 2014-11-08 09:20:14 UTC
I found the following on the Internet:
http://article.gmane.org/gmane.linux.ide/58740
https://bugzilla.kernel.org/show_bug.cgi?id=60731

The way I test is a bit strange but it works all the time. I have a rhel 7 iso on my ssd in >/Downloads. I fire up virt-manager, create a vm, accepting all the defaults and using the rhel7 iso. The setup is also default. The problems start when the install gets to actually yum all packages on the vm disk. It slows down to a crawl.

I tried all settings in the mentioned links. The only thing that makes it fly again is adding nobarrier to the root mountpoint in fstab.

When it's really slow I see an iostat %util at or near 100% on sda. When I pause the vm install it drops immediatly.

yum/rpm seems to hit a disk in a very bad way. I do not only see this during the yum phase in a vm install, but also when doing a yum update or install on the box itself.

I will attach an iostat output.

Comment 2 Fred van Zwieten 2014-11-08 09:39:45 UTC
Created attachment 955197 [details]
This iostat is during the install of only 1 package: tzdata -. package 5/238)

Comment 3 Josh Boyer 2014-11-10 21:09:35 UTC
I added the patch to F20-rawhide.  Thanks for the pointer.

Comment 4 Fred van Zwieten 2014-11-11 12:18:53 UTC
What is f20-rawhide? Will that end up in F21 gold?

Comment 5 Josh Boyer 2014-11-11 13:25:29 UTC
(In reply to Fred van Zwieten from comment #4)
> What is f20-rawhide? Will that end up in F21 gold?

The f20 through rawhide releases, which includes F21.

If you'd like to help us out and confirm the fix, please download the kernel, kernel-core, and kernel-modules packages for your architecture from here:

http://koji.fedoraproject.org/koji/buildinfo?buildID=592006

install them and try the new kernel out.

Comment 6 Fedora Update System 2014-11-15 15:03:35 UTC
kernel-3.17.3-300.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/kernel-3.17.3-300.fc21

Comment 7 Fedora Update System 2014-11-15 16:44:40 UTC
kernel-3.17.3-200.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/kernel-3.17.3-200.fc20

Comment 8 Fedora Update System 2014-11-16 14:39:58 UTC
Package kernel-3.17.3-300.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.17.3-300.fc21'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-15159/kernel-3.17.3-300.fc21
then log in and leave karma (feedback).

Comment 9 Fedora Update System 2014-11-18 12:17:22 UTC
kernel-3.17.3-300.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 Fred van Zwieten 2014-11-20 05:54:13 UTC
Sorry i am a bit late, but the issue is not resolved. Like I sad in comment 1, the only thing that works for me, with or without this kernel version and with or without the GRUB options mentioned in the links.

AFAICT, it is only this slow when using yum install or yum update with large packages. On L0 (the fedora box itself) I see it during yum update. On L1 (virt-manager) installing a RHEL7 vm from a RHEL7 iso on the same disk, I see it during the installation phase when the packages are actually being installed by anaconda. As soon as I add nobarrier to the affected filesystems in fstab, all is well and really really fast.

To confirm this is only with the SSD, I attached an external USB drive (rotational), mounted it without nobarrier and used it as a vm pool. When doing the same vm install there, it is fast as well.

Comment 11 Fedora Update System 2014-11-20 23:03:52 UTC
kernel-3.17.3-200.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 12 Koen van Bakel 2014-12-10 14:28:22 UTC
I also see this issue on a Macbook Pro 15" mid 2014.
With the latest kernel on Fedora 20 the issue is still there. The nobarrier option works in fstab.

Comment 13 Fred van Zwieten 2014-12-11 10:02:18 UTC
Sorry, but this bug is NOT resolved. Not in F20 and not in F21, So I have reopened it.

Comment 14 Josh Boyer 2014-12-11 14:31:19 UTC
Can you provide the output of lspci -nn please?  There was another model that had the same quirk added yesterday.

Comment 15 Fred van Zwieten 2014-12-13 10:58:12 UTC
00:00.0 Host bridge [0600]: Intel Corporation Haswell-ULT DRAM Controller [8086:0a04] (rev 09)
00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:0a2e] (rev 09)
00:03.0 Audio device [0403]: Intel Corporation Haswell-ULT HD Audio Controller [8086:0a0c] (rev 09)
00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04)
00:16.0 Communication controller [0780]: Intel Corporation 8 Series HECI #0 [8086:9c3a] (rev 04)
00:1b.0 Audio device [0403]: Intel Corporation 8 Series HD Audio Controller [8086:9c20] (rev 04)
00:1c.0 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 1 [8086:9c10] (rev e4)
00:1c.1 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 2 [8086:9c12] (rev e4)
00:1c.2 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 3 [8086:9c14] (rev e4)
00:1c.4 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 5 [8086:9c18] (rev e4)
00:1c.5 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 6 [8086:9c1a] (rev e4)
00:1f.0 ISA bridge [0601]: Intel Corporation 8 Series LPC Controller [8086:9c43] (rev 04)
00:1f.3 SMBus [0c05]: Intel Corporation 8 Series SMBus Controller [8086:9c22] (rev 04)
02:00.0 Multimedia controller [0480]: Broadcom Corporation Device [14e4:1570]
03:00.0 Network controller [0280]: Broadcom Corporation BCM4360 802.11ac Wireless Network Adapter [14e4:43a0] (rev 03)
04:00.0 SATA controller [0106]: Samsung Electronics Co Ltd Apple PCIe SSD [144d:1600] (rev 01)

Comment 16 Justin M. Forbes 2015-01-27 14:59:03 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs.

Fedora 21 has now been rebased to 3.18.3-201.fc21.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

Comment 17 Fedora Kernel Team 2015-02-24 16:13:49 UTC
*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.


Note You need to log in before you can comment on or make changes to this bug.