The man page for mlockall on my kernel 3.0 says
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.
and later says
Real-time processes that are using mlockall() to prevent delays on
page faults should reserve enough locked stack pages before entering
the time-critical section, so that no page fault can be caused by
function
calls. This can be achieved by calling a function that allocates a sufficiently large automatic variable (an array) and
writes to the memory occupied by this array in order to touch these
stack pages. This way,
enough pages will be mapped for the stack and can be locked into RAM. The dummy writes ensure that not even copy-on-write page
faults can occur in the critical section.
I understand that this system call can’t guess the maximum stack size that will be reached and thus is unable to lock pages for the stack. But why the first part of the man displayed above says that it’s also done for the stack ? Is there an error in this man page, or does it just mean that the locking is done for the initial stack size ?
Yes, locking is done for the current stack pages, but not for all possible future stack pages.