Re: poison mmap cache

["James K. Lowden" <jklowden%schemamania.org@localhost>]

On Tue, 12 Aug 2014 12:15:38 +0930
Brett Lymn <blymn%internode.on.net@localhost> wrote:

> > 
> > Suggestions?  What would you do?  
> > 
> 
> I would use msync(2) with the MS_INVALIDATE flag on your test file to
> invalidate the cached pages.

Thanks, Brett.  I'm afraid that's a fine answer to the question I
asked, instead of the one I should have asked....

Each test is a separate process, and tests are executed sequentially.
My concern is that the kernel's pagemap cache (or whatever it's called)
will still contain file pages from the input file when process N+1
runs, and that the kernel will, rationally, take advantage of that
fact to make mmap(2) as fast as possible.  

AIUI, msync(2) on process N wouldn't affect mmap(2) on process N+1.
If the last thing process N does is 

        msync(fd, len, MS_INVALIDATE);
        exit(0);

then when process N+1 calls mmap on the same file, the kernel is
certainly positioned to know whether or not those pages have in fact
been changed (and, in this case, they have not).  So there's no
technical *need* for the kernel to expend I/O to re-read pages it
"knows" haven't changed.  Does it do that anyway?  

I thought I would need a kernel sysctl or something, a nonportable knob
to force re-reading the file from disk.  If such exists.  

--jkl