 |
» |
|
|
|
|  | |
Running without memory windows, HP-UX has limitations for
shared resources on 32-bit applications. All applications in the
system are limited to a total of 1.75 GB of shared memory, 2.75
GBif compiled as SHMEM_MAGIC.
In a system with 16 tes of physical memory, only 1.75 can be used
for shared resources. To address this limitation, a functional change has been made
to allow 32-bit processes to create unique memory windows for shared
objects like shared memory. The memory window for default executables is 1 GB. This allows cooperating applications to create one GB of shared
resources without exhausting the system-wide resource. Part of the
virtual address space remains globally visible to all processes,
so that shared libraries are accessible no matter what memory window
they are in. Summary of Change | |
The following customer-visible changes have been made for
memory windows: New kernel tunable to configure the
number of memory windows a system can have.
New set of commands and files (setmemwindow,
getmemwindow, /etc/services.window)
to start applications in different memory windows.
Manpages for the new functionality
have been created; they are getmemwindow(1M), setmemwindow(1M), and services.window(4).
How to Use Memory Windows | |
A process joins a memory window by using the setmemwindow
command. A process can associate with a memory window in one of
two ways: Pure Inheritance. Only the parent
process and its children share the window. No other processes in
the system can attach to the memory window. The memory window remains
active until the process, its children, and all objects created
in that window are no longer in use. A process creates a private window by not specifying a window
ID to the setmemwindow command.
Key Associative. A process creates
or joins a window associated with a particular key. Any process
can join this memory window as long as it specifies the proper key.
The window associated with the user key remains active until all
processes and all objects created in that window are no longer in
use. A process associates itself with a particular window by specifying
a user key(ID) to the setmemwindow
command.
The /etc/services.window File | |
/etc/services.window
is used only by Key Associative processes. A group of processes, intended for use by a common memory
window and not started by a common parent process, must associate
themselves with a unique key. The key allows separate processes
to select the same memory window and access (attach) to shared resources
in that memory window. The /etc/services.window
file provides a centrally located repository for user key IDs. It
serves to prevent applications from hard coding IDs in startup or
control scripts. (IDs might be embedded in control scripts and passed
directly to the setmemwindow
command, but conflicts between applications would be difficult to
find and correct.) IDs placed in a central repository can be easily
changed by the system administrator if two applications collide
on a user key. While it is easy to change user keys, it is more
difficult to change the associated string. Care must be taken in selecting a unique string for a particular
application or product. Either installation scripts or system administrators
can update/modify entries in this file. A sample /etc/services.window file # /etc/services.window format:
#
# Name <user_key>
application1 20
application2 30
application3 40 |
The getmemwindow Command | |
Given a name, getmemwindow
extracts the user key associated with name from the /etc/services.window
file. getmemwindow is used
only for key associative processes. Syntax: getmemwindow name Once a unique ID (key) is present in the /etc/services.window
file, application programs (such as startup scripts) can use getmemwindow
to extract that key and pass it to the setmemwindow
command. For example, the following lines of code start the executable program
with arg1 and arg2
in the memory window associated with the user key in $WinId: WinId = $(getmemwindow "application1")
setmemwindow -i $WinId Program arg1 arg2 .... |
The setmemwindow Command | |
setmemwindow starts a
particular process in a memory window. Syntax: setmemwindow [-i WindowID] [-ncjf] [-p pid] || program arg1 arg2 setmemwindow provides
the ability to change the memory window ID of a running process
or start a particular program in a memory window. program is used only if the process
ID's pid is either 0
or -p is
unspecified. If a pid is specified and the ID is non-zero, only
the desired window ID is changed in the process; program
is ignored. What does it mean to only change the ID? Setting the window
for a process does not mean a process immediately attaches or creates
objects in a memory window. The targeted process does not begin
using the specified window until it executes a new image. If a currently
running process is specified, the memory window is not changed until
that process executes. Any children created by that process inherit
the new window ID and when they execute the new window takes effect. setmemwindow is intended
as a wrapper for an existing executable: If setmemwindow
executes program, setmemwindow
waits until program finishes, by default.
If waiting is not desired, there is
the -n option to override the default wait behavior.
Options -i WindowID The value of WindowID is a key
to the desired memory window. WindowID
is user specified as a value contained in /etc/services.window.
Applications extract the user key from /etc/services.window
through the getmemwindow command. If the caller does not specify a window ID (that is, -i
is unspecified), the program is placed in a private memory window,
which is the first available memory window. Only children created
by the program have access to that memory window and no other process
can ever join the memory window. The value 0 is special. If 0 is specified, the process (program)
is placed into the default global window instead of a unique memory
window identified by WindowID.
By default, all processes are in the memory window 0. -p ProcessID Change the window in process ProcessId.
Only the desired window is changed. No program is executed, even
if one is specified. -c Create a window identified by WindowID
and attach the specified process to it. If a memory window corresponding
to WindowID already exists, the call
fails. -j Join an existing window identified by WindowID.
The specified process attaches to an existing memory window. If
no window with WindowID exists, the call
fails. If -c or -j is unspecified,
the process is placed in the memory window specified by WindowID,
by default. If no memory window exists with WindowID,
an unused window is allocated and associated with WindowID. -n If program is executed, the default behavior is to wait for
the process to terminate. -n causes setmemwindow
to return after starting program in the specified window. -f If -f is specified, setmemwindow
executes the defined program, even if unable to set the memory window.
This allows the caller to execute even though the process is not
in the desired memory window. The -f option allows
a script to start an application whether or not memory windows are
present or installed in the system. Example 3-1 Examples # Start a program and all its children in a private memory
# window
setmemwindow program arg1 arg
# Start a program in the memory window associated with user
# key "application1"
WinId=$(getmemwindow "application1")
setmemwindow -i $WinId program arg1 arg2
# Start a program in the memory window associated with user
# key "application1" and make sure this process is the first
# one to enter the memory window.
WinId=''''''''''''''''''''''''''''''''''''''''''''''''$(getmemwindow "application1")
setmemwindow -i $WinId -c program arg1 arg2 |
There is an unsupported command available to report the following
kinds of information: the memory window
of a shared memory segment what window a process is in the memory windows themselves
The command is called memwin_stats
and is available at: ftp://contrib:9unsupp8@hprc.external.hp.com/ Customers using memory windows should bear in mind the following
implications for other aspects of the HP-UX memory management subsystem: Processes must be in the same memory
window to share data. Processes wanting to share global data (such as shared memory
or MAP_SHARED memory
mapped files) must make sure all processes are in the same memory
window. If they are in separate memory windows, they will not be
able to map or attach to the data. Only processes in the same memory
window can access or attach to the data. Thus, if Process A is in memory window 1 and process B is
in memory window 2, any shared memory segments created by process
A cannot be accessed by process B. Child processes inherit memory window IDs. Child processes inherit their window IDs from their parent
process. In most cases this behavior is desired, but in some cases
it may be unexpected. A program in a non-default memory window may
fork and exec a system command, another application, or a utility,
leading the executed program to draw an incorrect assumption about
what memory window it is in. If this becomes a problem, an easy solution is available:
Place a wrapper around the failing executable using setmemwindow.
Using setmemwindow places the
executable in the required window. Most likely, this will be the
default or system global window; for example, setmemwindow -i 0 program arg1 arg2. Memory-mapped files. Memory mapped files are similar to shared memory segments.
If a common file is mapped by two different processes, then those
two processes should be in the same window. To guarantee mapping
of the file (MAP_SHARED),
all processes must be in the same memory window. Shared libraries mapped privately. Shared libraries are memory-mapped files. As such, a shared
library is mapped into the shared address space, just as a shared
memory segment. However, unlike a shared memory segment, a process
attaches itself to a shared library based on which libraries a process
needs. Different applications commonly share the same libraries,
such as libc. It is a premise of memory windowing that any process wishing
to share an object must occupy the same memory window space. If
two processes do not occupy the same memory window and wish to share
an object, the second process will fail. This behavior may be acceptable
for a cooperating application, but an application running in one
window should not affect a separate application running in a completely
different memory window. Rather than returning an error and failing the shared library
load, HP-UX handles shared libraries and memory windows in a special
way. If a shared library is mapped so that it occupies an address
apart from the globally visible address range, and a memory windowed
process attempts to load (that is, map) that library, the process
cannot map the library shared. Instead the library is mapped privately.
This poses some drawbacks; for instance, private memory mapped files
must allocate swap space. However, private mapping is likely to
be a rare condition. HP-UX prevents this from occurring in most
systems, by defaulting shared libraries into the globally visible
address range. Only if the globally visible address range is completely filled
are shared libraries mapped privately. Other than the swap space
consumption, mapping privately should have no effects on the processes
performance. POSIX message queues. POSIX message queues are built on a special form of shared
memory. Therefore, message queues are subject to the same constraints
as a memory mapped file. Only processes in the same memory window
can use or access the message queue. Use or access refers to the
sending and receiving of messages. Change in Policy allocation In previous HP-UX releases, the location policy for shared
objects (such as shared memory, memory-mapped files, shared libraries)
is as follows: First, try allocating an address from quadrant 4. If #1 fails, try allocating from quadrant 3. If #2 fails, return an error.
This policy is done to preserve the third quadrant for applications
needing large contiguous segments. However, a memory windowed application
would require that the shared data occupy the memory window space
(that is, quadrant 3). In a memory windowed system, the fourth quadrant
becomes a more precious resource for shared libraries. To reflect
the importance of preserving quadrant 4, memory windows change the
default location policy, as follows: If the object is a shared library, allocate it quadrant 4. If the object is not a shared library or the allocation
for a shared library failed in #1, try allocating from quadrant
3. If #2 fails, try allocating from quadrant 4.
Please note, the change in policy location occurs only if
memory windows are enabled in the system (that is, max_mem_window != 0).
Instead of shared memory addresses populating quadrant 4 first,
they will populate quadrant 3 first. This is not expected to cause
problems, since shared libraries default to quadrant 4 and shared
libraries are the common consumer of shared space.
By default, HP-UX ships with memory windows disabled. To enable memory windows, set the kernel tunable parameter
max_mem_window
to the desired amount. Customers can change this value by placing
the desired value in their kernel configuration file. The system
must be rebooted for the new value to take effect. max_mem_window
represents the number of memory windows beyond the global default
window. Setting max_mem_window
to one creates a single memory window to accompany the existing
global memory window, or a total of two memory windows one default
and one user-defined. Setting max_mem_window
to two produces a total of three memory windows the default and
two user-defined. Setting max_mem_window
to 0 leaves only one memory window, the default or global memory
window.
What should the value be? That depends on the application
requirements and the applications installed on the system. HP recommends
that each ISV/application should document how many windows it intends
to use. Use of memory windows does not affect the performance of processes.
There is no size requirement associated with memory windows. Any
machine running HP-UX (32-bit or 64-bit) and any hardware supporting
HP-UX release 11.0 can use memory windows. |
Printable version
