From: Jeremy Jackson <jerj@coplanar.net>
To: Helge Hafting <helgehaf@idb.hist.no>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Is there a way to turn file caching off ?
Date: Thu, 19 Apr 2001 12:15:10 -0400 [thread overview]
Message-ID: <3ADF0F0E.BBD78FE1@coplanar.net> (raw)
In-Reply-To: <Pine.LNX.3.96.1010418134153.20558A-100000@medusa.sparta.lu.se> <3ADD99E8.FB7F8542@coplanar.net> <3ADE9FFA.3E8476C2@idb.hist.no>
Helge Hafting wrote:
> Jeremy Jackson wrote:
>
> > currently all the kernel's heuristics are feed-back control loops.
> > what you are asking for is a feed-forward system: a way for the application
> > to tell kernel "I'm only reading this once, so after I'm done, throw it out
> > straight away"
> > and "I'm only writing this data, so after I'm done, start writing it out and
> > then forget it"
> >
> This is hard to get right. Sure - your unpack/copy program read once
> and
> writes once. But the stuff might be used shortly thereafter by
> another process. For example: I unpack a kernel tarball. tar
> knows it writes only once and might not need more than 5M to do
> this as efficient as possible with my disks. A lot of other cache
> could be saved, fewer things swapped out.
> But then I compile it. Todays system ensures that lots of the source
> is in memory already. Limiting the caching to what tar needed
> however will force the source to be read from disk once during
> the compile - not what I want at all.
They why would you tell tar not to use cache? If you know what's happening
next you need to tell the system (feed-forward), not have it try to read your
mind. I'm assuming your modified tar would have an option switch
to cause this behaviour, not be hard coded...
>
>
> A program may know its own access pattern, but it don't usually know
> future access patterns. Well, backing up the entire fs could benefit
Yes, so a script that does the above wouldn't enable no cache mode
for written files. The program doesn't know, but the encompasing
script (or person at console) does.
>
> from a something like this, you probably won't need the backup again
> soon. But this is hard to know in many other cases.
next prev parent reply other threads:[~2001-04-19 16:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-17 16:37 Is there a way to turn file caching off ? Laurent Chavet
2001-04-18 4:56 ` David Schwartz
2001-04-18 11:49 ` Bjorn Wesen
2001-04-18 13:43 ` Jeremy Jackson
2001-04-18 9:56 ` Very bad behavior of kswapd Laurent Chavet
2001-04-18 18:52 ` Rik van Riel
2001-04-18 19:15 ` David S. Miller
2001-04-19 8:21 ` Is there a way to turn file caching off ? Helge Hafting
2001-04-19 16:15 ` Jeremy Jackson [this message]
2001-04-19 18:01 ` John Lenton
[not found] <3ADD4E61.A2A9CE9@av.com>
2001-04-18 18:21 ` David Schwartz
2001-04-18 19:00 ` Andrea Arcangeli
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=3ADF0F0E.BBD78FE1@coplanar.net \
--to=jerj@coplanar.net \
--cc=helgehaf@idb.hist.no \
--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.