From: Vivek Goyal <vgoyal@redhat.com>
To: Shaohua Li <shaohua.li@intel.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
jaxboe@fusionio.com, czoccolo@gmail.com
Subject: Re: [patch]cfq-iosched: don't idle if a deep seek queue is slow
Date: Mon, 20 Sep 2010 10:15:41 -0400 [thread overview]
Message-ID: <20100920141541.GE6138@redhat.com> (raw)
In-Reply-To: <1284972814.6598.18.camel@sli10-conroe.sh.intel.com>
On Mon, Sep 20, 2010 at 04:53:34PM +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 you seem to be addressing the issue of storage being fast enough and
a single queue not being able to keep the storage busy.
But we have the same issue for non-deep queues for a fast storage. This
patch will not solve that.
I think CFQ idling in general is a problem on faster storage. For SSDs we
can statically detect non-rotational media and disable idling. For faster
RAIDs we need to find an intellligent way of detection and disable idling.
One of the suggestions at this year's LSF was to keep idling on only for
SATA disks and for any SCSI disks we can think of disabling idling by
default. May be with the help of udev rule.
Thanks
Vivek
> Signed-off-by: Shaohua Li <shaohua.li@intel.com>
>
> ---
> block/cfq-iosched.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> Index: linux-2.6/block/cfq-iosched.c
> ===================================================================
> --- linux-2.6.orig/block/cfq-iosched.c 2010-09-19 21:25:11.000000000 +0800
> +++ linux-2.6/block/cfq-iosched.c 2010-09-21 00:20:46.000000000 +0800
> @@ -2275,6 +2275,17 @@
> 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-09-20 14:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-20 8:53 [patch]cfq-iosched: don't idle if a deep seek queue is slow Shaohua Li
2010-09-20 14:15 ` Vivek Goyal [this message]
2010-09-20 23:55 ` 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=20100920141541.GE6138@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 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.