Swap space - The Answer

Bill Maltby - LFS Related lfsbill at wlmcs.com
Tue Nov 12 02:59:42 PST 2002

On Tue, 12 Nov 2002, Richard Lightman wrote:

>* Dan Osterrath <do3 at mail.inf.tu-dresden.de> [2002-11-12 08:00]:
>> Another example:
>> Program x is executed and modifies its own code in memory. (For example there 
>> is a counter in the code segment.) When it is swapped and re-read the counter 
>> would be set to the initial value.
>Code is loaded from the filesystem, and mapped as shared, read only.
>When you try to write to it, you will get a different mapping that
>is not shared, but is rw. This mapping can get swapped out and read
>back from swap. Tasks that have not modified the code can continue
>to use the other mapping that is backed by the filesystem.

I think that is correct. IIRC, the VM subsystem has a basic copy-on-write
policy for shared pages. So when a process that is using a shared page is
going to modify that page (which is tagged read-only), an interrupt is
generated, the unmodified page is copied and operation (modification of
the page) is resumed. The second copy is flagged as a  "dirty" (modified)
page and the system knows it can not be restored from the executable.

I think this holds for both code and data, although code can not be easily
modified by user-space processes on a real OS (one needs to keep previous
DOS/Win experience in perspective). On *IX (Intel-based) systems, there
are three components in an executable. Text, data and bss. Text = code =
not modifiable by user (IIRC - don't take my word); data =
constant literals = not modifiable (same caveat); bss = I-can-never-
remember-what-it-stands-for-but-I-think-its-the-heap = modifiable memory.

All based on memories long unused, so please correct me if I have


Bill Maltby
billm at wlmcs.com

Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-support' in the subject header of the message

More information about the lfs-support mailing list