linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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)



  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).