When I use dd if=<some_iso_file> of=<device_of_usb_key> The system becomes very unresponsive. X is almost completely unusable, maybe you can move a mouse for some time but click do nothing. Even togling the Caps Lock doesn't do anything. Trying to SSH is also almost impossible during this. System is like this all the time while using the dd command. After it finishes system again becomes responsive. I've noticed this on two of my computers: 1: AMD Athlon 64 3000+, 2 GB of memory, kernel 2.6.38.2 2: AMD Athlon II P320 Dual-Core, 4 GB of memory, kernel 2.6.39-rc2 The USB key is this one: http://www.takems.com/products.php?categ=usb&prod=MEM-Drive_Easy_II What I expected was that the doing dd wouldn't have a noticable impact on responsivness of the rest of the system.
Created attachment 55962 [details] dmesg2
Created attachment 55972 [details] lspci2
Created attachment 55982 [details] config2
This has been somewhat addressed in later kernels
Alas, I'm seeing this behaviour on a 3.16 kernel (although, it's a distribution kernel from Debian testing). $ uname -a Linux SPR-T500 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt2-1 (2014-12-08) x86_64 GNU/Linux Running `echo never > /sys/kernel/mm/transparent_hugepage/defrag`, seems to make the general responsiveness problem go away, while running `sysctl vm.dirty_background_ratio=1 vm.dirty_ratio=2` seems to help reduce the slowdown for individual processes that try to fsync. I confirmed that reverting these changes causes the problem to come back. Should I open a new bug, or should this one be reopened?