hp-ux / virtual memory May 2003 Adaptive Address Space technical white paper table of contents introduction executive summary background limitations of traditional HP-UX address space models what does MPAS provide? larger, more homogeneous address space mmap independence multiple mmap()s of the same data preffered address for shmat() how to get MPAS? usage details alternatives to MPAS performance compatibility/ interoperability configuration glossary (simplified) for more information 2 2 3 6 7 7 9 9 9
Adaptive Address Space introduction The Adaptive Address Space (AAS) feature is introduced in HP-UX 11i V2. AAS provides a new address space layout, MPAS (Mostly Private Address Space), which helps applications targeted for HP-UX running on Intel® Itanium ® Processor Family (IPF) machines. MPAS can also be used to aid application portability to HP-UX. This paper describes the features AAS provides, how applications can use these features and impacts thereof.
Adaptive Address Space background HP-UX provides various address space layouts for applications to choose from. An address space layout represents a process’s accessible virtual address space and how the operating system divides it into different regions into which different types of memory objects can be attached. The default address space layout for 32-bit processes is known as SHAREMAGIC. In this layout, the first 1GB of the process’s address space is reserved exclusively for text.
0xFFFF FFFF (quadrants 2 and 3) is consumed by most 32-bit processes in the system. For example, if processes A and B want to share 1MB of data, they will use this space to share it (the kernel will pick a virtual address in this range). This 1MB data may not be visible to process C, but the data will consume 1MB of virtual address space that process C could have used. Processes A and B will access the data using the same virtual address – hence they will read / write the same data.
bit process is shown below. This type of layout is called MGAS (for Mostly Global Address Space). The layout is: (The diagram shows a 64-bit MGAS process on IPF. Note, the figure is not drawn to scale. The maximum stack sizes are decided by system tunables and process resource limits at the time of process start-up). For a 64-bit process, text can occupy up to 1 octant. This entire octant is not available to the application for any other use.
virtual address space for 64-bit MGAS processes lies in octants 0,1 and 6. The layout for a 64-bit process on PA-RISC is significantly different and is not shown here. limitations of traditional HP UX address space models The traditional address space layouts of HP-UX suffered from the following limitations: 1. On HP-UX, processes have a fixed distribution of the processes’ virtual address space into ‘shared’ address space and ‘private’ address space (i.e.
what does MPAS provide? The MPAS layout provides the following features: larger, more homogeneous address space The address space layout for 32-bit MPAS processes looks like: (Note that the figure is not drawn to scale. The maximum stack sizes are decided based on system tunables and process resource limits at the time of process start up). In this layout the entire 4GB, i.e. all 4 quadrants, are available for the process to consume in any manner it chooses.
The layout for 64-bit MPAS processes is shown below: (Note that the figure is not drawn to scale. The maximum stack sizes are decided based on system tunables and process resource limits at the time of process start up). For 64-bit MPAS processes, text can occupy one entire octant of address space. This octant is not available to the process for any other use. All processes running the same binary use share the text using the same virtual address – without need for aliasing virtual addresses.
mmap independence For MPAS processes, mmap() calls made by this process are independent of calls made by any other process. In the case cited earlier in the section “limitations of traditional HP-UX address space models”, item number 5, process B could not mmap() pages 1 and 2 of a file because another process A had mmap()ed page 1. This, and all such inter-process limitations are removed for MPAS processes.
the maxdsiz tunable appropriately, and ensure that enough swap is available. Similar constraints apply if other types of large objects are desired – e.g. if a large stack was needed, then the maxssiz tunable and the RLIMIT_STACK limit would have to be adjusted instead of the maxdsiz tunable and RLIMIT_AS limit respectively. The man page for setrlimit(2) is a good starting point for information on resource limits.
4. The MAP_GLOBAL and MAP_ADDR32 flags of mmap(2) behave differently for MPAS and non-MPAS processes. MAP_GLOBAL MAP_ADDR32 MAP_ADDR32|MAP_GLOBAL 32-bit MPAS No effect No effect No effect 32-bit, nonMPAS Goes to 4th quadrant No effect Same as MAP_GLOBAL 64-bit MPAS Goes to 6th Octant No effect Same as MAP_GLOBAL 64-bit, nonMPAS Goes to 6th Octant Goes to Goes to virtual address virtual between 3GB and 4GB address <4GB 5. MPAS processes attach shared library text in private address space.
alternatives to MPAS Reasons for not using the MPAS layout could include: 1. Application is targeted for the PA-RISC architecture. 2. Application is targeted for a version of HP-UX preceding HP-UX 11i V2. 3. Application vendor wants to retain performance advantages provided to non-MPAS applications. Applications that cannot use MPAS can get some of the advantages that MPAS layouts provide by choosing one of several address space layouts provided by HP-UX as described earlier.
glossary (simplified) AAS: Adaptive Address Space. The feature being discussed in this paper. Aliasing: In this paper, aliasing refers to the condition when two or more unique virtual addresses translate to the same physical address. All aliased virtual addresses can be used to access the same data. BSS: Block Started by Symbol. The section of a program’s data which is used to store global data that is not initialized explicitly by the programmer. (Implicitly initialized to 0).
• setrlimit(2) • maxdsiz(5) • maxssiz(5) Intel® Itanium ® Processor Family is a trademark of Intel Corporation in the US and other countries and is used under license. Solaris® is a registered trademark of Sun Microsystems, Inc. Linux® is a registered trademark of Linus Torvalds. HP-UX and PA-RISC are registered trademarks of Hewlett-Packard company. The information in this document is subject to change without notice. © Copyright Hewlett-Packard Company 2003 05/2003 Publication number 1.
