Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Thu, 26 Aug 1999 09:55:29 -0700 (PDT) | Subject | Re: mmap() better than read() fro streaming, Was: Re: Streaming disk I/O kills file buffering and makes Linux unusable |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |