This is almost certainly not the IO scheduler's problem. IO scheduling priorities are orthogonal to CPU scheduling priorities.
What you are likely running into is the dirty_ratio limits. In Linux, there is a memory threshold for "dirty memory" (memory that is destined to be written out to disk), that once crossed, will cause symptoms like you've described. The dirty_ratio values can be tuned via/proc, but beware that the kernel will internally add its own heuristics to the values you've plugged in.
When the threshold is crossed, in an attempt to "slow down the dirtiers", the Linux kernel will penalized (in rate-limited fashion) any and every task on the system that tries to allocate a page.
It will throttle tasks when they try to dirty a page, not allocate a new one. By the time allocators are caught up on dirty pages (during page reclaim), the writeback heuristics has already screwed up.
Also, it does not throttle _every_ dirtier. A task's dirty limit is biased based on its contribution to the total amount of dirty pages in the system, which introduces a phase where heavy dirtiers will get throttled while light ones get away without any holdup.
It's impossible to set a sane kernel-default for these limits. Heck, there are not even good per-system defaults, which is why people are currently trying to make those them self-tuning based on the workload.
We have also seen reports of such interactivity problems for pure read loads, btw. So while the dirty-writeback stuff certainly is not optimal, I am not convinced it is the sole source of the problem described in the TFA.
Slashdot Mirror
This is almost certainly not the IO scheduler's problem. IO scheduling priorities are orthogonal to CPU scheduling priorities.
What you are likely running into is the dirty_ratio limits. In Linux, there is a memory threshold for "dirty memory" (memory that is destined to be written out to disk), that once crossed, will cause symptoms like you've described. The dirty_ratio values can be tuned via /proc, but beware that the kernel will internally add its own heuristics to the values you've plugged in.
When the threshold is crossed, in an attempt to "slow down the dirtiers", the Linux kernel will penalized (in rate-limited fashion) any and every task on the system that tries to allocate a page.
It will throttle tasks when they try to dirty a page, not allocate a new one. By the time allocators are caught up on dirty pages (during page reclaim), the writeback heuristics has already screwed up.
Also, it does not throttle _every_ dirtier. A task's dirty limit is biased based on its contribution to the total amount of dirty pages in the system, which introduces a phase where heavy dirtiers will get throttled while light ones get away without any holdup.
It's impossible to set a sane kernel-default for these limits. Heck, there are not even good per-system defaults, which is why people are currently trying to make those them self-tuning based on the workload.
We have also seen reports of such interactivity problems for pure read loads, btw. So while the dirty-writeback stuff certainly is not optimal, I am not convinced it is the sole source of the problem described in the TFA.