Because page faults cause paged out pages to be paged in transparently,
a process rarely needs to be concerned about locking pages. However,
there are two reasons people sometimes are:
Speed. A page fault is transparent only insofar as the process is not
sensitive to how long it takes to do a simple memory access. Time-critical
processes, especially realtime processes, may not be able to wait or
may not be able to tolerate variance in execution speed.
A process that needs to lock pages for this reason probably also needs
priority among other processes for use of the CPU. See Priority.
In some cases, the programmer knows better than the system's demand
paging allocator which pages should remain in real memory to optimize
system performance. In this case, locking pages can help.
Privacy. If you keep secrets in virtual memory and that virtual memory
gets paged out, that increases the chance that the secrets will get out.
If a password gets written out to disk swap space, for example, it might
still be there long after virtual and real memory have been wiped clean.
Be aware that when you lock a page, that's one fewer page frame that can
be used to back other virtual memory (by the same or other processes),
which can mean more page faults, which means the system runs more
slowly. In fact, if you lock enough memory, some programs may not be
able to run at all for lack of real memory.
Published under the terms of the GNU General Public License