From: Steven Cole <elenstev@mesatop.com>
To: Andries.Brouwer@cwi.nl
Cc: akpm@zip.com.au, linux-kernel@vger.kernel.org,
Dave Jones <davej@suse.de>
Subject: Re: readahead
Date: 16 Apr 2002 10:08:23 -0600 [thread overview]
Message-ID: <1018973304.2304.10.camel@spc.esa.lanl.gov> (raw)
In-Reply-To: <UTC200204161354.g3GDsFO28323.aeb@smtp.cwi.nl>
On Tue, 2002-04-16 at 07:54, Andries.Brouwer@cwi.nl wrote:
> [readahead.c has badly readable comments, on a standard
> 80-column display: many lines have a size just slightly
> over 80 chars]
[other stuff snipped]
How is this? Now the longest comment line should end at column 80.
Patch is made against 2.5.8-dj1.
Steven
--- linux-2.5.8-dj1/mm/readahead.c.orig Tue Apr 16 09:25:36 2002
+++ linux-2.5.8-dj1/mm/readahead.c Tue Apr 16 09:54:31 2002
@@ -63,9 +63,10 @@
* Together, start and size represent the `readahead window'.
* next_size: The number of pages to read when we get the next readahead miss.
* prev_page: The page which the readahead algorithm most-recently inspected.
- * prev_page is mainly an optimisation: if page_cache_readahead sees
- * that it is again being called for a page which it just looked at,
- * it can return immediately without making any state changes.
+ * prev_page is mainly an optimisation: if page_cache_readahead
+ * sees that it is again being called for a page which it just
+ * looked at, it can return immediately without making any state
+ * changes.
* ahead_start,
* ahead_size: Together, these form the "ahead window".
*
@@ -95,30 +96,31 @@
* If readahead hits are more sparse (say, the application is only reading every
* second page) then the window will build more slowly.
*
- * On a readahead miss (the application seeked away) the readahead window is shrunk
- * by 25%. We don't want to drop it too aggressively, because it's a good assumption
- * that an application which has built a good readahead window will continue to
- * perform linear reads. Either at the new file position, or at the old one after
- * another seek.
- *
- * There is a special-case: if the first page which the application tries to read
- * happens to be the first page of the file, it is assumed that a linear read is
- * about to happen and the window is immediately set to half of the device maximum.
+ * On a readahead miss (the application seeked away) the readahead window is
+ * shrunk by 25%. We don't want to drop it too aggressively, because it's a
+ * good assumption that an application which has built a good readahead window
+ * will continue to perform linear reads. Either at the new file position,
+ * or at the old one after another seek.
+ *
+ * There is a special-case: if the first page which the application tries to
+ * read happens to be the first page of the file, it is assumed that a linear
+ * read is about to happen and the window is immediately set to half of the
+ * device maximum.
*
* A page request at (start + size) is not a miss at all - it's just a part of
* sequential file reading.
*
* This function is to be called for every page which is read, rather than when
- * it is time to perform readahead. This is so the readahead algorithm can centrally
- * work out the access patterns. This could be costly with many tiny read()s, so
- * we specifically optimise for that case with prev_page.
+ * it is time to perform readahead. This is so the readahead algorithm can
+ * centrally work out the access patterns. This could be costly with many tiny
+ * read()s, so we specifically optimise for that case with prev_page.
*/
/*
* do_page_cache_readahead actually reads a chunk of disk. It allocates all the
- * pages first, then submits them all for I/O. This avoids the very bad behaviour
- * which would occur if page allocations are causing VM writeback. We really don't
- * want to intermingle reads and writes like that.
+ * pages first, then submits them all for I/O. This avoids the very bad
+ * behaviour which would occur if page allocations are causing VM writeback.
+ * We really don't want to intermingle reads and writes like that.
*/
void do_page_cache_readahead(struct file *file,
unsigned long offset, unsigned long nr_to_read)
@@ -231,7 +233,8 @@
ra->next_size += 2;
} else {
/*
- * A miss - lseek, pread, etc. Shrink the readahead window by 25%.
+ * A miss - lseek, pread, etc.
+ * Shrink the readahead window by 25%.
*/
ra->next_size -= ra->next_size / 4;
if (ra->next_size < min)
next prev parent reply other threads:[~2002-04-16 16:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-16 13:54 readahead Andries.Brouwer
2002-04-16 16:08 ` Steven Cole [this message]
2002-04-16 18:25 ` readahead Andrew Morton
2002-04-16 19:10 readahead Andries.Brouwer
2002-04-16 19:23 ` readahead Andrew Morton
2002-04-16 19:33 ` readahead Jens Axboe
2002-04-16 20:21 readahead Andries.Brouwer
2003-10-30 19:23 READAHEAD age
2003-10-30 21:44 ` READAHEAD Andrew Morton
2003-10-31 7:43 ` READAHEAD Nuno Silva
2003-10-31 8:03 ` READAHEAD Andrew Morton
2003-10-31 12:20 ` READAHEAD age
2003-10-31 9:28 ` READAHEAD Andrew Morton
2003-10-31 9:29 ` READAHEAD Andrew Morton
2003-11-01 9:15 ` READAHEAD age
2003-11-03 0:15 ` READAHEAD Derek Foreman
2003-11-01 17:22 READAHEAD Voluspa
2005-09-27 2:38 Readahead Alan Stern
2005-09-27 3:06 ` Readahead Randy.Dunlap
2005-09-27 4:24 ` Readahead Andrew Morton
2005-09-28 18:40 ` Readahead Alan Stern
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=1018973304.2304.10.camel@spc.esa.lanl.gov \
--to=elenstev@mesatop.com \
--cc=Andries.Brouwer@cwi.nl \
--cc=akpm@zip.com.au \
--cc=davej@suse.de \
--cc=linux-kernel@vger.kernel.org \
/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).