From: Vivek Goyal <vgoyal@redhat.com>
To: Shaohua Li <shaohua.li@intel.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
Jens Axboe <jaxboe@fusionio.com>,
czoccolo@gmail.com
Subject: Re: [patch 3/3]cfq-iosched: don't idle if a deep seek queue is slow
Date: Mon, 8 Nov 2010 09:20:54 -0500 [thread overview]
Message-ID: <20101108142054.GB16767@redhat.com> (raw)
In-Reply-To: <1289182045.23014.191.camel@sli10-conroe>
On Mon, Nov 08, 2010 at 10:07:25AM +0800, Shaohua Li wrote:
> If a deep seek queue slowly deliver requests but disk is much faster, idle
> for the queue just wastes disk throughput. If the queue delevers all requests
> before half its slice is used, the patch disable idle for it.
> In my test, application delivers 32 requests one time, the disk can accept
> 128 requests at maxium and disk is fast. without the patch, the throughput
> is just around 30m/s, while with it, the speed is about 80m/s. The disk is
> a SSD, but is detected as a rotational disk. I can configure it as SSD, but
> I thought the deep seek queue logic should be fixed too, for example,
> considering a fast raid.
>
Hi Shaohua,
So looks like you are trying to cut down queue idling in the case when
device is fast and idling hurts. That's a noble goal, just that detetction
of this condition only for deep queues does not seem to cover lots of
cases. Manually one can set slice_idle=0 to handle this situation.
What about if you have lots of sequential queues (not deep) and they all
will still idle.
Secondly, what if driver is just buffering lots of requests in its device
queue and not necessarily device is processing the reuqests faster.
So I think it is a good idea to cut down on idling if we can find that
underlying device is fast and idling on queue might hurt more. But
discovering this only using deep queues does not sound very appleaing to
me. This is help only a particular workload which is driving deep queues.
So if there was a generic mechanism to tackle this, that would be much
better.
Vivek
> Signed-off-by: Shaohua Li <shaohua.li@intel.com>
>
> ---
> block/cfq-iosched.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> Index: linux/block/cfq-iosched.c
> ===================================================================
> --- linux.orig/block/cfq-iosched.c 2010-11-08 08:43:51.000000000 +0800
> +++ linux/block/cfq-iosched.c 2010-11-08 08:49:52.000000000 +0800
> @@ -2293,6 +2293,17 @@ static struct cfq_queue *cfq_select_queu
> goto keep_queue;
> }
>
> + /*
> + * This is a deep seek queue, but the device is much faster than
> + * the queue can deliver, don't idle
> + **/
> + if (CFQQ_SEEKY(cfqq) && cfq_cfqq_idle_window(cfqq) &&
> + (cfq_cfqq_slice_new(cfqq) ||
> + (cfqq->slice_end - jiffies > jiffies - cfqq->slice_start))) {
> + cfq_clear_cfqq_deep(cfqq);
> + cfq_clear_cfqq_idle_window(cfqq);
> + }
> +
> if (cfqq->dispatched && cfq_should_idle(cfqd, cfqq)) {
> cfqq = NULL;
> goto keep_queue;
>
next prev parent reply other threads:[~2010-11-08 14:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-08 2:07 [patch 3/3]cfq-iosched: don't idle if a deep seek queue is slow Shaohua Li
2010-11-08 14:20 ` Vivek Goyal [this message]
2010-11-08 15:06 ` Jens Axboe
2010-11-09 1:36 ` Shaohua Li
2010-11-09 2:28 ` Vivek Goyal
2010-11-09 2:31 ` 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=20101108142054.GB16767@redhat.com \
--to=vgoyal@redhat.com \
--cc=czoccolo@gmail.com \
--cc=jaxboe@fusionio.com \
--cc=linux-kernel@vger.kernel.org \
--cc=shaohua.li@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