Memory Windows

   

The memory windowing system was introduced to HP-UX 11.0 as a patch (PHKL_13810 and PHCO_13811) and is part of the HP-UX 11.i release. Figure 5-6 shows a greatly simplified example of a system VAS with memory windows implemented. To enable memory windows on a system, the kernel-tunable parameter max_mem_window must be set to the desired number of user windows. The kernel adds 1 to this value and initializes a memory-window array structure during system boot.

Figure 5-6. SHARE_MAGIC and Memory Windows

graphics/05fig06.gif


NOTE

Memory windows may only be implemented for 32-bit narrow application memory mapping.


The kernel pointer *memWindows directs us to an array of individual window data structures of type vas_window. Let's take a look at this structure in Listing 5.3.

Listing 5.3. q4> fields struct vas_window
 The first three fields are used to map quadrant Q2  (in the case of SHMEM_MAGIC)  0 0 4 0 u_int q2_32bitSpaceid  4 0 4 0 u_int q2_32bitSpaceidInitial  8 0 4 0 *     q2_32bitMap The next two fields are used to map quadrant Q3 12 0 4 0 u_int q3_32bitSpaceid 16 0 4 0 *     q3_32bitMap The "key" is required to join a window 20 0 4 0 int   key This keeps track of how many processes are currently using the  window. 24 0 4 0 int   refCnt This value keeps track of the last process to join the window  (useful in debugging) 28 0 4 0 int   lastSetpid 

The first window in the array is reserved as the global window. Its Q3 (and Q2) space IDs are the system defaults used by all processes that do not request a specific memory window assignment.

The second window is reserved for q3_private process usage (coming up next in our discussion). The rest of the windows may be requested by system call or user command, up to the configured limit.

There are two mechanisms by which a process may join a window: pure inheritance refers to a child of a process that has inherited its window association from its parent; key associative refers to a process that has either made the _set_mem_window() system call or has had the setmemwindow user command issued on its behalf.

Fundamentally, when a process joins a memory window, its Q3 (and Q2 for SHMEM_MAGIC processes) space ID is obtained from the appropriate vas_window array element. You may have noticed the *q2_32bitMap and *q3_32bitMap pointers in the vas_window structure. These point to resource maps used to managed availability of address ranges within the window quadrants. The kernel must keep track of which areas of a quadrant are in use and which are free so that space may be allocated to handle requests from new processes. The resource map approach was covered in Chapter 3, "The Kernel: Basic Organization."

One thing to note is that on a system with memory windows enabled, the basic algorithm for allocation of shared objects is modified slightly. Since there is only one truly global quadrant now (Q4) and it is slightly less than 75 percent available (remember the gateway page and the 256 MB of I/O space mapped here), shared library space comes at a slightly higher premium.

For a non-memory windowed system, the allocation routine for shared objects is as follows:

  1. Try finding space for the object in Q4 (regardless of object type).

  2. If step 1 fails, then look in Q3 (and then in Q2 for SHMEM_MAGIC).

  3. If step 2 fails, then return an error.

For a memory window-enabled system, the new routine is as follows:

  1. If the object is a shared library, try to put it in Q4; if no room in Q4, then try Q3 (or Q2 for SHMEM_MAGIC).

  2. If it isn't a shared library, then place it in Q3 (or in Q2 for SHMEM_MAGIC).

  3. If step 2 fails, then place it in Q4.

  4. If step 3 fails, then return an error.

The policy used by the kernel is controlled by allocAddrPolicy, which is in turn set according to the value of max_mem_window. (If max_mem_window = 0, memory windows are disabled and we use the first policy; if max_mem_window != 0, memory windows are enabled and we use the second policy.) In addition to the tunable parameter, the kernel parameter maxMemWindow is maintained and set to max_mem_window plus 1 (this allows space for the second q3_private window).

To use q4 to monitor memory window usage,

 

q4> load struct vas_window from memWindows max maxMemWindow

 

q4> prinrfrt -tx key refCnt


We have mentioned the term q3_private a couple of times now we look at this new option.

Q3 Private Address Space

With the release of patch PHKL_20224 for HP-UX 11.0 and on subsequent releases, 32-bit narrow applications running under control of a 64-bit wide kernel on 64-bit PA-RISC 2.0 hardware have an additional mapping option available to them (a 32-bit kernel will simply ignore this request for large private data). Figure 5-7 illustrates the basics of this option.

Figure 5-7. Q3 Private Address Space

graphics/05fig07.gif


The classic narrow process map reserves Q3 and Q4 for shared objects, but what if the process needs an extraordinary amount of private data space? As there is a hard limit of four quadrants, the only way to increase a process's private data space comes at the expense of its ability to access system-shared space.

To implement this new feature requires the use of the chattr command-line utility. Two new options have been added to chattr: +q3p <enable/disable> <process-name> and +q4p <enable/disable> <process-name>. Before either of these commands may be issued, the kernel must be tuned to allow the new, larger private data size, which is accomplished by tuning the age-old parameter maxdsiz.

Several other stipulations apply to a q3_private process. Such processes cannot share objects not created by another q3_private process even in Q4 unless the objects were created by a non-q3-private process using the IPC_GLOBAL or MAP_GLOBAL flags, which may require a recompile. If a recompile is not an option, then all processes needing to share objects in Q4 will simply need to be made into q3_private processes (chattr +q3p enable <process-name>).

In a limited number of extreme cases, you may wish to extend the process's private data space even farther. This may be done (but only with extreme caution and need!) by invoking the +q4p option with chattr. The use of +q4p presupposes the implementation of the +q3p rules. This is an extreme decision, as a process running in this mode will have access to no shared objects whatsoever (with exception to the I/O space and the gateway page).

Note that the space IDs for the extended data spaces are identical. In effect, this means that the logical data size may exceed the previous limits. While this does bring some relief, all is not skittles and beer here. The fixed placement of the gateway page means that even with +q4P invoked, a singular data object may not extend past the beginning of the fourth quadrant. In order to use the additional space in Q4, the process must make private memory map calls using mmap(MAP_PRIVATE) or malloc(), which has been modified to address this limit.

As an observation, if you need to utilize these types of options to make your process fit into the 32-bit narrow environment, perhaps your process is trying to tell you something like, "I need to be a 64-bit wide process!"



HP-UX 11i Internals
HP-UX 11i Internals
ISBN: 0130328618
EAN: 2147483647
Year: 2006
Pages: 167

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net