On Sat, 2011-12-17 at 21:17 -0430, Patrick O'Callaghan wrote: > On Sun, 2011-12-18 at 01:37 +0000, Marko Vojinovic wrote: > > On Saturday 17 December 2011 19:41:38 Patrick O'Callaghan wrote: > > > This looks like a regression. Under F15 when I wrote large files to a > > > pendrive, the system would become a little sluggish. Now it essentially > > > freezes until the write terminates. What I mean is that the UI is almost > > > completely unresponsive; even clicking between two terminal windows is > > > so slow that you can see the window contents refresh, followed several > > > seconds later by the frame. > > > > > > Fully updated F16 with KDE, Intel Core 2 Dual, 4GB RAM, Intel onboard > > > graphics. The pendrive is an 8GB Patriot Xporter (a year or two old) > > > under USB-2 with no intervening hub. > > > > Oh yes, this is one of my favourities... :-D > > > > There's a very good article at LWN discussing precisely this issue: > > > > http://lwn.net/Articles/467328/ > > > > You wouldn't believe how complicated these things can get... ;-) One would > > naively think "yes, the USB drive is slow, but that shouldn't stop the rest of > > the system from running smoothly". However, when you put into the mix the > > hugemem page allocation, memory fragmentation, contradictory points of view on > > how the kernel should be optimized, etc., it seems that it is quite natural > > that your typical fast 3GHz system with 4GB of RAM grinds to a complete halt > > during a simple write-to-USB-drive operation... :-D > > That might be it I guess, but I'm not totally convinced. I updated > F15->F16 only 5 days ago, and previous to the switchover had no problems > of this sort, using the latest kernel for F15. It's hard to believe the > kernel switch from F15 to F16 can have made such a huge difference. For > the record, I went from: > > kernel-2.6.41.1-1.fc15.x86_64 > > to: > > kernel-3.1.5-1.fc16.x86_64 > > But as we know, the version bump from 2 to 3 is meaningless in itself. This was really bothering me (I make frequent use of pendrives) so took another look at the above article, then at /usr/share/doc/kernel-doc-3.1.9/Documentation/vm/transhuge.txt, where it explains how to turn off the Transparent Huge Pages feature. I added transparent_hugepage=never to my boot params, rebooted, and the problem appears to have been fixed. Note: YMMV. This works for me with my workload (no long jobs or intensive compute load). Others may find it impacts their performance, but it shouldn't break anything. poc -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
