Mapping Files into Memory

本为转载自：

https://www.safaribooksonline.com/library/view/linux-system-programming/0596009585/ch04s03.html

Mapping Files into Memory

As an alternative to standard file I/O, the kernel provides an interface that allows an application to map a file into memory, meaning that there is a one-to-one correspondence between a memory address and a word in the file. The programmer can then access the file directly through memory, identically to any other chunk of memory-resident data—it is even possible to allow writes to the memory region to transparently map back to the file on disk.

POSIX.1 standardizes—and Linux implements—the mmap( ) system call for mapping objects into memory. This section will discuss mmap( ) as it pertains to mapping files into memory to perform I/O; in Chapter 8, we will visit other applications of mmap( ).

mmap( )

A call to mmap( ) asks the kernel to map len bytes of the object represented by the file descriptor fd, starting at offset bytes into the file, into memory. If addr is included, it indicates a preference to use that starting address in memory. The access permissions are dictated by prot, and additional behavior can be given by flags:

#include <sys/mman.h>

void * mmap (void *addr,
             size_t len,
             int prot,
             int flags,
             int fd,
             off_t offset);

The addr parameter offers a suggestion to the kernel of where best to map the file. It is only a hint; most users pass 0. The call returns the actual address in memory where the mapping begins.

The prot parameter describes the desired memory protection of the mapping. It may be either PROT_NONE, in which case the pages in this mapping may not be accessed (making little sense!), or a bitwise OR of one or more of the following flags:

PROT_READ

The pages may be read.

PROT_WRITE

The pages may be written.

PROT_EXEC

The pages may be executed.

The desired memory protection must not conflict with the open mode of the file. For example, if the program opens the file read-only, prot must not specify PROT_WRITE.

Protection Flags, Architectures, and Security

While POSIX defines four protection bits (read, write, execute, and stay the heck away), some architectures support only a subset of these. It is common, for example, for a processor to not differentiate between the actions of reading and executing. In that case, the processor may have only a single "read" flag. On those systems, PROT_READ implies PROT_EXEC. Until recently, the x86 architecture was one such system.

Of course, relying on such behavior is not portable. Portable programs should always setPROT_EXEC if they intend to execute code in the mapping.

The reverse situation is one reason for the prevalence of buffer overflow attacks: even if a given mapping does not specify execution permission, the processor may allow execution anyway.

Recent x86 processors have introduced the NX (no-execute) bit, which allows for readable, but not executable, mappings. On these newer systems, PROT_READ no longer implies PROT_EXEC.

The flags argument describes the type of mapping, and some elements of its behavior. It is a bitwise OR of the following values:

MAP_FIXED

Instructs mmap( ) to treat addr as a requirement, not a hint. If the kernel is unable to place the mapping at the given address, the call fails. If the address and length parameters overlap an existing mapping, the overlapped pages are discarded and replaced by the new mapping. As this option requires intimate knowledge of the process address space, it is nonportable, and its use is discouraged.

MAP_PRIVATE

States that the mapping is not shared. The file is mapped copy-on-write, and any changes made in memory by this process are not reflected in the actual file, or in the mappings of other processes.

MAP_SHARED

Shares the mapping with all other processes that map this same file. Writing into the mapping is equivalent to writing to the file. Reads from the mapping will reflect the writes of other processes.

Either MAP_SHARED or MAP_PRIVATE must be specified, but not both. Other, more advanced flags are discussed in Chapter 8.

When you map a file descriptor, the file's reference count is incremented. Therefore, you can close the file descriptor after mapping the file, and your process will still have access to it. The corresponding decrement of the file's reference count will occur when you unmap the file, or when the process terminates.

As an example, the following snippet maps the file backed by fd, beginning with its first byte, and extending for len bytes, into a read-only mapping:

void *p;

p = mmap (0, len, PROT_READ, MAP_SHARED, fd, 0);
if (p == MAP_FAILED)
        perror ("mmap");

Figure 4-1 shows the effects of paramaters supplied with mmap( ) on the mapping between a file and a process' address space.

Figure 4-1. Mapping a file into a process' address space

The page size

The page is the smallest unit of memory that can have distinct permissions and behavior. Consequently, the page is the building block of memory mappings, which in turn are the building blocks of the process address space.

The mmap( ) system call operates on pages. Both the addr and offset parameters must be aligned on a page-sized boundary. That is, they must be integer multiples of the page size.

