From: Erik Andersen <andersen@codepoet.org>
To: Giuliano Pochini <pochini@shiny.it>
Cc: linux-kernel@vger.kernel.org, Mark Mielke <mark@mark.mielke.cc>,
Jamie Lokier <lk@tantalophile.demon.co.uk>,
Robert Love <rml@tech9.net>
Subject: Re: [PATCH] O_STREAMING - flag for optimal streaming I/O
Date: Thu, 10 Oct 2002 03:10:00 -0600 [thread overview]
Message-ID: <20021010091000.GA16695@codepoet.org> (raw)
In-Reply-To: <XFMail.20021010103336.pochini@shiny.it>
On Thu Oct 10, 2002 at 10:33:36AM +0200, Giuliano Pochini wrote:
>
> On 10-Oct-2002 Erik Andersen wrote:
> > I don't think grep is a very good candidate for O_STREAMING. I
> > usually want the stuff I grep to stay in cache. O_STREAMING is
> > much better suited to applications like ogle, vlc, xine, xmovie,
> > xmms etc since there is little reason for the OS to cache things
> > like songs and movies you aren't likely to hear/see again any
> > time soon.
>
> The kernel already have cache pruning algorithm. O_STREAMING logic
> should not clear caches if there is no need to do that. We could
The entire point of O_STREAMING is to let user space specify
policy. If user space user space knows with 100% certainty that
the data being read/written from a particular file descriptor is
use-once-and-discard data, then it makes sense to honor that
hint. In this case, user space knows best and can set policy on
a per file descriptor basis.
Note that most applications do not want to use this flag. But
for a few applications it just just perfect. For example, if I
am playing a DVD there is absolutely no point in the kernel
trying to cache the content of the DVD. A DVD has way too much
content for caching it to do any good, and since most people
watch a DVD once through from beginning to end, there is no point
stuffing the DVD's content into the pagecache, thereby crowding
out other things that should remain in cache.
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
next prev parent reply other threads:[~2002-10-10 9:04 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-08 2:38 [PATCH] O_STREAMING - flag for optimal streaming I/O Robert Love
2002-10-08 10:42 ` J.A. Magallon
2002-10-08 18:08 ` Robert Love
2002-10-08 18:38 ` Chris Wedgwood
2002-10-08 18:49 ` Robert Love
2002-10-08 19:05 ` Chris Wedgwood
2002-10-08 19:17 ` Robert Love
2002-10-08 19:30 ` Andrew Morton
2002-10-09 14:14 ` Marco Colombo
2002-10-09 16:30 ` kernel
2002-10-08 19:52 ` Chris Wedgwood
2002-10-08 19:59 ` Robert Love
2002-10-08 20:01 ` Chris Wedgwood
2002-10-09 8:33 ` Giuliano Pochini
2002-10-09 8:43 ` Andrew Morton
2002-10-09 10:55 ` Giuliano Pochini
2002-10-09 17:05 ` Mark Mielke
2002-10-09 19:36 ` Giuliano Pochini
2002-10-09 22:24 ` Mark Mielke
2002-10-09 23:20 ` Jamie Lokier
2002-10-10 3:07 ` Mark Mielke
2002-10-10 10:55 ` Helge Hafting
2002-10-10 17:50 ` Mark Mielke
2002-10-10 3:29 ` Erik Andersen
2002-10-10 3:37 ` Robert Love
2002-10-10 13:39 ` Giuliano Pochini
2002-10-10 22:50 ` Mike Fedyk
2002-10-10 22:58 ` Erik Andersen
2002-10-11 8:26 ` Giuliano Pochini
2002-10-11 8:32 ` Helge Hafting
2002-10-10 8:33 ` Giuliano Pochini
2002-10-10 9:10 ` Erik Andersen [this message]
2002-10-10 9:38 ` Giuliano Pochini
2002-10-10 10:40 ` Miquel van Smoorenburg
2002-10-10 11:01 ` Helge Hafting
2002-10-10 12:29 ` Xavier Bestel
2002-10-10 13:17 ` Giuliano Pochini
2002-10-10 22:44 ` Mike Fedyk
2002-10-11 8:13 ` Giuliano Pochini
2002-10-10 11:38 ` O_STREAMING has insufficient info - how about fadvise() ? Alan Cox
2002-10-10 11:47 ` William Lee Irwin III
2002-10-10 15:34 ` Andrew Morton
2002-10-10 16:08 ` Alan Cox
2002-10-10 16:49 ` Oliver Xymoron
2002-10-10 15:37 ` [PATCH] O_STREAMING - flag for optimal streaming I/O Gerhard Mack
2002-10-10 22:47 ` Mike Fedyk
2002-10-11 2:14 ` Gerhard Mack
2002-10-11 8:10 ` Chris Wedgwood
2002-10-10 9:14 ` David Lang
2002-10-10 14:51 ` Denis Vlasenko
2002-10-08 19:53 ` Matthias Schniedermeyer
2002-10-08 19:59 ` Chris Wedgwood
2002-10-08 20:03 ` Andrew Morton
2002-10-08 20:34 ` Matthias Schniedermeyer
2002-10-08 20:42 ` Andrew Morton
2002-10-08 20:37 ` Larry McVoy
2002-10-09 11:53 ` Roy Sigurd Karlsbakk
2002-10-09 14:10 ` Marco Colombo
2002-10-09 14:14 ` Robert Love
2002-10-09 14:33 ` Richard B. Johnson
2002-10-09 15:27 ` Andreas Dilger
2002-10-09 23:17 ` Jamie Lokier
2002-10-09 23:46 ` Rik van Riel
2002-10-10 0:16 ` Jamie Lokier
2002-10-10 2:39 ` Erik Andersen
2002-10-10 10:33 ` Marco Colombo
2002-10-10 20:00 ` Erik Andersen
-- strict thread matches above, loose matches on Subject: below --
2002-10-11 4:16 Hank Leininger
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=20021010091000.GA16695@codepoet.org \
--to=andersen@codepoet.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lk@tantalophile.demon.co.uk \
--cc=mark@mark.mielke.cc \
--cc=pochini@shiny.it \
--cc=rml@tech9.net \
/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.