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 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.