From: "Ryan Bloom" <[EMAIL PROTECTED]> Sent: Tuesday, November 27, 2001 11:35 PM
> Bill's idea was to map and then unmap the individual sections of the file, so > that no more than one section was mapped at a time. If you do that, and you > really unmap each section as you map the next, you will be thrashing your > MMAPs. If you are really going to leave each section as an MMAP, then I > would agree completely, and say let's do it, but that wasn't what Bill > suggested. MMAPs consume memory. Yes, they may not start in-memory but await their first pagefault. Yes, they may go away when they fall off the mru and weren't modified. But why force the kernel to make these elections when we can help? If you set some arbitrary mmap limit based on your available memory and anticipated consumption, then cycle out those pages, you avoid forcing unneeded pagefaults for lack of memory and the associated discarding of the mmaps themselves. Now I'm speaking to Win32, I don't know the Unix mmap architecture, but I don't imagine it's that different. The bottom line is that the read-from-file is as optimized as you can _ever_ get with an mmaped section. It is far more efficient than a read call which is soaking the kernel buffer, then copying to the user's buffer space. I imagine the cost of mru elections will outweigh any imagined benefit from keeping a much-too-large file mapped in memory. Bill
