Comment 6 for bug 747707

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.