Hi Gleb, On Mon, Jan 18, 2010 at 3:37 PM, Gleb Natapov <gleb@xxxxxxxxxx> wrote: > The current interaction between mlockall(MCL_FUTURE) and mmap has a > deficiency. In 'normal' mode, without MCL_FUTURE in force, the default > is that new memory mappings are not locked, but mmap provides MAP_LOCKED > specifically to override that default. However, with MCL_FUTURE toggled > to on, there is no analogous way to tell mmap to override the default. The > proposed MAP_UNLOCKED flag would resolve this deficiency. > > The benefit of the patch is that it makes it possible for an application > which has previously called mlockall(MCL_FUTURE) to selectively exempt > new memory mappings from memory locking, on a per-mmap-call basis. There > is currently no thread-safe way for an application to do this as > toggling MCL_FUTURE around calls to mmap is racy in a multi-threaded > context. Other threads may manipulate the address space during the > window where MCL_FUTURE is off, subverting the programmers intended > memory locking semantics. > > The ability to exempt specific memory mappings from memory locking is > necessary when the region to be mapped is larger than physical memory. > In such cases a call to mmap the region cannot succeed, unless > MAP_UNLOCKED is available. The changelog doesn't mention what kind of applications would want to use this. Are there some? Using mlockall(MCL_FUTURE) but then having some memory regions MAP_UNLOCKED sounds like a strange combination to me. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
