No need for additional system calls ( by your process ), you just access it like regular memory. When you re done with the file, just call munmap.

Return Value

On success, mmap() returns a pointer to the mapped area. On error, the value MAP_FAILED (that is, (void *) -1) is returned, and errno is set appropriately. On success, munmap() returns 0, on failure -1, and errno is set (probably to EINVAL).

See the man page here for details.

Edit For clarification:

I m saying that the function maps the file into the calling process s memory space and returns a pointer to the beginning of the memory block.

For example, if you have two different processes map the same file with the MAP_SHARED flag then each process will be accessing the same physical memory, but that memory may be mapped at a different location in each process s virtual memory space, i.e. the pointers returned by mmap in each process s virtual memory space may not be equal.

This brings up the point that if you for instance need to store pointers inside the shared memory block those pointers would only be useful if they were stored as offsets relative to the beginning of the block / file and they would only be able to usefully point to locations internal to the block / file.

When you mmap a file, Linux creates entries in the MMU (memory management unit). The MMU watches over all reads and writes of the CPU to the real RAM. This way, it knows when you access parts of the memory which mmap() returned. Reading parts which are not yet in the real RAM will cause page faults. The MMU will catch them and call a kernel routine to load the right part of the file into RAM somewhere and then it will update the entry in the MMU table so it appears that the data is now located at the address which mmap() gave you. In fact, it will be somewhere else but the MMU will make this completely transparent.

When you write to the memory, the MMU will mark the modified pages as "dirty". When they are flushed out (because you access more of the file or because you call munmap()), then the changes will be written out to disk.

So every time a page fault and a dirty page flush happens, a system call happens. But since pages are 4 or 8KB, these happen rarely. Also, the kernel will load more than a single page at a time, so the number of system calls is reduced again. Lastly, the same code is used to implement swapping, so it is very optimized.

All these effects make mmap so efficient.