Messages in this thread | | | Date | Fri, 22 May 1998 16:55:51 -0700 | From | Jim Wilcoxson <> | Subject | Re: Swapping in 2.1.103? |
| |
At 01:50 PM 5/22/98 +0200, you wrote: >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.
This would be a good test case for any algorithm change. As long as there are free memory pages, the buffer cache would continue to expand. Since header files would be referenced more often, they would presumably have priority over regular source files that were referenced only once; LRU should handle that.
When free memory is no longer available, is it better to get rid of previously compiled C program files in the buffer cache, or start paging out applications?
Another scenario: you are editing in Emacs and stop to think a few minutes. The guy next to you decides to compile the kernel. Should the buffer cache steal your Emacs text/data pages so that it can fill memory with every C file in the kernel? My suggestion wasn't to throw out sequentially accessed files as soon as possible. But going on a strictly LRU algorithm, your Emacs pages would be gone and lots of C file buffers that will never be used again would be in memory. Assuming there isn't room for everything of course.
>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.
The flag sounds like a good idea, but setting it heuristically or incrementing a counter in lseek would be more effective than a new open mode.
Can you give me a pointer to Albert's wish list?
Thanks, Jim
> >Cheers, > >Marnix Coppens
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |