From: David Rolenc <drolenc@rtlogic.com>
To: linux-kernel@vger.kernel.org
Subject: Re: POSIX_FADV_NOREUSE and O_STREAMING behavior in 2.6.7
Date: Thu, 26 Aug 2004 13:23:57 -0600 [thread overview]
Message-ID: <412E38CD.1050408@rtlogic.com> (raw)
In-Reply-To: <1093544239.30480.7.camel@betsy.boston.ximian.com>
Is there any technical reason that we couldn't set a flag in the struct
file* and put code in the read/write calls to handle shrinking the page
cache? This is similar to what was done with O_STREAMING in 2.4. It
seems like it would conform more to the behavior expected from
POSIX_FADV_NOREUSE, and I wouldn't have to make a bunch of system calls :-)
-Dave
Robert Love wrote:
>On Thu, 2004-08-26 at 11:39 -0600, David Rolenc wrote:
>
>
>>I am trying to get O_STREAMING (Robert Love patch for 2.4) behavior in
>>2.6 and just a glance at fadvise.c suggests that POSIX_FADV_NOREUSE is
>>not implemented any differently than POSIX_FADV_WILLNEED. Am I missing
>>something?
>>
>>
>
>Yes, they are currently the same. Their difference in theory is subtle:
>NOREUSE says "I will use this once in the future" and WILLNEED says "I
>will use this [some number of times] in the future".
>
>So for both of them, you want to keep the data in the page cache. But
>for NOREUSE you could do drop-behind of the pages. But Linux does not
>currently do drop-behind, so we have them both do the same thing.
>
>
>
>> I want to read data from disk with readahead and drop the
>>data from the page cache as soon as I am done with it. Do I have to call
>>fadvise with POSIX_FADV_DONTNEED after every read?
>>
>>
>
>Yes, you do. Or every couple of reads.
>
>The sort of applications that need DONTNEED already are setup in a way
>to make that easy. You either have a streaming loop, like:
>
> do {
> read
> process
> } while (repeat);
>
>Or you are readings lots of files (like updatedb).
>
>In the first case, just stick the fadvise call after the processing. In
>the latter case, call fadvise before closing the file.
>
>You don't _have_ to call fadvise after every reading. Just whenever you
>want to drop the pages. Whenever it makes sense.
>
> Robert Love
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
next prev parent reply other threads:[~2004-08-26 19:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-26 17:39 POSIX_FADV_NOREUSE and O_STREAMING behavior in 2.6.7 David Rolenc
2004-08-26 18:17 ` Robert Love
2004-08-26 19:23 ` David Rolenc [this message]
2004-08-26 18:38 ` David Greaves
2004-08-26 19:11 ` Trond Myklebust
2004-08-27 8:25 ` David Greaves
2004-08-27 17:21 ` Trond Myklebust
2004-08-27 17:37 ` Trond Myklebust
2004-08-26 19:11 ` David Rolenc
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=412E38CD.1050408@rtlogic.com \
--to=drolenc@rtlogic.com \
--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 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.