Re: mmap() better than read() fro streaming, Was: Re: Streaming disk I/O kills file buffering and ma

["Stephen C. Tweedie" <sct@redhat.com>]

Hi,

Benno Senoner writes:

 > Yes, I run with mlockall(MCL_CURRENT|MCL_FUTURE)
 > I can confirm this now:
 > I just removed my memcpy()s for testing purposes, and the app loads the
 > data nicely.

As it should be.  mlock/mlockall apply to _all_ pages which appear in
your process' address space, regardless of whether they are page cache
or local data pages.

 > Pratically this means that if you enabled MCL_FUTURE, mmap() will
 > return only after all the mapped segment of the file resides in
 > memory.  Correct me please if I am wrong.

Yes.  If MCL_FUTURE is used then all future mmap()s are automatically
marked as locked, and we do a make_pages_present() before returning
from mmap.  This is exactly what mlockall is designed for: memory
access should simply never page fault if you use MCL_CURRENT |
MCL_FUTURE.  This is even true for writable MAP_PRIVATE pages: if you
have full mlockall enabled, then the make_pages_present() will do a
copy-on-write page fault for you.

--Stephen