Memory Management Under Linux (SAP Library - SAP Memory Management (BC-CST-MM))

Memory Management Under Linux

How you implement memory management under Linux depends on the release and patch level of the SAP kernel, and the Linux version.

Address Space of a Process Under Linux

The following graphic shows the structure of the address space on a Linux/ELF system. This applies to Linux kernel versions 2.0,.2.2, and 2.4.

This graphic is explained in the accompanying text

Every 32-bit architecture limits the addressable memory to 4 GB.

The upper quarter of the virtual address space is reserved for the Linux kernel.

Shared libraries, such as glibc, are stored at 1 GB and higher. You have to take these into account when calculating the free address space. ("Free" in this context means that shared memory and memory mapped files can be created.)

You can use the process number <pid> to monitor the virtual address space of a running process. To do this, evaluate the file /proc/<pid>/maps.

SAP uses the MMAP/SHM areas for its buffers and user contexts that are stored in the SAP extended memory. Usually, this area has a size of ca. 2 GB.

Implementing Memory Management under Linux

There are two implementations of the SAP extended memory for Linux. Which one you use depends mainly on the Linux kernel you are using.

"Classical" Implementation

In the "classical" memory management implementation – as with Implementing Memory Management (UNIX) – all user contexts are visible in the virtual address space of a work process (see also Implementing Extended Memory under UNIX). On the 32-bit Intel architecture, this has the disadvantage that only 1 – 1.2 GB are available for the extended memory of all user contexts.

This graphic is explained in the accompanying text

New "Zero Admin" Implementation

In the new implementation – just like with Implementing Extended Memory under Windows – only the current user context is visible in the address space. In other words, the 1 – 1.2 GB can be used by one user context, and the total size can be much greater. The extended memory (that is, all user contexts that are not currently in use) is completely contained in the EM backing store of the instance. This capacity is therefore only limited by the available main memory and swap space.

This graphic is explained in the accompanying text

When created, the EM backing store has the size specified in em/initial_size_MB, and is then dynamically extended to a maximum size (em/max_size_MB).

So, in the new implementation, the parameter em/initial_size_MB only specifies the initial size of the EM backing store. The parameter em/address_space specifies how much extended memory a user context gets.

The section Old or New Memory Management? describes when to use which implementation of the memory management function.