public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: linux kernel mailing list <linux-kernel@vger.kernel.org>,
	Jens Axboe <axboe@kernel.dk>
Cc: Tao Ma <tm@tao.ma>
Subject: Re: [PATCH] cfq: Fix starvation of async writes in presence of heavy sync workload
Date: Mon, 20 Jun 2011 10:34:11 -0400	[thread overview]
Message-ID: <20110620143411.GB4749@redhat.com> (raw)
In-Reply-To: <20110620141631.GA4749@redhat.com>

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
writes.

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.

Thanks
Vivek

  reply	other threads:[~2011-06-20 14:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-20 14:16 [PATCH] cfq: Fix starvation of async writes in presence of heavy sync workload Vivek Goyal
2011-06-20 14:34 ` Vivek Goyal [this message]
2011-06-20 16:14 ` Justin TerAvest
2011-06-20 16:45   ` Vivek Goyal
2011-06-20 22:16     ` Justin TerAvest
2011-06-20 22:33       ` Vivek Goyal
2011-06-21  2:15 ` Shaohua Li
2011-06-21 15:26   ` Vivek Goyal
2011-06-22  2:07     ` Shaohua Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110620143411.GB4749@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tm@tao.ma \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox