6 ms·

From the manpage of mlockall > All pages that contain a part of the specified address range are guaranteed to be resident in RAM when the call returns successf

From the manpage of mlockall > All pages that contain a part of the specified address range are guaranteed to be resident in RAM when the call returns successfully; the pages are guaranteed to stay in RAM until later unlocked. So it doesn't matter if the memory is dirty, as long as it's marked as locked.

rkeene2 8y ago
But since the memory is never actually backed by anything, it doesn't have a real effect except in the accounting of the process. No additional memory is used by locking it.
- wolfgang42 8y ago
  Doesn't "guaranteed to be resident in RAM" mean the memory gets backing?
  - rkeene2 8y ago
    No, because the pages aren't mapped to anything -- not disk, RAM, or an external paging device. Allocating a chunk of memory typically doesn't map those pages to anything immediately (since there's no benefit to doing that extra work). The current Linux man page gives a bit more insight: mlockall() and munlockall() mlockall() locks all pages mapped into the address space of the calling process. This includes the pages of the code, data and stack segment, as well as shared libraries, user space kernel data, shared memory, and memory-mapped files. All mapped pages are guaranteed to be resident in RAM when the call returns successfully; the pages are guaranteed to stay in RAM until later unlocked. The flags argument is con‐ structed as the bitwise OR of one or more of the following constants: MCL_CURRENT Lock all pages which are currently mapped into the address space of the process. MCL_FUTURE Lock all pages which will become mapped into the address space of the process in the future. These could be, for instance, new pages required by a grow‐ ing heap and stack as well as new mem‐ ory-mapped files or shared memory regions.
    - wolfgang42 8y ago
      Ah, I see--it's all mapped pages, not all pages as irishsultan's comment says. That makes a lot more sense, thanks!
      - rkeene2 8y ago
        After some experimenting it will fault all the mapped pages, causing the VM subsystem to try to back them. In Linux 4.4+ there is an a flag to `mlockall(2)` called "MCL_ONFAULT" which does not do that and instead locks the pages as they become backed. $ cat wheres-the-ram.c #! /home/rkeene/bin/c #include <sys/mman.h> #include <stdlib.h> #include <stdio.h> int main(int argc, char **argv) { unsigned char *buffer; int mla_ret; mla_ret = mlockall(MCL_CURRENT | MCL_FUTURE | MCL_ONFAULT); if (mla_ret != 0) { perror("mlockall"); return(1); } buffer = malloc(1024LLU * 1024LLU * 1024LLU * 32LLU); if (!buffer) { perror("malloc"); return(1); } buffer[0] = 1; buffer[1] = buffer[0]; buffer[2] = buffer[3]; puts("Success !"); return(0); } $ sudo ./wheres-the-ram.c Success ! $ free -g total used free shared buff/cache available Mem: 14 1 5 0 7 13 Swap: 0 0 0 $
        dullgiulio 8y ago
        Never seen someone "execute C" before. You are never done learning apparently obvious things...
        riking 8y ago
        The canonical shebang line to do this is '/usr/bin/tcc -r' - the Tiny C Compiler in "run" mode.

rkeene2 8y ago

But since the memory is never actually backed by anything, it doesn't have a real effect except in the accounting of the process. No additional memory is used by locking it.

wolfgang42 8y ago
Doesn't "guaranteed to be resident in RAM" mean the memory gets backing?
- rkeene2 8y ago
  No, because the pages aren't mapped to anything -- not disk, RAM, or an external paging device. Allocating a chunk of memory typically doesn't map those pages to anything immediately (since there's no benefit to doing that extra work). The current Linux man page gives a bit more insight: mlockall() and munlockall() mlockall() locks all pages mapped into the address space of the calling process. This includes the pages of the code, data and stack segment, as well as shared libraries, user space kernel data, shared memory, and memory-mapped files. All mapped pages are guaranteed to be resident in RAM when the call returns successfully; the pages are guaranteed to stay in RAM until later unlocked. The flags argument is con‐ structed as the bitwise OR of one or more of the following constants: MCL_CURRENT Lock all pages which are currently mapped into the address space of the process. MCL_FUTURE Lock all pages which will become mapped into the address space of the process in the future. These could be, for instance, new pages required by a grow‐ ing heap and stack as well as new mem‐ ory-mapped files or shared memory regions.
  - wolfgang42 8y ago
    Ah, I see--it's all mapped pages, not all pages as irishsultan's comment says. That makes a lot more sense, thanks!
    - rkeene2 8y ago
      After some experimenting it will fault all the mapped pages, causing the VM subsystem to try to back them. In Linux 4.4+ there is an a flag to `mlockall(2)` called "MCL_ONFAULT" which does not do that and instead locks the pages as they become backed. $ cat wheres-the-ram.c #! /home/rkeene/bin/c #include <sys/mman.h> #include <stdlib.h> #include <stdio.h> int main(int argc, char **argv) { unsigned char *buffer; int mla_ret; mla_ret = mlockall(MCL_CURRENT | MCL_FUTURE | MCL_ONFAULT); if (mla_ret != 0) { perror("mlockall"); return(1); } buffer = malloc(1024LLU * 1024LLU * 1024LLU * 32LLU); if (!buffer) { perror("malloc"); return(1); } buffer[0] = 1; buffer[1] = buffer[0]; buffer[2] = buffer[3]; puts("Success !"); return(0); } $ sudo ./wheres-the-ram.c Success ! $ free -g total used free shared buff/cache available Mem: 14 1 5 0 7 13 Swap: 0 0 0 $
      - dullgiulio 8y ago
        Never seen someone "execute C" before. You are never done learning apparently obvious things...
        riking 8y ago
        The canonical shebang line to do this is '/usr/bin/tcc -r' - the Tiny C Compiler in "run" mode.