From: Andi Kleen <andi@firstfloor.org>
To: "Alan D. Brunelle" <Alan.Brunelle@hp.com>
Cc: linux-kernel@vger.kernel.org, Jens Axboe <jens.axboe@oracle.com>
Subject: Re: [RFC][PATCH 0/3] Skip I/O merges when disabled
Date: Thu, 24 Apr 2008 15:29:05 +0200 [thread overview]
Message-ID: <87ve27gz4u.fsf@basil.nowhere.org> (raw)
In-Reply-To: <480F8936.5030406@hp.com> (Alan D. Brunelle's message of "Wed, 23 Apr 2008 15:08:38 -0400")
"Alan D. Brunelle" <Alan.Brunelle@hp.com> writes:
> The block I/O + elevator + I/O scheduler code spends a lot of time
> trying to merge I/Os -- rightfully so under "normal" circumstances.
> However, if one were to know that the incoming I/O stream was /very/
> random in nature, the cycles are wasted. (This can be the case, for
> example, during OLTP-type runs.)
>
> This patch stream adds a per-request_queue tunable that (when set)
> disables merge attempts, thus freeing up a non-trivial amount of CPU cycles.
It sounds interesting. But explicit tunables are always bad because
they will be only used by a elite few. Do you think it would be
possible instead to keep some statistics on how successfull merging is and
when the success rate is very low disable it automatically for some
time until a time out?
This way nearly everybody could get most of the benefit from this
change.
-Andi
next prev parent reply other threads:[~2008-04-24 13:30 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-23 19:08 [RFC][PATCH 0/3] Skip I/O merges when disabled Alan D. Brunelle
2008-04-23 19:12 ` [RFC][PATCH 1/3] Add flag and sysfs interfaces Alan D. Brunelle
2008-04-23 19:14 ` [RFC][PATCH 2/3] Have __make_request skip merges when disabled Alan D. Brunelle
2008-04-23 19:15 ` [RFC][PATCH 3/3] Do not use rqhash when merges disabled Alan D. Brunelle
2008-04-24 0:37 ` Aaron Carroll
2008-04-24 0:59 ` Alan D. Brunelle
2008-04-24 2:07 ` Aaron Carroll
2008-04-24 7:09 ` [RFC][PATCH 0/3] Skip I/O merges when disabled Jens Axboe
2008-04-24 12:09 ` Alan D. Brunelle
2008-04-25 8:38 ` Jens Axboe
2008-04-25 11:17 ` Alan D. Brunelle
2008-04-25 11:25 ` Jens Axboe
2008-04-25 12:06 ` Aaron Carroll
2008-04-25 12:14 ` Jens Axboe
2008-04-25 12:17 ` Alan D. Brunelle
2008-04-28 16:36 ` Alan D. Brunelle
2008-04-29 7:37 ` Jens Axboe
2008-04-24 20:38 ` Alan D. Brunelle
2008-04-24 13:29 ` Andi Kleen [this message]
2008-04-24 13:59 ` Jens Axboe
2008-04-24 14:13 ` Alan D. Brunelle
2008-04-24 15:05 ` Jens Axboe
2008-04-24 22:04 ` Carl Henrik Lunde
2008-04-25 7:13 ` Andi Kleen
2008-04-24 14:15 ` Andi Kleen
2008-04-24 15:04 ` Jens Axboe
2008-04-24 15:53 ` David Collier-Brown
2008-04-24 16:29 ` Alan D. Brunelle
2008-04-24 13:31 ` Alan D. Brunelle
2008-04-24 13:43 ` Alan D. Brunelle
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=87ve27gz4u.fsf@basil.nowhere.org \
--to=andi@firstfloor.org \
--cc=Alan.Brunelle@hp.com \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
/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