From: Jens Axboe <axboe@suse.de>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] SFQ disk scheduler
Date: Mon, 10 Feb 2003 16:22:26 +0100 [thread overview]
Message-ID: <20030210152226.GV12828@suse.de> (raw)
In-Reply-To: <20030210151144.GT31401@dualathlon.random>
On Mon, Feb 10 2003, Andrea Arcangeli wrote:
> On Mon, Feb 10, 2003 at 03:50:01PM +0100, Jens Axboe wrote:
> > Hi,
> >
> > Here's a simple stochastic fairness queueing disk scheduler, for current
> > 2.5.59-BK. It has known limitations right now, mainly because I didn't
> > bother making it complete. But it should suffice for some rudimentary
> > testing, at least.
>
> Cool, that was fast! ;)
It's pretty easy to do in 2.5 :-). A 2.4 backport is of course feasible,
but requires a bit more work (and possibly abstracting some of the
elevator stuff there).
> > I'm not going to go into great detail about how it works, see Andrea's
> > initial post of the paper referenced. This version may not be completely
> > true to the SFQ concept, but should be close enough I think. It divides
> > traffic into a fixed number of buckets (64 per default), and perturbs
> > the hash every 5 seconds (hash shamelessly borrowed from networking atm,
> > see comment).
>
> I tend to think 5 seconds is too small, 30 sec would be better IMHO (it
> should be tested at bit).
It probably is too small, testing will show. I don't see too many
collisions from a dbench 32 or 64, so...
> > To avoid too many disk seeks, when it's time to dispatch requests to the
> > driver, we round robin all non-empty buckets and grab a single request
> > from each. These requests are sorted into the dispatch queue.
> >
> > For performance reasons, io scheduler request merging is still a
> > per-queue function (and not per-bucket).
>
> Unsure if it worth, but it probably it won't make that much difference,
> likely different workloads are working on different part of the disk
> anyways.
The rate of unrelated merging is typically quite low, so no it probably
doesn't provide much of a performance benefit. However, it also keeps
the code simpler to simply have a single merge hash per queue.
> > In closing, let me stress that this version has not really been tested
> > all that much. It passes simple SCSI and IDE testing, should work on any
> > hardware basically.
>
> How does it feel?
I don't know yet, haven't booted it on my work station yet. Will do so
soon :)
--
Jens Axboe
next prev parent reply other threads:[~2003-02-10 15:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-10 14:50 [PATCH] SFQ disk scheduler Jens Axboe
2003-02-10 15:11 ` Andrea Arcangeli
2003-02-10 15:22 ` Jens Axboe [this message]
2003-02-11 9:06 ` CFQ disk scheduler (was Re: [PATCH] SFQ disk scheduler) Jens Axboe
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=20030210152226.GV12828@suse.de \
--to=axboe@suse.de \
--cc=andrea@suse.de \
--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 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.