On Saturday 17 December 2011 21:17:19 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. I wouldn't know when exactly was this kind of vmm behavior first introduced (in kernel-version-time), but it appears that the problem was discovered only about a month ago, and that there is still no proper fix for this. IMHO, it's still too fresh, but eventually a fix will come in one of the future kernels. :-) What I would like best is to have a kernel "knob" somewhere under /proc, which would enable/disable Mel Gorman's patch, so that both desktop users and cluster farms could tune the vmm behavior to their needs. Also, I haven't been following the discussions on the LKML, but AFAIK there is no consensus yet on how to disentangle this mess. We Linux users usually make fun of Windows users for having to defragment their hard drives every now and then, while our ext2/3/4 solution is sooo far superior. But when RAM gets fragmented due to the big uptimes (which is also something we like to bragg about among Windows users), then all sorts of sh*t starts to happen... The moral of the story: optimization of virtual memory management systems is a bloody hell, especially if you insist on a one-size-fits-all solution (which is the part that always seems to not make any sense IMHO). Best, :-) Marko -- 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
