Page 431 - DCAP103_Principle of operating system

Principles of Operating Systems

Notes 14.4.2 Memory Management System Calls in Linux
POSIX does not specify any system calls for memory management. This topic was considered
too machine dependent for standardization. Instead, the problem was swept under the rug
by saying that programs needing dynamic memory management can use the malloc library
procedure (defined by the ANSI C standard). How malloc is implemented is thus moved outside
the scope of the POSIX standard. In some circles, this approach is known as passing the buck.
In practice, most Linux systems have system calls for managing memory. The most common
ones are listed in Figure 14.14. Brk specifies the size of the data segment by giving the address of
the first byte beyond it. If the new value is greater than the old one, the data segment becomes
larger; otherwise it shrinks.

Figure 14.14: Some System Calls Relating to Memory Management

System call Description
s = brk(addr) Change data segment size
a = mmap(addr, len, prot, flags, fd, offset) Map a file in
s = unmap(addr, len) Unmap a file

The return code s is ~1 if an error has occurred; a and addr are memory addresses, len is a
length, prot controls protection, flags are miscellaneous bits, fd is a file descriptor, and offset
is a file offset. The mmap and munmap system calls control memory-mapped files. The first
parameter to mmap, addr, determines the address at which the file (or portion thereof) is
mapped. It must be a multiple of the page size. If this parameter is 0, the system determines the
address itself and returns it in a. The second parameter, len, tells how many bytes to map. It,
too, must be a multiple of the page size. The third parameter, prot, determines the protection for
the mapped file. It can be marked readable, writable, executable, or some combination of these.
The fourth parameter, flags, controls whether the file is private or sharable, and whether addr
is a requirement or merely a hint. The fifth parameter, fd, is the file descriptor for the file to be
mapped. Only open files can be mapped, so to map a file in, it must first be opened. Finally,
offset tells where in the file to begin the mapping. It is not necessary to start the mapping at
byte 0; any page boundary will do. The other call, unmap, removes a a mapped file. If only a
portion of the file is unmapped, the rest remains mapped.
14.4.3 Implementation of Memory Management in Linux

Each Linux process on a 32 bit machine typically gets 3 GB of virtual address space for itself,
with the remaining 1 GB reserved for its page tables and other kernel data. The kernel’s 1 GB
is not visible when running in user mode, but becomes accessible when the process traps into
the kernel. The kernel memory typically resides in low physical memory, however it is mapped
in the top 1 GB of each process virtual address space, between addresses 0×C0000000 and
0×FFFFFFFF (3-4 GB). The address space is created when the process is created and is
overwritten on an exec system call.

In order to allow multiple processes to share the underlying physical memory Linux monitors
the use of the physical memory, allocates more memory as needed by user processes or kernel
components, dynamically maps portions of the physical memory into the address space of
different processes, and dynamically brings in and out of memory program executables, files
and other state, necessary to utilize the platform resources efficiently and to ensure execution
progress. The remainder of this unit describes the implementation of various mechanisms in
the Linux kernel which are responsible for these operations.

424 LOVELY PROFESSIONAL UNIVERSITY