All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Dalecki <dalecki@evision-ventures.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Rik van Riel <riel@conectiva.com.br>,
	Jeff Garzik <jgarzik@mandrakesoft.com>,
	linux-kernel@vger.kernel.org
Subject: Re: PATCH: killing read_ahead[]
Date: Mon, 30 Oct 2000 17:35:49 +0100	[thread overview]
Message-ID: <39FDA365.F16B781D@evision-ventures.com> (raw)
In-Reply-To: <Pine.LNX.4.10.10010251036010.1337-100000@penguin.transmeta.com>

Linus Torvalds wrote:
> 
> On Wed, 25 Oct 2000, Rik van Riel wrote:
> >
> > OTOH, block-dev readahead makes sense for filesystems where
> > the packing locality is close to the access pattern BUT NOT
> > close to anything the page cache would recognise as being
> > close.
> 
> I dunno. The main reason I'd like to get the block devices into the page
> cache is that right now there is no way to mmap them - something that can
> potentially be _very_ useful, regardless of readahead.
> 
> And quite frankly, the generic file readahead has been pounded upon and
> tested a lot more than the block device read-ahead ever was. I bet it
> performs better if for no other reason.

And then of course the FS is the LOGICAL level of access to the device -
so
if read ahead matters then it's this level where it should happen -
since
this is the place where actual predictability of the next access
(actually
the assumption that the access will happen at least semi-sequentially)
has good
chances to be right. So you are completely right that the page-cache is
the right place where the rahead logic should take place. I have just
filled
the argumentation gap ;-).

-- 
- phone: +49 214 8656 283
- job:   STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!)
- langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort:
ru_RU.KOI8-R
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

       reply	other threads:[~2000-10-30 15:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.10.10010251036010.1337-100000@penguin.transmeta.com>
2000-10-30 16:35 ` Martin Dalecki [this message]
     [not found] <39F5999B.91DDC98@evision-ventures.com>
2000-10-26 23:39 ` PATCH: killing read_ahead[] Jeff V. Merkey
2000-10-27  0:47   ` Jeff V. Merkey
     [not found] <Pine.GSO.4.21.0010251435100.12098-100000@weyl.math.psu.edu>
2000-10-26 20:44 ` Linus Torvalds
2000-10-29 14:43   ` Alexander Viro
     [not found] <39F5DAF5.1D3662BD@mandrakesoft.com>
     [not found] ` <Pine.LNX.4.10.10010241245280.1704-100000@penguin.transmeta.com>
2000-10-24 22:30   ` Ingo Oeser
2000-10-25  0:16     ` Jeff V. Merkey

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=39FDA365.F16B781D@evision-ventures.com \
    --to=dalecki@evision-ventures.com \
    --cc=jgarzik@mandrakesoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@conectiva.com.br \
    --cc=torvalds@transmeta.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.