From: Vivek Goyal <vgoyal@redhat.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: Shaohua Li <shaohua.li@intel.com>, Tao Ma <tm@tao.ma>,
linux-kernel@vger.kernel.org
Subject: Re: CFQ: async queue blocks the whole system
Date: Fri, 10 Jun 2011 05:29:22 -0400 [thread overview]
Message-ID: <20110610092922.GE4183@redhat.com> (raw)
In-Reply-To: <4DF1E1EB.8010808@kernel.dk>
On Fri, Jun 10, 2011 at 11:20:43AM +0200, Jens Axboe wrote:
> On 2011-06-10 11:17, Vivek Goyal wrote:
> > On Fri, Jun 10, 2011 at 09:19:12AM +0800, Shaohua Li wrote:
> >
> > [..]
> >>> If there is no major advantage of draining sync requests before async
> >>> is dispatched, I think this should be an easy fix.
> >> I thought this is to avoid sync latency if we switch from an async
> >> queue to sync queue later.
> >
> > Is it about the sync request latency which has already been dispatched? I
> > really wish that driver and disk should do some prioritazation for reads
> > here and CFQ does not have to jump through hoops like drain sync requests
> > before async requests are dispatched.
>
> That would never work. Are you suggesting putting that logic in all
> drivers? Or relying on hardware to get the fairness right? Not going to
> happen.
I was hoping that hardware does some prioritization. Well, in this case
even if hardware maintains FIFO behavior it should be good enough.
But I would not claim anything in this regard as I have never experimented
with it and have no idea that how sync latencies are impacted if we don't
drain the queue before dispathing WRITEs.
I was just wondering that with current generation hardware is it bad
enough that we need to keep this logic around?
Thanks
Vivek
next prev parent reply other threads:[~2011-06-10 9:29 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-09 10:49 CFQ: async queue blocks the whole system Tao Ma
2011-06-09 14:14 ` Vivek Goyal
2011-06-09 14:34 ` Jens Axboe
2011-06-09 14:47 ` Tao Ma
2011-06-09 15:37 ` Vivek Goyal
2011-06-09 15:44 ` Tao Ma
2011-06-09 18:27 ` Vivek Goyal
2011-06-10 5:48 ` Tao Ma
2011-06-10 9:14 ` Vivek Goyal
2011-06-10 10:00 ` Tao Ma
2011-06-10 15:44 ` Vivek Goyal
2011-06-11 7:24 ` Tao Ma
2011-06-13 10:08 ` Tao Ma
2011-06-13 21:41 ` Vivek Goyal
2011-06-14 7:03 ` Tao Ma
2011-06-14 13:30 ` Vivek Goyal
2011-06-14 15:42 ` Tao Ma
2011-06-14 21:14 ` Vivek Goyal
2011-06-17 3:04 ` Tao Ma
2011-06-17 12:50 ` Vivek Goyal
2011-06-17 14:34 ` Tao Ma
2011-06-10 1:19 ` Shaohua Li
2011-06-10 1:34 ` Shaohua Li
2011-06-10 2:06 ` Tao Ma
2011-06-10 2:35 ` Shaohua Li
2011-06-10 3:02 ` Tao Ma
2011-06-10 9:20 ` Vivek Goyal
2011-06-10 9:21 ` Jens Axboe
2011-06-13 1:03 ` Shaohua Li
2011-06-10 9:17 ` Vivek Goyal
2011-06-10 9:20 ` Jens Axboe
2011-06-10 9:29 ` Vivek Goyal [this message]
2011-06-10 9:31 ` Jens Axboe
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=20110610092922.GE4183@redhat.com \
--to=vgoyal@redhat.com \
--cc=axboe@kernel.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=shaohua.li@intel.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.