Mappings are, therefore, integer multiples of pages. If the len parameter provided by the caller is not aligned on a page boundary—perhaps because the underlying file's size is not a multiple of the page size—the mapping is rounded up to the next full page. The bytes inside this added memory, between the last valid byte and the end of the mapping, are zero-filled. Any read from that region will return zeros. Any writes to that memory will not affect the backing file, even if it is mapped as MAP_SHARED. Only the original len bytes are ever written back to the file.

sysconf( )

The standard POSIX method of obtaining the page size is with sysconf( ), which can retrieve a variety of system-specific information:

#include <unistd.h>

long sysconf (int name);

A call to sysconf( ) returns the value of the configuration item name, or −1 if name is invalid. On error, the call sets errno to EINVAL. Because −1 may be a valid value for some items (e.g., limits, where −1 means no limit), it may be wise to clear errno before invocation, and check its value after.

POSIX defines _SC_PAGESIZE (and a synonym, _SC_PAGE_SIZE) to be the size of a page, in bytes. Therefore, getting the page size is simple:

long page_size = sysconf (_SC_PAGESIZE);

getpagesize( )

Linux also provides the getpagesize( ) function:

#include <unistd.h>

int getpagesize (void);

A call to getpagesize( ) will likewise return the size of a page, in bytes. Usage is even simpler than sysconf( ):

int page_size = getpagesize (  );

Not all Unix systems support this function; it's been dropped from the 1003.1-2001 revision of the POSIX standard. It is included here for completeness.

PAGE_SIZE

The page size is also stored statically in the macro PAGE_SIZE, which is defined in<asm/page.h>. Thus, a third possible way to retrieve the page size is:

int page_size = PAGE_SIZE;

Unlike the first two options, however, this approach retrieves the system page size at compile-time, and not runtime. Some architectures support multiple machine types with different page sizes, and some machine types even support multiple page sizes themselves! A single binary should be able to run on all machine types in a given architecture—that is, you should be able to build it once and run it everywhere. Hard-coding the page size would nullify that possibility. Consequently, you should determine the page size at runtime. Because addrand offset are usually 0, this requirement is not overly difficult to meet.

Moreover, future kernel versions will likely not export this macro to user space. We cover it in this chapter due to its frequent presence in Unix code, but you should not use it in your own programs. The sysconf( ) approach is your best bet.

Return values and error codes

On success, a call to mmap( ) returns the location of the mapping. On failure, the call returnsMAP_FAILED, and sets errno appropriately. A call to mmap( ) never returns 0.

Possible errno values include:

EACCESS

The given file descriptor is not a regular file, or the mode with which it was opened conflicts with prot or flags.

EAGAIN

The file has been locked via a file lock.

EBADF

The given file descriptor is not valid.

EINVAL

One or more of the parameters addr, len, or off are invalid.

ENFILE

The system-wide limit on open files has been reached.

ENODEV

The filesystem on which the file to map resides does not support memory mapping.

ENOMEM

The process does not have enough memory.

EOVERFLOW

The result of addr+len exceeds the size of the address space.

EPERM

PROT_EXEC was given, but the filesystem is mounted noexec.

Associated signals

Two signals are associated with mapped regions:

SIGBUS

This signal is generated when a process attempts to access a region of a mapping that is no longer valid—for example, because the file was truncated after it was mapped.

SIGSEGV

This signal is generated when a process attempts to write to a region that is mapped read-only.

munmap( )

Linux provides the munmap( ) system call for removing a mapping created with mmap( ):

#include <sys/mman.h>

int munmap (void *addr, size_t len);

A call to munmap( ) removes any mappings that contain pages located anywhere in the process address space starting at addr, which must be page-aligned, and continuing for lenbytes. Once the mapping has been removed, the previously associated memory region is no longer valid, and further access attempts result in a SIGSEGV signal.

Normally, munmap( ) is passed the return value and the len parameter from a previous invocation of mmap( ).

On success, munmap( ) returns 0; on failure, it returns −1, and errno is set appropriately. The only standard errno value is EINVAL, which specifies that one or more parameters were invalid.

As an example, the following snippet unmaps any memory regions with pages contained in the interval [addr,addr+len]:

if (munmap (addr, len) == −1)
        perror ("munmap");

Mapping Example

