I assume this is referring to some mechanism like `mlockall(2)` or using cgroups to disable using paging. Is the "excess" memory dirtied ? It's not clear why having the pages mapped but unaccessed entirely would cause a performance issue.
> 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.
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. $ 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
$