Re: [PATCH] cfq: Fix starvation of async writes in presence of heavysync workload

From: Vivek Goyal
Date: Mon Jun 20 2011 - 10:34:22 EST

On Mon, Jun 20, 2011 at 10:16:31AM -0400, Vivek Goyal wrote:
> In presence of heavy sync workload CFQ can starve asnc writes.
> If one launches multiple readers (say 16), then one can notice
> that CFQ can withhold dispatch of WRITEs for a very long time say
> 200 or 300 seconds.
> Basically CFQ schedules an async queue but does not dispatch any
> writes because it is waiting for exisintng sync requests in queue to
> finish. While it is waiting, one or other reader gets queued up and
> preempts the async queue. So we did schedule the async queue but never
> dispatched anything from it. This can repeat for long time hence
> practically starving Writers.
> This patch allows async queue to dispatch atleast 1 requeust once
> it gets scheduled and denies preemption if async queue has been
> waiting for sync requests to drain and has not been able to dispatch
> a request yet.
> One concern with this fix is that how does it impact readers
> in presence of heavy writting going on.
> I did a test where I launch firefox, load a website and close
> firefox and measure the time. I ran the test 3 times and took
> average.
> - Vanilla kernel time ~= 1 minute 40 seconds
> - Patched kenrel time ~= 1 minute 35 seconds

Forgot to mention that this was in the presence of a dd doing

dd if=/dev/zero of=zerofile bs=4K count=1M

Launching firefox takes around 25 seconds or so. Loading first
website takes a long time. I had a quick look at blktrace
and it I see for long time no reads are queued at all. Looks
like firefox has some dependency on some write to finish
before next read can be issued.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at