Let's consider a simple example program that uses mmap( ) to print a file chosen by the user to standard out:

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>

int main (int argc, char *argv[])
{
        struct stat sb;
        off_t len;
        char *p;
        int fd;

        if (argc < 2) {
                fprintf (stderr, "usage: %s <file>\n", argv[0]);
                return 1;
        }

        fd = open (argv[1], O_RDONLY);
        if (fd == −1) {
                perror ("open");
                return 1;
        }

        if (fstat (fd, &sb) == −1) {
                perror ("fstat");
                return 1;
        }

        if (!S_ISREG (sb.st_mode)) {
                fprintf (stderr, "%s is not a file\n", argv[1]);
                return 1;
        }

        p = mmap (0, sb.st_size, PROT_READ, MAP_SHARED, fd, 0);
        if (p == MAP_FAILED) {
                perror ("mmap");
                return 1;
        }

        if (close (fd) == −1) {
                perror ("close");
                return 1;
        }

        for (len = 0; len < sb.st_size; len++)
                putchar (p[len]);

        if (munmap (p, sb.st_size) == −1) {
                perror ("munmap");
                return 1;
        }

        return 0;
}

The only unfamiliar system call in this example should be fstat( ), which we will cover inChapter 7. All you need to know at this point is that fstat( ) returns information about a given file. The S_ISREG( ) macro can check some of this information, so that we can ensure that the given file is a regular file (as opposed to a device file or a directory) before we map it. The behavior of nonregular files when mapped depends on the backing device. Some device files are mmap-able; other nonregular files are not mmap-able, and will set errno toEACCESS.

The rest of the example should be straightforward. The program is passed a filename as an argument. It opens the file, ensures it is a regular file, maps it, closes it, prints the file byte-by-byte to standard out, and then unmaps the file from memory.

Advantages of mmap( )

Manipulating files via mmap( ) has a handful of advantages over the standard read( ) andwrite( ) system calls. Among them are:

• Reading from and writing to a memory-mapped file avoids the extraneous copy that occurs when using the read( ) or write( ) system calls, where the data must be copied to and from a user-space buffer.

• Aside from any potential page faults, reading from and writing to a memory-mapped file does not incur any system call or context switch overhead. It is as simple as accessing memory.

• When multiple processes map the same object into memory, the data is shared among all the processes. Read-only and shared writable mappings are shared in their entirety; private writable mappings have their not-yet-COW (copy-on-write) pages shared.

• Seeking around the mapping involves trivial pointer manipulations. There is no need for the lseek( ) system call.

For these reasons, mmap( ) is a smart choice for many applications.

Disadvantages of mmap( )

There are a few points to keep in mind when using mmap( ):

• Memory mappings are always an integer number of pages in size. Thus, the difference between the size of the backing file and an integer number of pages is "wasted" as slack space. For small files, a significant percentage of the mapping may be wasted. For example, with 4 KB pages, a 7 byte mapping wastes 4,089 bytes.

• The memory mappings must fit into the process' address space. With a 32-bit address space, a very large number of various-sized mappings can result in fragmentation of the address space, making it hard to find large free contiguous regions. This problem, of course, is much less apparent with a 64-bit address space.

• There is overhead in creating and maintaining the memory mappings and associated data structures inside the kernel. This overhead is generally obviated by the elimination of the double copy mentioned in the previous section, particularly for larger and frequently accessed files.

For these reasons, the benefits of mmap( ) are most greatly realized when the mapped file is large (and thus any wasted space is a small percentage of the total mapping), or when the total size of the mapped file is evenly divisible by the page size (and thus there is no wasted space).

Resizing a Mapping

Linux provides the mremap( ) system call for expanding or shrinking the size of a given mapping. This function is Linux-specific:

#define _GNU_SOURCE

#include <unistd.h>
#include <sys/mman.h>

void * mremap (void *addr, size_t old_size,
               size_t new_size, unsigned long flags);

A call to mremap( ) expands or shrinks mapping in the region [addr,addr+old_size) to the new size new_size. The kernel can potentially move the mapping at the same time, depending on the availability of space in the process' address space and the value of flags.

Tip

The opening [ in [addr,addr+old_size) indicates that the region starts with (and includes) the low address, whereas the closing ) indicates that the region stops just before (does not include) the high address. This convention is known as interval notation.

