From: Andreas Dilger <adilger@clusterfs.com>
To: Steven Pratt <slpratt@austin.ibm.com>
Cc: linuxram@us.ibm.com, akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH/RFC] Simplified Readahead
Date: Wed, 29 Sep 2004 17:13:27 -0600 [thread overview]
Message-ID: <20040929231327.GM2061@schnapps.adilger.int> (raw)
In-Reply-To: <415B3845.3010005@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2014 bytes --]
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 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? Lustre generally runs with very fast disk and
network systems so the size of the readahead window has to be very large
in order to keep the pipeline full to avoid stalling on the client.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-09-29 23:13 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 [this message]
2004-09-30 2:26 ` Ram Pai
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=20040929231327.GM2061@schnapps.adilger.int \
--to=adilger@clusterfs.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--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®