From: Jens Axboe <jaxboe@fusionio.com>
To: Shaohua Li <shaohua.li@intel.com>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: [patch]block: avoid building too big plug list
Date: Fri, 8 Jul 2011 08:17:14 +0200 [thread overview]
Message-ID: <4E16A0EA.1030703@fusionio.com> (raw)
In-Reply-To: <1310090367.15392.263.camel@sli10-conroe>
On 2011-07-08 03:59, Shaohua Li wrote:
> When I test fio script with big I/O depth, I found the total throughput drops
> compared to some relative small I/O depth. The reason is the thread accumulates
> big requests in its plug list and causes some delays (surely this depends
> on CPU speed).
> I thought we'd better have a threshold for requests. When a threshold reaches,
> this means there is no request merge and queue lock contention isn't severe
> when pushing per-task requests to queue, so the main advantages of blk plug
> don't exist. We can force a plug list flush in this case.
> With this, my test throughput actually increases and almost equals to small
> I/O depth. Another side effect is irq off time decreases in blk_flush_plug_list()
> for big I/O depth.
> The BLK_MAX_REQUEST_COUNT is choosen arbitarily, but 16 is efficiently to
> reduce lock contention to me. But I'm open here, 32 is ok in my test too.
Thanks, I have wondered whether that would potentially cause an issue.
So this patch is quite fine with me, generally a good idea to cap it.
I'll queue it up with 16 for the max depth, that's still quite a decent
proportion of local to queued requests.
Thanks!
--
Jens Axboe
prev parent reply other threads:[~2011-07-08 6:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-08 1:59 [patch]block: avoid building too big plug list Shaohua Li
2011-07-08 6:17 ` Jens Axboe [this message]
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=4E16A0EA.1030703@fusionio.com \
--to=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.