It's not just USB access---it's anything that hits a filesystem hard. I can confirm that 2.6.38-7-generic on AMD64 freaks out exactly the same way: kswapd0 goes to 100% if driven by 'nc -l 1234 | tar xvfp -' to ext4 (no crypto, no LVM, no RAID, just an ordinary partition) on an ordinary SATA 2TB disk when the other end sends large files via gigabit. This ruins throughput by 2x and drives the CPU fan to max on my 6-core 2.8GHz AMD64. I haven't yet tried 2.6.38-8 because I'm doing my testing with a daily build from 3/30 via a LiveUSB and I've learned the hard way that doing update-manager on a persistent LiveUSB leads to a broken system. The current daily build of 4/5 still only has 2.6.38-7, according to the manifest. (When can we expect 2.6.38-8 in the daily build? Tomorrow? I'm looking at http://cdimage.ubuntu.com/daily-live/current/)
If I direct the nc into /dev/null instead of tar, kswapd0 stays dormant, of course. I am now in the extremely unpalatable situation of having -terrible- (6x) slowdowns on small-file access if they're on top of LUKS in Maverick AMD64 (see bug #731340) or -terrible- large-file performance in Natty while trying to build a new server and migrate a 2TB dirvish vault with many of each from 8.10 or thereabouts, where all this worked just fine. This seems like a showstopper; neither one will work half as well as one from over 2 years ago on this simple task. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/747707 Title: kswapd0 freaks out if rsync runs on an USB disk -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs