Lazy Swap Reservation |
 |
Runtime environments in which multiple processes map large
private data regions into their address spaces will put an exorbitant
demand on a system's swap resources. It can be demonstrated that
in such environments the swap pool becomes inefficiently utilized.
The Lazy Swap Reservation (SWLZY) feature means that a swap
reservation for a process-private page is deferred until the process
actually attempts to modify the page (i.e. copy-on-write is broken).
Essentially, for Lazy Swap private regions, swap resources are used
only for dirtied private pages (which really require swap backing-store
in the event of a possible page-out).
Although a SWLZY process more efficiently utilizes swap resources
by not reserving swap for all private pages at either exec(2)
or fork(2)
time, a process may receive an unexpected SIGBUS signal at run time
as a result of a failed attempt at making a swap reservation. Consequently,
a discerning program must be written to handle the SIGBUS signal
and invoke appropriate recovery steps. These steps may include a
limited retry, a check-pointing of any significant or volatile data,
or simply exiting.
SWLZY Flag |
|
When loading an executable file, exec(2) service now recognizes the
SWLZY program attribute by testing defined flags in the a.out
file. Both SOM and ELF executables have been enhanced to support
a program attribute flag specifying that any statically or dynamically
allocated private data region must be lazily evaluated in regards
to swap space reservation (excludes stack segment in this implementation).
The chatr(1)
command has been enhanced to provide the +z enable
command-line switch to generate a Lazy Swap executable. From a user's
perspective, the convenience in using the chatr(1) utility lies in the fact
that an existing executable would not have to be rebuilt as would
be the case with a cc(1) or ld(1)
flag. The SWLZY flag can only be applied to a program's a.out
file and can not be applied to a shared library file. This means
that there is no change to the underlying VM management of shared
library regions. In the case of a SWLZY process, the associated
private data region(s) created when the library is dynamically linked
will be lazily evaluated.
mmap(2) MAP_NORESERVE |
|
HP-UX mmap(2) has been enhanced to support
a MAP_NORESERVE flag for requesting that swap reservations be lazily
evaluated for the mapping. Contrasting the default case (i.e. without
this flag), where successful execution of a MAP_PRIVATE mapping
requires that swap space equal to the size of the mapping be reserved,
the MAP_NORESERVE flag is used. The success of the first attempted
write to a mapped page depends on the deferred reservation and the
current availability of swap resources. If the swap reservation
for the page can be made successfully (the expected case), the write
will succeed and a private copy of the written page is created.
Conversely, if swap space is not available at that time, the write
fails and a SIGBUS signal is delivered to the writing process.
If a SWLZY process (as described above) executes a mmap(2)
request with MAP_PRIVATE, whether or not MAP_NORESERVE is specified,
the process will use lazily evaluated swap. In short, SWLZY processes
which map MAP_PRIVATE always set MAP_NORESERVE behavior.
Printable version
