From: Hans Reiser <reiser@namesys.com>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Andrew Morton <akpm@digeo.com>,
piggin@cyberone.com.au, jakob@unthought.net,
david.lang@digitalinsight.com, riel@conectiva.com.br,
ckolivas@yahoo.com.au, linux-kernel@vger.kernel.org,
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 23:14:54 +0300 [thread overview]
Message-ID: <3E48083E.6000901@namesys.com> (raw)
In-Reply-To: <20030210131858.GP31401@dualathlon.random>
Andrea Arcangeli wrote:
>On Mon, Feb 10, 2003 at 03:58:13PM +0300, Hans Reiser wrote:
>
>
>>Is the following a fair summary?
>>
>>There is a certain minimum size required for the IOs to be cost
>>effective. This can be determined by single reader benchmarking. Only
>>readahead and not anticipatory scheduling addresses that.
>>
>>Anticipatory scheduling does not address the application that spends one
>>minute processing every read that it makes. Readahead does.
>>
>>Anticipatory scheduling does address the application that reads multiple
>>files that are near each other (because they are in the same directory),
>>and current readahead implementations (excepting reiser4 in progress
>>vaporware) do not.
>>
>>Anticipatory scheduling can do a better job of avoiding unnecessary
>>reads for workloads with small time gaps between reads than readahead
>>(it is potentially more accurate for some workloads).
>>
>>Is this a fair summary?
>>
>>
>
>I would also add what I feel the most important thing, that is
>anticipatory scheduling can help decreasing a lot the latencies of
>filesystem reads in presence of lots of misc I/O, by knowing which are
>the read commands that are intermediate-dependent-sync, that means
>knowing a new dependent read will be submitted very quickly as soon as
>the current read-I/O is completed.
>
Ah.... yes... I have seen that be a problem, and reiserfs suffers from
it more than ext2....
maybe we should simply have an explicit protocol for that... I would be
quite willing to have reiserfs use some flag that says
WILL_READ_NEARBY_NEXT whenever it reads an internal node to get the
location of its children.... that might be a lot cleaner than trying to
do it all in your layer... what do you guys think...
Perhaps it will be both less code, and a better result in that it avoids
some unnecessary lingering....
> In such a case it makes lots sense to
>wait for the next read to be submitted instead of start processing
>immediatly the rest of the I/O queue. This way when you read a file and
>you've to walk the indirect blocks before being able to read the data,
>you won't be greatly peanalized against the writes or reads that won't
>need to pass through metadata I/O before being served.
>
>This doesn't obviate the need of SFQ for the patological multimedia
>cases where I/O latency is the first prio, or for workloads where
>sync-write latency is the first prio.
>
>BTW, I'm also thinking that the SFQ could be selected not system wide,
>but per-process basis, with a prctl or something, so you could have all
>the I/O going into the single default async-io queue, except for mplayer
>that will use the SFQ queues. This may not even need to be privilegied
>since SFQ is fair and if an user can write a lot it can just hurt
>latency, with SFQ could hurt more but still not deadlock. This SFQ prctl
>for the I/O scheduler, would be very similar to the RT policy for the
>main process scheduler. Infact it maybe the best to just have SFQ always
>enabled, and selectable only via the SFQ prctl, and to enable the
>functionaltiy only per-process basis rather than global. We can still
>add a sysctl to enable it globally despite nobody set the per-process
>flag.
>
>Andrea
>
>
>
>
I still don't really understand your SFQ design, probably because I
haven't studied recent networking algorithms that your description
assumed I understand.
--
Hans
next prev parent reply other threads:[~2003-02-10 20:05 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 [this message]
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
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=3E48083E.6000901@namesys.com \
--to=reiser@namesys.com \
--cc=akpm@digeo.com \
--cc=andrea@suse.de \
--cc=axboe@suse.de \
--cc=ckolivas@yahoo.com.au \
--cc=david.lang@digitalinsight.com \
--cc=jakob@unthought.net \
--cc=linux-kernel@vger.kernel.org \
--cc=piggin@cyberone.com.au \
--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).