apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: apr_buckets_file.c:file_read + XTHREAD
Date Wed, 28 Nov 2001 05:51:26 GMT
From: "Ryan Bloom" <rbb@covalent.net>
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



Mime
View raw message