From: Nick Piggin <piggin@cyberone.com.au>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Rik van Riel <riel@conectiva.com.br>,
Con Kolivas <ckolivas@yahoo.com.au>,
lkml <linux-kernel@vger.kernel.org>, Jens Axboe <axboe@suse.de>
Subject: Re: stochastic fair queueing in the elevator [Re: [BENCHMARK] 2.4.20-ck3 / aa / rmap with contest]
Date: Mon, 10 Feb 2003 18:39:18 +1100 [thread overview]
Message-ID: <3E475726.5060206@cyberone.com.au> (raw)
In-Reply-To: 20030210071715.GD31401@dualathlon.random
Andrea Arcangeli wrote:
>On Mon, Feb 10, 2003 at 01:42:28AM -0200, Rik van Riel wrote:
>
>>On Sun, 9 Feb 2003, Andrea Arcangeli wrote:
>>
>>
>>>The only way to get the minimal possible latency and maximal fariness is
>>>my new stochastic fair queueing idea.
>>>
>>"The only way" ? That sounds like a lack of fantasy ;))
>>
>
>you can do more but you'd need to build additional APIs, to allow the
>highlevel (possibly userspace too) to give hints to the lowlevel.
>
>This only requires the pid and checking current->mm which is trivial. So
>without adding a complex API I think this is the best/only thing you can
>do to get close to the minimal possible I/O latency from a process point
>of view.
>
>
>>On the contrary, once we have SFQ to fix the biggest elevator
>>problems the difference made by the anticipatory scheduler should
>>be much more visible.
>>
>>Think of a disk with 6 track buffers for reading and a system with
>>10 active reader processes. Without the anticipatory scheduler you'd
>>need to go to the platter for almost every OS read (because each
>>process flushes out the track buffer for the others), while with the
>>anticipatory scheduler you've got a bigger chance of having the data
>>you want in one of the drive's track buffers, meaning that you don't
>>need to go to the platter but can just do a silicon to silicon copy.
>>
>>If you look at the academic papers of an anticipatory scheduler, you'll
>>find that it gives as much as a 73% increase in throughput.
>>On real-world tasks, not even on specially contrived benchmarks.
>>
>>The only aspect of the anticipatory scheduler that is no longer needed
>>with your SFQ idea is the distinction between reads and writes, since
>>your idea already makes the (better, I guess) distinction between
>>synchronous and asynchronous requests.
>>
>
>I'm not saying anticipatory scheduling is going to be obsoleted by SFQ,
>especially because SFQ has to be an option to use only when absolutely
>your only care to get the lowest possible I/O latency from a per-process
>point of view (like while playing an mpeg or mp3).
>
>But I still definitely think that if you run an anticipatory scheduling
>benchmark w/ and w/o SFQ, the effect w/o SFQ (i.e. right now) is going
>to be much more visible than w/ SFQ enabled. The reason is the size of
>the queue that w/o SFQ can be as large as several seconds in time and
>several dozen mbytes in bytes.
>
You are addressing a fundamentally different problem. In the 2.5
elevator we can have whatever queue size we like. I get great
contest results with a 8192 request queue size. We track each
request submission time so we can impose a soft upper limit on
service times which provides fine latency, and the sync nature
of reads ensures pretty good fairness.
What your scheduler is good for obviously is providing a much
stronger per process fairness solution which is obviously very
useful for some tasks.
The problems each are trying to solve are different. I don't
think your idea solves anything that anticipatory scheduling
solves (tries to).
Nick
next prev parent reply other threads:[~2003-02-10 7:29 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-09 13:30 [BENCHMARK] 2.4.20-ck3 / aa / rmap with contest Con Kolivas
2003-02-09 14:46 ` stochastic fair queueing in the elevator [Re: [BENCHMARK] 2.4.20-ck3 / aa / rmap with contest] Andrea Arcangeli
2003-02-10 3:13 ` Nick Piggin
2003-02-10 3:52 ` Rik van Riel
2003-02-10 4:44 ` Nick Piggin
2003-02-10 5:15 ` usbaudio.c 2.5.59 John
2003-02-10 7:26 ` stochastic fair queueing in the elevator [Re: [BENCHMARK] 2.4.20-ck3 / aa / rmap with contest] Andrea Arcangeli
2003-02-10 7:43 ` Nick Piggin
2003-02-10 3:42 ` Rik van Riel
2003-02-10 4:15 ` Rik van Riel
2003-02-10 4:19 ` David Lang
2003-02-10 4:29 ` Rik van Riel
2003-02-10 7:20 ` Andrea Arcangeli
2003-02-10 4:33 ` Andrew Morton
2003-02-10 4:47 ` Rik van Riel
2003-02-10 7:31 ` Andrea Arcangeli
2003-02-10 4:51 ` Jakob Oestergaard
2003-02-10 4:58 ` Nick Piggin
2003-02-10 5:10 ` Jakob Oestergaard
2003-02-10 6:06 ` Valdis.Kletnieks
2003-02-10 6:31 ` Jakob Oestergaard
2003-02-10 7:36 ` Andrea Arcangeli
2003-02-10 7:41 ` Nick Piggin
2003-02-10 8:08 ` Andrea Arcangeli
2003-02-10 8:19 ` Andrew Morton
2003-02-10 8:56 ` Andrea Arcangeli
2003-02-10 9:09 ` Andrew Morton
2003-02-10 9:14 ` Andrea Arcangeli
2003-02-10 10:07 ` Hans Reiser
2003-02-10 10:15 ` Andrea Arcangeli
2003-02-10 10:40 ` Nick Piggin
2003-02-10 11:10 ` Andrea Arcangeli
2003-02-10 11:21 ` Andrew Morton
2003-02-10 11:31 ` Andrea Arcangeli
2003-02-10 11:24 ` Nick Piggin
2003-02-10 11:39 ` Andrea Arcangeli
2003-02-10 11:45 ` Nick Piggin
2003-02-10 12:00 ` Andrea Arcangeli
2003-02-10 12:11 ` Nick Piggin
2003-02-10 12:22 ` Andrea Arcangeli
2003-02-10 12:36 ` Nick Piggin
2003-02-10 12:47 ` Andrea Arcangeli
2003-02-10 13:26 ` Rik van Riel
2003-02-10 11:48 ` Andrew Morton
2003-02-10 11:53 ` Nick Piggin
2003-02-10 12:10 ` Andrea Arcangeli
2003-02-10 12:14 ` Nick Piggin
2003-02-10 12:26 ` Andrea Arcangeli
2003-02-10 12:12 ` Andrew Morton
2003-02-10 12:25 ` Andrea Arcangeli
2003-02-10 12:27 ` Nick Piggin
2003-02-10 12:30 ` Andrea Arcangeli
2003-02-10 12:34 ` Nick Piggin
2003-02-10 12:43 ` Andrea Arcangeli
2003-02-10 12:55 ` Nick Piggin
2003-02-10 13:30 ` Rik van Riel
2003-02-11 19:13 ` Rod Van Meter
2003-02-10 12:09 ` Andrea Arcangeli
2003-02-10 12:17 ` Nick Piggin
2003-02-10 12:28 ` Andrea Arcangeli
2003-02-10 12:58 ` Hans Reiser
2003-02-10 13:18 ` Andrea Arcangeli
2003-02-10 20:14 ` Hans Reiser
2003-02-10 13:19 ` Nick Piggin
2003-02-10 14:49 ` stochastic fair queueing in the elevator [Re: [BENCHMARK] 2 Giuliano Pochini
2003-02-10 15:05 ` Andrea Arcangeli
2003-02-10 11:25 ` stochastic fair queueing in the elevator [Re: [BENCHMARK] 2.4.20-ck3 / aa / rmap with contest] Hans Reiser
2003-02-10 11:42 ` Andrew Morton
2003-02-10 13:00 ` Hans Reiser
2003-02-10 10:48 ` Andrew Morton
2003-02-10 10:55 ` Nick Piggin
2003-02-10 11:21 ` Andrea Arcangeli
2003-02-10 11:33 ` Andrew Morton
2003-02-10 11:43 ` Andrea Arcangeli
2003-02-10 11:39 ` Nick Piggin
2003-02-10 9:59 ` Hans Reiser
2003-02-10 10:06 ` Andrew Morton
2003-02-10 10:17 ` Hans Reiser
2003-02-10 10:39 ` Hans Reiser
2003-02-10 8:27 ` Nick Piggin
2003-02-10 9:02 ` Andrea Arcangeli
2003-02-10 9:18 ` Nick Piggin
2003-02-10 20:33 ` Kurt Garloff
2003-02-10 21:43 ` Rik van Riel
2003-02-10 5:01 ` Andrew Morton
2003-02-10 7:34 ` Andrea Arcangeli
2003-02-10 4:44 ` Rik van Riel
2003-02-10 7:31 ` Andrea Arcangeli
2003-02-10 7:17 ` Andrea Arcangeli
2003-02-10 7:39 ` Nick Piggin [this message]
2003-02-10 10:03 ` stochastic fair queueing in the elevator [Re: [BENCHMARK] 2 Giuliano Pochini
2003-02-10 16:23 ` stochastic fair queueing in the elevator [Re: [BENCHMARK] 2.4.20-ck3 / aa / rmap with contest] Pavel Machek
2003-02-11 11:49 ` Andrea Arcangeli
2003-02-11 12:43 ` Jens Axboe
2003-02-11 14:28 ` Jason Lunz
2003-02-11 14:41 ` Jens Axboe
2003-02-11 17:17 ` Jason Lunz
2003-02-11 20:19 ` Jens Axboe
2003-02-10 16:47 ` Pavel Machek
2003-02-11 11:01 ` 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=3E475726.5060206@cyberone.com.au \
--to=piggin@cyberone.com.au \
--cc=andrea@suse.de \
--cc=axboe@suse.de \
--cc=ckolivas@yahoo.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@conectiva.com.br \
/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;
as well as URLs for NNTP newsgroup(s).