Bug 753486 - Large I/O to slow USBMS device blocks up entire I/O subsystem
Summary: Large I/O to slow USBMS device blocks up entire I/O subsystem
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 16
Hardware: Unspecified
OS: Unspecified
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-11-12 22:01 UTC by James
Modified: 2012-08-27 12:51 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-27 12:51:03 UTC
Type: ---


Attachments (Terms of Use)
2.6.41.1-3.fc15.x86_64 latencytop screenshot 1 (108.29 KB, image/png)
2011-11-20 21:38 UTC, James
no flags Details
2.6.41.1-3.fc15.x86_64 latencytop screenshot 2 (108.49 KB, image/png)
2011-11-20 21:39 UTC, James
no flags Details

Description James 2011-11-12 22:01:00 UTC
Description of problem:
Transferring a large amount of data (e.g. copying music library, or live USB image) to a slow (< 3 MB/s or so) USBMS device (typically formatted vfat) ends up slowing down the entire system, blocking I/O on other, much faster devices (such as USB- or SATA-attached discs), and producing O(minute) latencies in other processes. This renders the desktop effectively unusable until the slow I/O process completes.

Version-Release number of selected component (if applicable):
kernel-2.6.40.8-4.fc15.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Find a slow (< around 3 MB/s) USBMS device, formatted vfat.
2. Run liveusb-creator and turn it into a Fedora 16 live stick.
3. Watch as Firefox becomes unresponsive, and launching new programs takes ages.
  
Actual results:
Latency goes through the roof:

 - Firefox just stops responding.
 - Launching a new program takes much longer than is acceptable, for instance
   taking minutes instead of seconds under other circumstances (or I/O load
   to much faster devices).
 - Processes that are doing it all in memory seem unaffected (until they
   try to access a disc).

Expected results:
That a single process using a slow USBMS device is not able to hose the entire system to the extent observed, where faster, independent discs are left waiting for writes to complete to a much slower device.

Comment 1 Dave Jones 2011-11-14 18:40:20 UTC
This is still being investigated upstream.
Thread starts here: https://lkml.org/lkml/2011/11/7/2

Comment 2 James 2011-11-14 21:36:50 UTC
(In reply to comment #1)
> This is still being investigated upstream.
> Thread starts here: https://lkml.org/lkml/2011/11/7/2

Thanks for the pointers --- I'll see if running with transparent hugepages disabled helps.

Comment 3 Dave Jones 2011-11-17 21:31:15 UTC
There's a scratch build here that has a patch that may help.
http://koji.fedoraproject.org/koji/taskinfo?taskID=3522260

Comment 4 James 2011-11-20 21:36:06 UTC
(In reply to comment #3)
> There's a scratch build here that has a patch that may help.
> http://koji.fedoraproject.org/koji/taskinfo?taskID=3522260

Can still reproduce this with 2.6.41.1-3.fc15.x86_64 --- screenshots of latencytop attached below.

Comment 5 James 2011-11-20 21:38:42 UTC
Created attachment 534686 [details]
2.6.41.1-3.fc15.x86_64 latencytop screenshot 1

Comment 6 James 2011-11-20 21:39:03 UTC
Created attachment 534687 [details]
2.6.41.1-3.fc15.x86_64 latencytop screenshot 2

Comment 7 James 2011-12-11 12:13:19 UTC
I still see this on 2.6.41.4-1.fc15.x86_64 (.e.g. while making a liveusb) even with transparent_hugepage=never on the cmdline.

Comment 8 Eric Blake 2012-02-27 21:43:07 UTC
I hit this again today, with kernel-3.2.7-1.fc16.x86_64

Comment 9 Josh Boyer 2012-06-07 15:11:13 UTC
Is anyone still seeing this with the 3.3 kernel?

Comment 10 James 2012-08-26 16:54:27 UTC
Sorry for the huge delay in response. Haven't seen this in kernel 3.5.2 in F17.

Comment 11 Josh Boyer 2012-08-27 12:51:03 UTC
Thanks.


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