Recall that for a process to execute, all the regions (for
data, text, and so forth) have to be set up; yet pages are not loaded
into memory until the process demands them. Only when the actual
page is accessed is a translation established.
A compiled program has a header containing information on
the size of the data and code regions. As a process is created from
the compiled code by fork and exec, the kernel sets up the process's
data structures and the process starts executing its instructions
from user mode. When the process tries to access an address that
is not currently in main memory, a page fault occurs. (For example,
you might attempt to execute from a page not in memory.) The kernel
switches execution from user mode to kernel mode and tries to resolve
the page fault by locating the pregion containing
the sought-after virtual address. The kernel then uses the pregion's
offset and region to locate information needed for reading in the
page.
If the translation is not already present and the page is
required, the pdapage() routine
executes to add the translation (space ID, offset into the page,
protection ID and access permissions assigned the page, and logical
frame number of the page), and then on demand brings in that page
and sets up the translation, hashes in the table, and all the rest.
In main memory, the kernel also looks for a free physical
page in which to load the requested page. If no free page is available,
the system swaps or pages out selected used pages to make room for
the requested page. The kernel then retrieves (pages in) the required
page from file space on disk. It also often pages in additional
(adjacent) pages that the process might need.
Then the kernel sets up the page's permissions and
protections, and exits back to user mode. The process executes
the instruction again, this time finding the page and continuing
to execute.
The flexibility of demand paging lies in the fact that it
allows a process to be larger than physical memory. Its disadvantage
lies in the degree of complexity paging requires of the processor;
instructions must be restartable to handle page faults.
By default, all HP-UX processes are load-on-demand. A demand
paged process does not preload a program before it is executed.
The process code and data are stored on disk and loaded into physical
memory on demand in page increments. (Programs often contain routines
and code that are rarely accessed. For example, error handling
routines might constitute a large percentage of a program and yet
may never be accessed.)
copy-on-write |
 |
HP-UX now implements copy-on-write of EXEC_MAGIC
processes, to enable the system to manipulate processes more efficiently.
The system used to copy the entire data segment of a process every
time the process fork'd,
increasing fork time as the size
of the data and code segments increased. Only one translation of
a physical page is maintained; a parent process can point to and
read a physical page, but copies it only when writing on the page.
The child process does not have a page translation and must copy
the page for either read or write access.
Copy-on-write means that pages in the parent's region
are not copied to the child's region until needed. Both
parent and child can read the pages without being concerned about
sharing the same page. However, as soon as either parent or child
writes to the page, a new copy is written, so that the other process
retains the original view of the page.
For more information about the implementaton of EXEC_MAGIC,
see the HP-UX Process Management white paper.
