From: Ram Pai <linuxram@us.ibm.com>
To: Andreas Dilger <adilger@clusterfs.com>
Cc: Steven Pratt <slpratt@austin.ibm.com>,
Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH/RFC] Simplified Readahead
Date: 29 Sep 2004 19:26:47 -0700 [thread overview]
Message-ID: <1096511206.5481.58.camel@dyn319181.beaverton.ibm.com> (raw)
In-Reply-To: <20040929231327.GM2061@schnapps.adilger.int>
On Wed, 2004-09-29 at 16:13, Andreas Dilger wrote:
> On a readahead-related note, I'm wondering how hard it would be to have
> some tunables and/or hooks from the readahead state manchine made
> available to the filesystem? With the 2.4 readahead code it was basically
> impossible for the filesystem to disable the readahead, I haven't looked
> at the 2.6 readahead enough to determine whether we need that or not.
>
The best way currently to shutoff readahead is to poke into the file
descriptors' readahead structure and set ra_pages to 0.
> The real issue (reason for turning off RA in 2.4) is that within Lustre
> there can be many DLM extent locks for a single file, so client A can
> be writing to one part of the file, and client B can be reading from
> another part of the same file. With the stock readahead it wouldn't
> stay within the lock extent boundaries, and we couldn't turn it off
> easily. Having some sort of FS method that says "don't do RA beyond
> this offset" would be useful here.
>
> The other problem that Lustre had was that the stock readahead would
> send out page reads in small chunks as the window grew instead of
> sending out large requests that could be turned into large, efficient
> network RPCs. So the desire would be to have some sort of tunable in
> the readahead state (per fs or per file) that says "don't submit
> another readahead until the window is growing by X pages".
>
> As it is we've basically had to implement our own readahead code within
> the filesystem in order to get correct behaviour and good performance.
> This is of course not optimal from a code duplication point of view and
> also we don't get any benefits from the algorithm improvements being
> done here.
>
>
> The other question is whether the new readahead code takes the latency
> of completing read requests into account when determining the size of
> the readahead window?
No. it does not currently. But taking that into consideration will be
tricky. If Luster does that it would be nice to know how does it.
RP
next prev parent reply other threads:[~2004-09-30 2:27 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-23 16:06 Steven Pratt
2004-09-23 22:14 ` Joel Schopp
2004-09-24 0:21 ` Nick Piggin
2004-09-24 2:42 ` Andrew Morton
2004-09-24 15:40 ` Steven Pratt
2004-09-24 16:16 ` Nick Piggin
2004-09-24 16:48 ` Steven Pratt
2004-09-24 22:05 ` Andrew Morton
2004-09-24 22:43 ` Steven Pratt
2004-09-24 23:01 ` Andrew Morton
2004-09-27 15:39 ` Steven Pratt
2004-09-27 19:26 ` Andrew Morton
2004-09-28 10:13 ` Jens Axboe
2004-09-24 22:55 ` Steven Pratt
2004-09-27 20:29 ` Ray Bryant
2004-09-27 21:04 ` Steven Pratt
2004-09-25 0:45 ` Nick Piggin
2004-09-25 1:01 ` Ram Pai
2004-09-25 6:07 ` Ram Pai
2004-09-27 15:30 ` Steven Pratt
2004-09-27 18:42 ` Ram Pai
2004-09-27 20:07 ` Steven Pratt
2004-09-29 18:46 ` Ram Pai
2004-09-29 22:33 ` Steven Pratt
2004-09-29 23:13 ` Andreas Dilger
2004-09-30 2:26 ` Ram Pai [this message]
2004-09-30 5:29 ` Andrew Morton
2004-09-30 20:20 ` Stephen C. Tweedie
2004-09-30 1:12 ` Ram Pai
2004-10-01 21:02 ` Steven Pratt
2004-10-05 17:52 ` Ram Pai
[not found] <372479081@toto.iv>
2004-09-24 5:00 ` Peter Chubb
2004-09-24 22:57 ` Steven Pratt
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=1096511206.5481.58.camel@dyn319181.beaverton.ibm.com \
--to=linuxram@us.ibm.com \
--cc=adilger@clusterfs.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=slpratt@austin.ibm.com \
/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
all inboxes | Powered by JetHome®