Bug 698841 - IO performance is remarkably lower
Summary: IO performance is remarkably lower
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 15
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-21 23:39 UTC by Wyatt Gosling
Modified: 2012-06-04 18:50 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-04 18:50:08 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
dmesg output (54.53 KB, text/plain)
2011-04-24 04:29 UTC, Wyatt Gosling
no flags Details

Description Wyatt Gosling 2011-04-21 23:39:35 UTC
Description of problem:
I just did a fresh install of the Fedora 15 KDE Beta, and disk IO performance is severely reduced compared to Fedora 14. Applications that report transfer-rate are reporting speeds of 1/1000th of what Fedora 14 was able to achieve.

Copying a file reports a transfer-rate of 5-10 KiB/s, compared to ~2MiB/s in Fedora 14. Launching applications takes 2-3 minutes (the first time, additional times are 'instant'). The first Gtk application launched will increase that about 3x, due to having to load all the Gtk libraries. The SELinux Troubleshooting tool takes about 10 minutes to load. This also means that the First Boot Wizard also takes several minutes to load (leaving a black screen with no indication of anything occurring).

Additionally, X can take so long to begin accepting connections that the desktop gives up waiting for it.


Version-Release number of selected component (if applicable):


How reproducible:
Every time, even after reinstalling.


Steps to Reproduce:
Any of the following.
1. Copy a file, preferably one that is at least 10s of MiB.
2. Notice the reported transfer rate in the relevant dialog.
3. Repeat test in Fedora 14.
4. Notice the transfer rate is significantly lower in F15.

1. Run yum upgrade
2. Wait for it to build delta-rpms
3. Notice the reported throughput.
4. Repeat test in F14.
5. Notice the rate is significantly lower.

1. Reboot and login.
2. Launch an application.
3. Note the launch time.
4. Close the app.
5. Relaunch the app.
6. Notice the launch time is about instant (as it should be in memory).
7. Repeat with F14.
8. Notice the launch time is significantly longer in F15.
9. Repeat with an application using a different toolkit (loading the toolkit will exacerbate the problem).

1. Load a music collection in a music player.
2. Notice the time it takes to analyze the collection.
3. Repeat with F14.
4. Notice the music player takes significantly longer one F15.

Additional info:
* Performance of the Live-USB does not seem affected.
* I used the same partition to perform the tests to try to remove the effect of disk corruption in one particular area.

* Computer Info: 2GHz processor, 3GiB of RAM, ATI 6850, 500GiB hard drive.

Comment 1 Chuck Ebbert 2011-04-23 06:48:42 UTC
Yours is the only report of any problem like this.

Can you run some minimal tests and then upload the output of the "dmesg" command (as a plain-text attachment)?

Comment 2 Wyatt Gosling 2011-04-24 04:29:47 UTC
Created attachment 494487 [details]
dmesg output

Comment 3 Chuck Ebbert 2011-04-25 01:56:10 UTC
Interrupt 19 is getting disabled 14 seconds after boot:

[   14.186682] irq 19: nobody cared (try booting with the "irqpoll" option)
[   14.186692] Pid: 0, comm: kworker/0:0 Not tainted 2.6.38.2-9.fc15.x86_64 #1
[   14.186695] Call Trace:
[   14.186698]  <IRQ>  [<ffffffff8146d44e>] ? __report_bad_irq+0x38/0x87
[   14.186717]  [<ffffffff810ade1c>] ? note_interrupt+0x122/0x18e
[   14.186722]  [<ffffffff810ae940>] ? handle_fasteoi_irq+0xab/0xd7
[   14.186728]  [<ffffffff8100c0b5>] ? handle_irq+0x88/0x8e
[   14.186734]  [<ffffffff8147b245>] ? do_IRQ+0x4d/0xa5
[   14.186741]  [<ffffffff81475193>] ? ret_from_intr+0x0/0x15
[   14.186743]  <EOI>  [<ffffffff810b1234>] ? rcu_needs_cpu+0x111/0x1c2
[   14.186754]  [<ffffffff8102a145>] ? native_safe_halt+0xb/0xd
[   14.186759]  [<ffffffff81010d12>] ? default_idle+0x4e/0x86
[   14.186765]  [<ffffffff81008321>] ? cpu_idle+0xa5/0xdf
[   14.186772]  [<ffffffff814641f7>] ? start_secondary+0x20c/0x20e
[   14.186775] handlers:
[   14.186777] [<ffffffff8132740e>] (ahci_interrupt+0x0/0x594)
[   14.186784] [<ffffffff8133de0a>] (usb_hcd_irq+0x0/0x77)

You could try adding "noirqdebug" to the kernel boot options, but this is just a workaround...

Comment 4 Wyatt Gosling 2011-04-25 10:05:59 UTC
Thanks Chuck, the workaround worked handily.


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