Same goes for I/O scheduling. The virtual memory subsystem seems to only have two modes: buffering and write-out. The system will buffer writes until some threshold is reached, then it switches to write-out mode and flushes all dirty pages regardless of their age. The problem is that new pages are locked during write-out, so pending writes will stall, regardless of the memory pressure on the rest of the system.

A better design would be to only lock a subset of dirty pages and let new writes to virtual memory continue while the write-out is happening, but it doesn't seem like the system can accomodate that.

A simple test to see this in action is to use netcat to transfer a large file across the network, and monitor the device activity with sar or atop (or just check the disk/network activity lights). What you'll see is that while the disk is writing, network activity drops to zero, and when network activity resumes, the disk remains idle again for seconds. It doesn't matter how much smaller you make vm.dirty_background_{bytes,ratio} with respect to vm.dirty_{bytes,ratio}, the network traffic will block as soon as the "background" disk write starts. The only effect a low value for vm.dirty_background_{bytes,ratio} has is to increase the frequency at which the network and disk activity will alternate.