21

In my understanding, mmap'ing a file that fits into RAM will be like having the file in memory.

Say that we have 16G of RAM, and we first mmap a 10G file that we use for a while. This should be fairly efficient in terms of access. If we then mmap a second 10G file, will that cause the first one be swapped out? Or parts of it? If so, when will this happen? At the mmap call, or on accessing the memory area of the newly loaded file?

And if we want to access the memory of the pointer for the first file again, will that make it load the swap the file in again? So, say we alternate reading between memory corresponding to the first file and the second file, will that lead to disastrous performance?

Lastly, if any of this is true, would it be better to mmap several smaller files?

Masseman
  • 359
  • 3
  • 13

2 Answers2

11

As has been discussed, your file will be accessed in pages; on x86_64 (and IA32) architectures, a page is typically 4096 bytes. So, very little if any of the file will be loaded at mmap time. The first time you access some page in either file, then the kernel will generate a page fault and load some of your file. The kernel may prefetch pages, so more than one page may be loaded. Whether it does this depends on your access pattern.

In general, your performance should be good if your working set fits in memory. That is, if you're only regularly accesning 3G of file across the two files, so long as you have 3G of RAM available to your process, things should generally be fine.

On a 64-bit system there's no reason to split the files, and you'll be fine if the parts you need tend to fit in RAM.

Note that if you mmap an existing file, swap space will not be required to read that file. When an object is backed by a file on the filesystem, the kernel can read from that file rather than swap space. However, if you specify MMAP_PRIVATE in your call to mmap, swap space may be required to hold changed pages until you call msync.

Sam Hartman
  • 6,210
  • 3
  • 23
  • 40
6

Your question does not have a definitive answer, as swapping in/out is handled by your kernel, and each kernel will have a different implementation (and linux itself offers different profiles depending on your usage, RT, desktop, server…)

Generally speaking, though, whatever you load in memory is done using pages, so your mmap'ed file in memory is loaded (and offloaded) by pages between all the levels of memory (the caches, RAM and swap). Then if you load two 10GB data into memory, you'll have parts of both between the RAM and your Swap, and the kernel will try to keep in RAM the pages you're likely to use now and guess what you'll load next.

What it means is that if you do truly random access to a few bytes of data in both files alternatively, you should expect awful performance, if you access contiguous chunks sequentially from both files alternatively, you should expect decent performance.

You can read some more details about kernel paging into virtual memory theory:

zmo
  • 24,463
  • 4
  • 54
  • 90
  • I see. So what matters are the pages, and not the files. Accessing memory from different pages of the same file should then have the same behavior/performance as accessing different pages from different files? No point in splitting the data into smaller files, then? – Masseman Apr 25 '17 at 13:16
  • well, what really matter is your kernel and the swapping strategy (as you don't control how paging works). Splitting the data into multiple smaller files shall be a calculated trade of. Because I/Os are blocking, loading a 10GB file will take a non-negligeable time causing other services to stall while you're accessing it (because you'll take all the bus bandwidth or because you might read from an old spinning drive). Thus, splitting in several files, will make it slower to load the data, but help keep your system more responsive. – zmo Apr 25 '17 at 18:19
  • I/O will not block other processes. That is, splitting the files will not help improve performance of unrelated operations. In general, if the data is mmapped, splitting won't improve blocking even within the file. – Sam Hartman Jul 12 '18 at 19:29