From: Andrea Arcangeli <andrea@suse.de>
To: Nick Piggin <piggin@cyberone.com.au>
Cc: Hans Reiser <reiser@namesys.com>, Andrew Morton <akpm@digeo.com>,
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 13:22:48 +0100 [thread overview]
Message-ID: <20030210122248.GG31401@dualathlon.random> (raw)
In-Reply-To: <3E4796D5.7070009@cyberone.com.au>
On Mon, Feb 10, 2003 at 11:11:01PM +1100, Nick Piggin wrote:
> Andrea Arcangeli wrote:
>
> >On Mon, Feb 10, 2003 at 10:45:59PM +1100, Nick Piggin wrote:
> >
> >>perspective it does nullify the need for readahead (though
> >>it is obivously still needed for other reasons).
> >>
> >
> >I'm guessing that physically it may be needed from a head prospective
> >too, I doubt it only has to do with the in-core overhead. Seeing it all
> >before reaching the seek point might allow the disk to do smarter things
> >and to keep the head at the right place for longer, dunno. Anyways,
> >whatever is the reason it doesn't make much difference from our point of
> >view ;), but I don't expect this hardware behaviour changing in future
> >high end storage.
> >
> I don't understand it at all. I mean there is no other IO going
Unfortunately I can't help you understand it, but this is what I found
with my pratical experience, I found it the first time in my alpha years
ago when I increased the sym to 512k in early 2.4 then since it could
break stuff we added the max_sectors again in 2.4. But of course if you
don't fix readahead there's no way reads can take advantage of these
lowlevel fixes. I thought I fixed readahead too but I felt it got backed
out and when I noticed I resurrected it in my tree (see the name of the
patch ;)
> >NOTE: just to be sure, I'm not at all against anticpiatory scheduling,
> >it's clearly a very good feature to have (still I would like an option
> >to disable it especially in heavy async environments like databases,
> >where lots of writes are sync too) but it should be probably be enabled
> >by default, especially for the metadata reads that have to be
> >synchronous by design.
> >
> Yes it definately has to be selectable (in fact, in my current
> version, setting antic_expire = 0 disables it), and Andrew has
> been working on tuning the non anticipatory version into shape.
Great.
> >Infact I wonder that it may be interesting to also make it optionally
> >controlled from a fs hint (of course we don't pretend all fs to provide
> >the hint), so that you stall I/O writes only when you know for sure
> >you're going to submit another read in a few usec, just the time to
> >parse the last metadata you read. Still a timeout would be needed for
> >scheduling against RT etc..., but it could be a much more relaxed
> >timeout with this option enabled, so it would need less accurate
> >timings, and it would be less dependent on hardware, and it would
> >be less prone to generate false positive stalls. The downside is having
> >to add the hints.
> >
> It would be easy to anticipate or not based on hints. We could
yep.
> anticipate sync writes if we wanted, lower expire time for sync
> writes, increase it for async reads. It is really not very
> complex (although the code needs tidying up).
this is not the way I thought at it. I'm interested to give an hint
only to know for sure which are the intermediate sync dependent reads
(the obvious example is when doing the get_block and walking the
3 level of inode indirect metadata blocks with big files, or while
walking the balanced tree in reiserfs), and I'm not interested at all
about writes. And I would just set an higher timeout when a read that I
know for sure (thanks to the hint) is "intermdiate" is completed. We can
use high timeouts there because we know they won't trigger 90% of the
time, a new dependent read will be always submitted first.
Andrea
next prev parent reply other threads:[~2003-02-10 12:13 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 [this message]
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
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=20030210122248.GG31401@dualathlon.random \
--to=andrea@suse.de \
--cc=akpm@digeo.com \
--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=reiser@namesys.com \
--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).