On Tue, Oct 12 2004, Nick Piggin wrote:
Ronny V. Vindenes wrote:
CFQ v2 is much better in a lot of cases, but certain situations trigger
a cpu load so high it starves the rest of the system thus completely
ruining the interactive experience. While casually looking at the
problem, I stumbled upon a patch by Arjan van de Ven sent to lkml on
sept. 1 (Subject: block fixes). Part of it is already included in the
CFQ v2 patches and after applying the rest[1] I'm no longer able to
trigger the problem.
[1] Patch attached against 2.6.9-rc4-ck1 but applies to rc4-mm1 with
some minor fuzz.
------------------------------------------------------------------------
--- patches/linux-2.6.9-rc4-ck1/drivers/block/ll_rw_blk.c 2004-10-12 12:25:09.798003278 +0200
+++ linux-2.6.9-rc4-ck1/drivers/block/ll_rw_blk.c 2004-10-12 12:25:42.959479479 +0200
@@ -100,7 +100,7 @@
nr = q->nr_requests;
q->nr_congestion_on = nr;
- nr = q->nr_requests - (q->nr_requests / 8) - 1;
+ nr = q->nr_requests - (q->nr_requests / 8) - (q->nr_requests/16)- 1;
if (nr < 1)
nr = 1;
q->nr_congestion_off = nr;
I thought this first hunk looked like a good idea when Arjan sent the
patch. Can you check if it alone helps your problem?
Yeah agree, it's a good idea to leave a bit of air between congestion on
and off. Fully explains the cfq v2 excessive sys time for some
workloads, which is extra nice.
The second hunk should be basically a noop.
I don't see what it is trying to achieve, I like the current code
better.