If I can try everyone's patience one last time -- two messages didn't
reach the f90 list, leading to confusing citations in one of my posts.
Here's a correctly cited version of Kevin Sheehan's response to
the missing message from Brian Sumner <[log in to unmask]>:
Brian's post:
bls> It also can be far slower. When you use mmap, you only fault in one
bls> page at a time, so unless the OS does extensive `prefaulting' on
bls> your behalf, you can wind up making much shorter requests to the
bls> file system. Add to that all the interesting cases that can
bls> arise if the file is NFS mounted and things don't look so simple
bls> anymore...
bls>
bls> mmap can be useful in certain situations, but I recommend caution.
Kevin's response:
> From: [log in to unmask]
>
> bls> mmap can be useful in certain situations, but I recommend caution.
>
> Caution is always a good thing, but I recommend finding out more about
> the facilities involved first, hence the paper :-)
>
> I'd really like to avoid debate and religion here, as I am not familiar
> with the charter of the list, but suspect Unix VM discussion are not
> germane to Fortran in general. As the author I think a couple of
> things need to be pointed out here. (and will do again so when my copious
> free time allows me to update the paper :-)
>
> If further discussion is warranted, I suggest taking it offline.
>
> bls> It also can be far slower. When you use mmap, you only fault in one
> bls> page at a time, so unless the OS does extensive `prefaulting' on
> bls> your behalf, you can wind up making much shorter requests to the
> bls>
>
> One of the arguments for using mmap() is that with madvise() and msync()
> you can explicitly control the use of VM resources. I.e. one of
> the strengths is giving the VM system a priori knowledge of what it is
> you want done with pages instead of making it guess. (e.g. running
> the page daemon or paging in short chunks as suggested above)
>
> madvise() gives you WILLNEED and WONTNEED to give a hint as to useful
> prefetching and when to lose the pages. WILLNEED in particular starts
> the system faulting in pages asynchronously in order to avoid both the
> necessity of guessing (speculative pre-fetching by the OS) or hitting an
> I/O wall all the time (not pre-fetching).
>
> bls> file system. Add to that all the interesting cases that can
> bls> arise if the file is NFS mounted and things don't look so simple
> bls> anymore...
>
> As for NFS and sharing writable files, consistency is a tricky problem
> as locking turns off the ability to use mmap(). The solution suggested
> is to use a secondary file of the same length with no contents for
> locking, and msync() to refresh and/or push pages back to the server
> as appropriate.
>
>
> mmap() is not a panacea for all ills, but the question asked by the
> paper is still valid far too many years after its publication :-)
>
> l & h,
> kev
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|