DragonFly On-Line Manual Pages

Search: Section:  

MLOCKALL(2)              DragonFly System Calls Manual             MLOCKALL(2)


mlockall, munlockall - lock (unlock) the address space of a process


Standard C Library (libc, -lc)


#include <sys/types.h> #include <sys/mman.h> int mlockall(int flags); int munlockall(void);


The mlockall() system call locks into memory the physical pages associated with the address space of a process until the address space is unlocked, the process exits, fork()s, or execs another program image. Any pages which are copy-on-write at the time of the function call will be force faulted. Locked pages will not be paged to swap backing store. The following flags affect the behavior of mlockall(): MCL_CURRENT Lock all pages currently mapped into the process's address space. MCL_FUTURE Lock all pages mapped into the process's address space in the future, at the time the mapping is established. Note that this may cause future mappings to fail if those mappings cause resource limits to be exceeded. Since physical memory is a potentially scarce resource, processes are limited in how much they can lock down. A single process can lock the minimum of a system-wide "wired pages" limit and the per-process RLIMIT_MEMLOCK resource limit. mlockall() has two limitations, necessary to keep it functional on modern systems. The first is that writable file-backed MAP_PRIVATE pages (such as shared library mappings) which have not yet been write-faulted will retain their read-only mapping to the file backing store and not be force-copied. If we were to force copy these pages, it would cause immense unnecessary overheads for the program. So any unmodified but writable pages which are currently in the pmap read-only will still take a COW fault if written to. The second limitation is that when a fork() is issued, all writable pages will be made copy-on-write (COW) in both the parent and the child. The child of course does not inherit the locked memory state, but this action will cause any locked pages in the parent to become copy-on-write and they will be faulted if written to. So they will not be quite as locked as might have been intended in this situation. The munlockall() call unlocks any locked memory regions in the process address space. Any regions mapped after an munlockall() call will not be locked.


A return value of 0 indicates that the call succeeded and all pages in the range have either been locked or unlocked. A return value of -1 indicates an error occurred and the locked status of all pages in the range remains unchanged. In this case, the global location errno is set to indicate the error.


mlockall() will fail if: [EINVAL] The flags argument is zero, or includes unimplemented flags. [ENOMEM] Locking the indicated range would exceed either the system or per-process limit for locked memory. [EPERM] The calling process does not have the appropriate privilege to perform the requested operation.


mincore(2), mlock(2), setrlimit(2)


The mlockall() and munlockall() functions are believed to conform to IEEE Std 1003.1-2001 ("POSIX.1").


The mlockall() and munlockall() functions first appeared in DragonFly 2.9.


How could there be any bugs? This is soooo simple... These system calls are not recommended for general use. They are obviously not thread-safe, and the larger application context from which they are called might be hostile to such actions due to non-deterministic resource limits in the system. In a modern system, even semi-realtime and interactive processes are already detected and handled by the system schedule. Please use mlock() and munlock() to lock specific address ranges instead of locking the entire address space. DragonFly 6.3-DEVELOPMENT May 16, 2022 DragonFly 6.3-DEVELOPMENT

Search: Section: