From: Jens Axboe <axboe@suse.de>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: linux-kernel@vger.kernel.org, "Chen,
Kenneth W" <kenneth.w.chen@intel.com>
Subject: Re: [PATCH] Consolidate the request merging
Date: Tue, 11 Jul 2006 19:36:05 +0200 [thread overview]
Message-ID: <20060711173604.GA4120@suse.de> (raw)
In-Reply-To: <44B379F6.4070309@yahoo.com.au>
On Tue, Jul 11 2006, Nick Piggin wrote:
> Jens Axboe wrote:
> >Hi,
> >
> >Right now, every IO scheduler implements its own backmerging (except for
> >noop, which does no merging). That results in duplicated code for
> >essentially the same operation, which is never a good thing. This patch
> >moves the backmerging out of the io schedulers and into the elevator
> >core. We save 1.6kb of text and as a bonus get backmerging for noop as
> >well. Win-win!
> >
> >Notes:
> >
> >- I dropped the "move hot entries to front" logic. It's never been
> > proven good, and some research indicates that it's a bad idea. I doubt
> > it matters in real life, so lets just cut that away.
> >
> >- Next it might be a good idea to move the rb sorting into the elevator
> > core as well. We could save some more kernel text, but more
> > importantly it gets us one step closer to dropping deadline_rq from
> > the deadline scheduler.
>
> Seems like a good idea. I don't think this could be a downside for anyone
> except maybe Ken Chen, if it adds any overhead to the noop scheduler.
>
> BTW, IMO it is a good idea for the noop scheduler to do as much merging as
> possible, especially as it could be used for things like network block
> devices (but more merging may actually cut down on CPU and IO bandwidth
> even in the local disk case).
I agree, I actually think it's a win for noop with the cheap merging. If
anyone complains, we can always make it tweakable with a sysfs
parameter. Even for "intelligent" hardware, you have a command overhead
per request, so it makes a lot of sense to always do merging.
--
Jens Axboe
prev parent reply other threads:[~2006-07-11 17:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-11 9:08 [PATCH] Consolidate the request merging Jens Axboe
2006-07-11 10:14 ` Nick Piggin
2006-07-11 17:36 ` 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=20060711173604.GA4120@suse.de \
--to=axboe@suse.de \
--cc=kenneth.w.chen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
/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