The flags parameter can be either 0 or MREMAP_MAYMOVE, which specifies that the kernel is free to move the mapping, if required, in order to perform the requested resizing. A large resizing is more likely to succeed if the kernel can move the mapping.

Return values and error codes

On success, mremap( ) returns a pointer to the newly resized memory mapping. On failure, it returns MAP_FAILED, and sets errno to one of the following:

EAGAIN

The memory region is locked, and cannot be resized.

EFAULT

Some pages in the given range are not valid pages in the process' address space, or there was a problem remapping the given pages.

EINVAL

An argument was invalid.

ENOMEM

The given range cannot be expanded without moving (and MREMAP_MAYMOVE was not given), or there is not enough free space in the process' address space.

Libraries such as glibc often use mremap( ) to implement an efficient realloc( ), which is an interface for resizing a block of memory originally obtained via malloc( ). For example:

void * realloc (void *addr, size_t len)
{
        size_t old_size = look_up_mapping_size (addr);
        void *p;

        p = mremap (addr, old_size, len, MREMAP_MAYMOVE);
        if (p == MAP_FAILED)
                return NULL;
        return p;
}

This would only work if all malloc( ) allocations were unique anonymous mappings; nonetheless, it stands as a useful example of the performance gains to be had. The example assumes the programmer has written a look_up_mapping_size( ) function.

The GNU C library does use mmap( ) and family for performing some memory allocations. We will look that topic in depth in Chapter 8.

Changing the Protection of a Mapping

POSIX defines the mprotect( ) interface to allow programs to change the permissions of existing regions of memory:

#include <sys/mman.h>

int mprotect (const void *addr,
              size_t len,
              int prot);

A call to mprotect( ) will change the protection mode for the memory pages contained in[addr,addr+len), where addr is page-aligned. The prot parameter accepts the same values as the prot given to mmap( ): PROT_NONE, PROT_READ, PROT_WRITE, andPROT_EXEC. These values are not additive; if a region of memory is readable, and prot is set to only PROT_WRITE, the call will make the region only writable.

On some systems, mprotect( ) may operate only on memory mappings previously created via mmap( ). On Linux, mprotect( ) can operate on any region of memory.

Return values and error codes

On success, mprotect( ) returns 0. On failure, it returns −1, and sets errno to one of the following:

EACCESS

The memory cannot be given the permissions requested by prot. This can happen, for example, if you attempt to set the mapping of a file opened read-only to writable.

EINVAL

The parameter addr is invalid or not page-aligned.

ENOMEM

Insufficient kernel memory is available to satisfy the request, or one or more pages in the given memory region are not a valid part of the process' address space.

Synchronizing a File with a Mapping

POSIX provides a memory-mapped equivalent of the fsync( ) system call that we discussed in Chapter 2:

#include <sys/mman.h>

int msync (void *addr, size_t len, int flags);

A call to msync( ) flushes back to disk any changes made to a file mapped via mmap( ), synchronizing the mapped file with the mapping. Specifically, the file or subset of a file associated with the mapping starting at memory address addr and continuing for len bytes is synchronized to disk. The addr argument must be page-aligned; it is generally the return value from a previous mmap( ) invocation.

Without invocation of msync( ), there is no guarantee that a dirty mapping will be written back to disk until the file is unmapped. This is different from the behavior of write( ), where a buffer is dirtied as part of the writing process, and queued for writeback to disk. When writing into a memory mapping, the process directly modifies the file's pages in the kernel's page cache, without kernel involvement. The kernel may not synchronize the page cache and the disk anytime soon.

The flags parameter controls the behavior of the synchronizing operation. It is a bitwise OR of the following values:

MS_ASYNC

Specifies that synchronization should occur asynchronously. The update is scheduled, but the msync( ) call returns immediately without waiting for the writes to take place.

MS_INVALIDATE

Specifies that all other cached copies of the mapping be invalidated. Any future access to any mappings of this file will reflect the newly synchronized on-disk contents.

MS_SYNC

Specifies that synchronization should occur synchronously. The msync( ) call will not return until all pages are written back to disk.

Either MS_ASYNC or MS_SYNC must be specified, but not both.

Usage is simple:

if (msync (addr, len, MS_ASYNC) == −1)
        perror ("msync");

This example asynchronously synchronizes (say that 10 times fast) to disk the file mapped in the region [addr,addr+len).

Return values and error codes

