<html lang="en">
<head>
<title>Locked Memory Details - The GNU C Library</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name="description" content="The GNU C Library">
<meta name="generator" content="makeinfo 4.13">
<link title="Top" rel="start" href="index.html#Top">
<link rel="up" href="Locking-Pages.html#Locking-Pages" title="Locking Pages">
<link rel="prev" href="Why-Lock-Pages.html#Why-Lock-Pages" title="Why Lock Pages">
<link rel="next" href="Page-Lock-Functions.html#Page-Lock-Functions" title="Page Lock Functions">
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
<!--
This file documents the GNU C library.

This is Edition 0.12, last updated 2007-10-27,
of `The GNU C Library Reference Manual', for version
2.8 (Sourcery G++ Lite 2011.03-41).

Copyright (C) 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2001, 2002,
2003, 2007, 2008, 2010 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with the
Invariant Sections being ``Free Software Needs Free Documentation''
and ``GNU Lesser General Public License'', the Front-Cover texts being
``A GNU Manual'', and with the Back-Cover Texts as in (a) below.  A
copy of the license is included in the section entitled "GNU Free
Documentation License".

(a) The FSF's Back-Cover Text is: ``You have the freedom to
copy and modify this GNU manual.  Buying copies from the FSF
supports it in developing GNU and promoting software freedom.''-->
<meta http-equiv="Content-Style-Type" content="text/css">
<style type="text/css"><!--
  pre.display { font-family:inherit }
  pre.format  { font-family:inherit }
  pre.smalldisplay { font-family:inherit; font-size:smaller }
  pre.smallformat  { font-family:inherit; font-size:smaller }
  pre.smallexample { font-size:smaller }
  pre.smalllisp    { font-size:smaller }
  span.sc    { font-variant:small-caps }
  span.roman { font-family:serif; font-weight:normal; } 
  span.sansserif { font-family:sans-serif; font-weight:normal; } 
--></style>
<link rel="stylesheet" type="text/css" href="../cs.css">
</head>
<body>
<div class="node">
<a name="Locked-Memory-Details"></a>
<p>
Next:&nbsp;<a rel="next" accesskey="n" href="Page-Lock-Functions.html#Page-Lock-Functions">Page Lock Functions</a>,
Previous:&nbsp;<a rel="previous" accesskey="p" href="Why-Lock-Pages.html#Why-Lock-Pages">Why Lock Pages</a>,
Up:&nbsp;<a rel="up" accesskey="u" href="Locking-Pages.html#Locking-Pages">Locking Pages</a>
<hr>
</div>

<h4 class="subsection">3.4.2 Locked Memory Details</h4>

<p>A memory lock is associated with a virtual page, not a real frame.  The
paging rule is: If a frame backs at least one locked page, don't page it
out.

   <p>Memory locks do not stack.  I.e., you can't lock a particular page twice
so that it has to be unlocked twice before it is truly unlocked.  It is
either locked or it isn't.

   <p>A memory lock persists until the process that owns the memory explicitly
unlocks it.  (But process termination and exec cause the virtual memory
to cease to exist, which you might say means it isn't locked any more).

   <p>Memory locks are not inherited by child processes.  (But note that on a
modern Unix system, immediately after a fork, the parent's and the
child's virtual address space are backed by the same real page frames,
so the child enjoys the parent's locks).  See <a href="Creating-a-Process.html#Creating-a-Process">Creating a Process</a>.

   <p>Because of its ability to impact other processes, only the superuser can
lock a page.  Any process can unlock its own page.

   <p>The system sets limits on the amount of memory a process can have locked
and the amount of real memory it can have dedicated to it.  See <a href="Limits-on-Resources.html#Limits-on-Resources">Limits on Resources</a>.

   <p>In Linux, locked pages aren't as locked as you might think. 
Two virtual pages that are not shared memory can nonetheless be backed
by the same real frame.  The kernel does this in the name of efficiency
when it knows both virtual pages contain identical data, and does it
even if one or both of the virtual pages are locked.

   <p>But when a process modifies one of those pages, the kernel must get it a
separate frame and fill it with the page's data.  This is known as a
<dfn>copy-on-write page fault</dfn>.  It takes a small amount of time and in
a pathological case, getting that frame may require I/O. 
<a name="index-copy_002don_002dwrite-page-fault-357"></a><a name="index-page-fault_002c-copy_002don_002dwrite-358"></a>
To make sure this doesn't happen to your program, don't just lock the
pages.  Write to them as well, unless you know you won't write to them
ever.  And to make sure you have pre-allocated frames for your stack,
enter a scope that declares a C automatic variable larger than the
maximum stack size you will need, set it to something, then return from
its scope.

   </body></html>