lkml.org 
[lkml]   [1998]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Swapping in 2.1.103?
Karl GünterWünsch wrote:
>Jim Wilcoxson wrote:
>>
>> ..., but perhaps there could be something like "if a file has never
>> been repositioned, then after it is closed, mark its file buffers so that
>> they will be re-used before paging out non-buffer-cache pages". Also,
>> sequentially accessing a large file shouldn't wipe out the buffer cache.
>> If a file has never been positioned while reading/writing, there is a good
>> chance that the data in the buffer cache, except for the page where the
>> file pointer is (or future pages for read-ahead) will not be needed in the
>> near future...

I may be totally clueless here, but what if you are working on a program,
that (often indirectly) uses a *large* number of relatively
small header files. Just strace the compiler and watch it open several
hundred files in all. These files are used in a sequential fashion and
have a short life span (open, quick read, close, repeat xxx times).
If you are in a edit-compile-debug cycle, you don't want all these files
to be thrown out as quickly as possible, on the contrary.

The (obvious) point is that the usage frequency matters far more than
the occasional repositioning. Unless of course, you are talking about
adding a new flag to the open mode (like NT's FILE_FLAG_NO_BUFFERING or
FILE_FLAG_SEQUENTIAL_SCAN or FILE_FLAG_RANDOM_ACCESS), rather than
modifying the default behaviour. Check Albert Cahalan's wish list.

Cheers,

Marnix Coppens

---
Reality is that which | Artificial Intelligence
when you stop believing | stands no chance against
in it doesn't go away. (Philip K. Dick) | Natural Stupidity.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.089 / U:0.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site