On success, msync( ) returns 0. On failure, the call returns −1, and sets errnoappropriately. The following are valid errno values:

EINVAL

The flags parameter has both MS_SYNC and MS_ASYNC set, a bit other than one of the three valid flags is set, or addr is not page-aligned.

ENOMEM

The given memory region (or part of it) is not mapped. Note that Linux will returnENOMEM, as POSIX dictates, when asked to synchronize a region that is only partly unmapped, but it will still synchronize any valid mappings in the region.

Before version 2.4.19 of the Linux kernel, msync( ) returned EFAULT in place of ENOMEM.

Giving Advice on a Mapping

Linux provides a system call named madvise( ) to let processes give the kernel advice and hints on how they intend to use a mapping. The kernel can then optimize its behavior to take advantage of the mapping's intended use. While the Linux kernel dynamically tunes its behavior, and generally provides optimal performance without explicit advice, providing such advice can ensure the desired caching and readahead behavior for some workloads.

A call to madvise( ) advises the kernel on how to behave with respect to the pages in the memory map starting at addr, and extending for len bytes:

#include <sys/mman.h>

int madvise (void *addr,
             size_t len,
             int advice);

If len is 0, the kernel will apply the advice to the entire mapping that starts at addr. The parameter advice delineates the advice, which can be one of:

MADV_NORMAL

The application has no specific advice to give on this range of memory. It should be treated as normal.

MADV_RANDOM

The application intends to access the pages in the specified range in a random (nonsequential) order.

MADV_SEQUENTIAL

The application intends to access the pages in the specified range sequentially, from lower to higher addresses.

MADV_WILLNEED

The application intends to access the pages in the specified range in the near future.

MADV_DONTNEED

The application does not intend to access the pages in the specified range in the near future.

The actual behavior modifications that the kernel takes in response to this advice are implementation-specific: POSIX dictates only the meaning of the advice, not any potential consequences. The current 2.6 kernel behaves as follows in response to the advice values:

MADV_NORMAL

The kernel behaves as usual, performing a moderate amount of readahead.

MADV_RANDOM

The kernel disables readahead, reading only the minimal amount of data on each physical read operation.

MADV_SEQUENTIAL

The kernel performs aggressive readahead.

MADV_WILLNEED

The kernel initiates readahead, reading the given pages into memory.

MADV_DONTNEED

The kernel frees any resources associated with the given pages, and discards any dirty and not-yet-synchronized pages. Subsequent accesses to the mapped data will cause the data to be paged in from the backing file.

Typical usage is:

int ret;

ret = madvise (addr, len, MADV_SEQUENTIAL);
if (ret < 0)
        perror ("madvise");

This call instructs the kernel that the process intends to access the memory region[addr,addr+len) sequentially.

Readahead

When the Linux kernel reads files off the disk, it performs an optimization known asreadahead. That is, when a request is made for a given chunk of a file, the kernel also reads the following chunk of the file. If a request is subsequently made for that chunk—as is the case when reading a file sequentially—the kernel can return the requested data immediately. Because disks have track buffers (basically, hard disks perform their own readahead internally), and because files are generally laid out sequentially on disk, this optimization is low-cost.

Some readahead is usually advantageous, but optimal results depend on the question of how much readahead to perform. A sequentially accessed file may benefit from a larger readahead window, while a randomly accessed file may find readahead to be worthless overhead.

As discussed in "Kernel Internals" in Chapter 2, the kernel dynamically tunes the size of the readahead window in response to the hit rate inside that window. More hits imply that a larger window would be advantageous; fewer hits suggest a smaller window. The madvise( )system call allows applications to influence the window size right off the bat.

Return values and error codes

On success, madvise( ) returns 0. On failure, it returns −1, and errno is set appropriately. The following are valid errors:

EAGAIN

An internal kernel resource (probably memory) was unavailable. The process can try again.

EBADF

The region exists, but does not map a file.

EINVAL

The parameter len is negative, addr is not page-aligned, the advice parameter is invalid, or the pages were locked or shared with MADV_DONTNEED.

EIO

An internal I/O error occurred with MADV_WILLNEED.

ENOMEM

The given region is not a valid mapping in this process' address space, orMADV_WILLNEED was given, but there is insufficient memory to page in the given regions.

The best content for your career. Discover unlimited learning on demand for around $1/day.

Get 10 Days Free