From: Vivek Goyal <vgoyal@redhat.com>
To: Shaohua Li <shaohua.li@intel.com>
Cc: Gui Jianfeng <guijianfeng@cn.fujitsu.com>,
Corrado Zoccolo <czoccolo@gmail.com>,
"jens.axboe@oracle.com" <jens.axboe@oracle.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jmoyer@redhat.com" <jmoyer@redhat.com>,
"yanmin_zhang@linux.intel.com" <yanmin_zhang@linux.intel.com>
Subject: Re: [PATCH]cfq-iosched: don't stop async queue with async requests pending
Date: Thu, 14 Jan 2010 06:09:02 -0500 [thread overview]
Message-ID: <20100114110902.GA15559@redhat.com> (raw)
In-Reply-To: <20100114061731.GA23590@sli10-desk.sh.intel.com>
On Thu, Jan 14, 2010 at 02:17:31PM +0800, Shaohua Li wrote:
> On Thu, Jan 14, 2010 at 01:27:21PM +0800, Gui Jianfeng wrote:
> > Shaohua Li wrote:
> > > On Wed, Jan 13, 2010 at 07:13:41PM +0800, Vivek Goyal wrote:
> > >> On Wed, Jan 13, 2010 at 04:23:22PM +0800, Shaohua Li wrote:
> > >>> On Wed, Jan 13, 2010 at 04:18:47PM +0800, Corrado Zoccolo wrote:
> > >>>> On Wed, Jan 13, 2010 at 8:44 AM, Shaohua Li <shaohua.li@intel.com> wrote:
> > >>>>> My SSD speed of direct write is about 80m/s, while I test page writeback,
> > >>>>> the speed can only go to 68m/s. Below patch fixes this.
> > >>>>> It appears we missused cfq_should_idle in cfq_may_dispatch. cfq_should_idle
> > >>>>> means a queue should idle because it's seekless sync queue or it's the last queue,
> > >>>>> which is to maintain service tree time slice. So it doesn't mean the
> > >>>>> last queue is always a sync queue. If the last queue is asyn queue,
> > >>>>> we definitely shouldn't stop dispatch requests because of pending async
> > >>>>> requests.
> > >>>> An other option is that cfq_should_idle returns false for async
> > >>>> queues, since cfq will never idle on them.
> > >>> I'm considering this option too, but it appears we need make async queue
> > >>> idle to maintain domain time slice.
> > >> IMHO, we don't have to wait on async write service tree. Generally aysnc
> > >> write queus contain many requests and they are not like reads where next
> > >> request is expected. So idling on aysnc write service tree is waste of
> > >> time and will lead to reduced throughput.
> > > I fully agree async queue doesn't need wait. I thought the purpose we add the last
> > > queue check in cfq_should_idle is we want a service tree or a group has dedicated
> > > slice, because before the service tree/group slice is expired, new queue can jump
> > > in and if we don't idle, the new queue can only run at next slice. Not sure if I
> > > understand the code correctly.
> >
> > Hi Shaohua,
> >
> > If a cfq queue is the last one in the io group, if we expire this cfqq immediately,
> > io group will be removed from service tree. When io group gets backlogged again, it
> > will be put at the end of service tree, so it loses its previous share. so we add
> > the last check here from the fairness point of view.
> ya, this is what I'm understanding. So we can't return false for async queue
> in cfq_should_idle if the queue is the last one of service tree.
>
Yes cfq_should_idle() can check for async queue and return false.
Regarding group loosing fair share, currently all async queues are in root
group and not in individual groups, so this particular change should not
affect a lot. We will continue to idle on sync-idle and sync-noidle
service tree. Only async service tree is the exception.
Once we introduce per group async queue in future, we shall have to come
up with something else, if need be.
So keep this as a separate patch. I think in the presence of mixed
workload, (readers and buffered writers), it might give little performance
boost. We need to test it though.
Thanks
Vivek
next prev parent reply other threads:[~2010-01-14 11:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-13 7:44 [PATCH]cfq-iosched: don't stop async queue with async requests pending Shaohua Li
2010-01-13 8:18 ` Corrado Zoccolo
2010-01-13 8:23 ` Shaohua Li
2010-01-13 11:13 ` Vivek Goyal
2010-01-14 3:41 ` Shaohua Li
2010-01-14 5:27 ` Gui Jianfeng
2010-01-14 6:17 ` Shaohua Li
2010-01-14 8:21 ` Gui Jianfeng
2010-01-14 9:04 ` Shaohua Li
2010-01-14 11:09 ` Vivek Goyal [this message]
2010-01-19 0:52 ` Li, Shaohua
2010-01-19 22:33 ` Vivek Goyal
2010-01-13 11:10 ` Vivek Goyal
2010-01-13 21:30 ` Corrado Zoccolo
2010-01-13 22:26 ` Vivek Goyal
2010-01-14 2:46 ` Gui Jianfeng
2010-01-14 3:43 ` 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=20100114110902.GA15559@redhat.com \
--to=vgoyal@redhat.com \
--cc=czoccolo@gmail.com \
--cc=guijianfeng@cn.fujitsu.com \
--cc=jens.axboe@oracle.com \
--cc=jmoyer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=shaohua.li@intel.com \
--cc=yanmin_zhang@linux.intel.com \
/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