ReviewEssays.com - Term Papers, Book Reports, Research Papers and College Essays
Search

4quadrant Hp-Ux Memory Issue

Essay by   •  December 21, 2010  •  Research Paper  •  4,894 Words (20 Pages)  •  2,349 Views

Essay Preview: 4quadrant Hp-Ux Memory Issue

Report this essay
Page 1 of 20

Memory Windows in HP-UX 11.0. White Paper

page 1

Memory Windows

White Paper

1. Objectives

HP-UX release 11.0 is the first to support the new HP V-class machine. Targeted for high end OLTP, decision

support, server consolidation and ERP, the V-class can support up to 16 gigabytes of physical memory.

The current 32-bit virtual address space of HP-UX is limiting applications from taking full advantage of

systems with a large amount of physical memory.

Not all of HP's software providers have ported their applications to 64-bits, nor is it necessary in all cases.

But HP-UX has limitations for shared resources on 32-bit applications. All applications in the system are

limited to a total of 1.75 gigabytes of global space(shared memory), 2.75 gigabytes if compiled, linked as

EXEC_MAGIC and chatr'd as SHMEM_MAGIC. In a system with 16 gigabytes of physical memory, only

1.75 can be used for shared resources such as shared memory.

To address this limitation a functional change has been made to the 11.00 release of HP-UX. The patch

allows 32-bit processes to create unique memory windows for shared objects like shared memory. There

are three types of executables in HP-UX. Their layout *WITHOUT* memory windows is the following:

The default HP-UX memory management is based on quadrants where each process has its own space.

The process text (executable code) is mapped to quadrant 1 and its private data is mapped to quadrant 2

in its individual space. Quadrant one and two exists n times (once for each process). All shared objects are

mapped to quadrant 3 and 4 (and quad 2 for SHMEM_MAGIC) of one single space shared by all processes.

This is where the system wide limit of 1.75 Gb's comes from. Each quadrant is 1gigabyte in size.

Program Text

1 Gigabyte

(quadrant 1)

Program Data

1 Gigabyte

(quadrant 2)

Global Space

1 Gigabyte

(quadrant 3)

Global Space

.75 Gigabyte

(quadrant 4)

Program Text & Data

1 Gigabyte

(quadrant 1)

Program Data

1 Gigabyte

(quadrant 2)

Global Space

1 Gigabyte

(quadrant 3)

Global Space

.75 Gigabyte

(quadrant 4)

Program Text & Data

1 Gigabyte

(quadrant 1)

Global Space

1 Gigabyte

(quadrant 2)

Global Space

1 Gigabyte

(quadrant 3)

Global Space

.75 Gigabyte

(quadrant 4)

SHARE_MAGIC

(default)

EXEC_MAGIC SHMEM_MAGIC

Memory Windows in HP-UX 11.0 White Paper

page 2

The 4th quadrant is only .75 gigabytes in size because the last 1/4 of the quadrant is reserved for architected

I/O space.

By default all executables are SHARE_MAGIC, the default mode. EXEC_MAGIC and SHMEM_MAGIC

require special binaries.

If no special options are given to the compiler/linker, the default executable format is SHARE_MAGIC. Text

is shared for all copies running on the system and data is private. EXEC_MAGIC is the output of using the

-N option to the linker. It results in the data starting immediately after the text allowing for a greater sized

data space (approximately 1.9 Gb's). SHMEM_MAGIC combines all the pieces of a process into the first

quadrant (text, data, and stack). SHMEM_MAGIC was done at a time when only 32-bit kernels were supported.

Applications requiring more than 1.75 Gb's of shared space should recompile as 64-bit and then

memory windows is not needed.

Unless otherwise noted, the remainder of this paper assumes the default executable format of

SHARE_MAGIC.

Memory windows allows each process to define a unique global space of up to 1 gigabyte of shared memory.

Shared memory segments placed in the unique space can only be accessed by processes in the

same memory window. But different applications, or distinct instances of a single application, can be

placed in different memory windows and consume more of the available physical memory within the system.

Memory windows extends system wide virtual capacity for 32-bit applications only. By extending the virtual

capacity, more of the underlying physical memory can be used for shared objects. Without memory

windows

...

...

Download as:   txt (32.6 Kb)   pdf (317.2 Kb)   docx (24.5 Kb)  
Continue for 19 more pages »
Only available on ReviewEssays.com