| 1 | ==============================
|
| 2 | remap_file_pages() system call
|
| 3 | ==============================
|
| 4 |
|
| 5 | The remap_file_pages() system call is used to create a nonlinear mapping,
|
| 6 | that is, a mapping in which the pages of the file are mapped into a
|
| 7 | nonsequential order in memory. The advantage of using remap_file_pages()
|
| 8 | over using repeated calls to mmap(2) is that the former approach does not
|
| 9 | require the kernel to create additional VMA (Virtual Memory Area) data
|
| 10 | structures.
|
| 11 |
|
| 12 | Supporting of nonlinear mapping requires significant amount of non-trivial
|
| 13 | code in kernel virtual memory subsystem including hot paths. Also to get
|
| 14 | nonlinear mapping work kernel need a way to distinguish normal page table
|
| 15 | entries from entries with file offset (pte_file). Kernel reserves flag in
|
| 16 | PTE for this purpose. PTE flags are scarce resource especially on some CPU
|
| 17 | architectures. It would be nice to free up the flag for other usage.
|
| 18 |
|
| 19 | Fortunately, there are not many users of remap_file_pages() in the wild.
|
| 20 | It's only known that one enterprise RDBMS implementation uses the syscall
|
| 21 | on 32-bit systems to map files bigger than can linearly fit into 32-bit
|
| 22 | virtual address space. This use-case is not critical anymore since 64-bit
|
| 23 | systems are widely available.
|
| 24 |
|
| 25 | The syscall is deprecated and replaced it with an emulation now. The
|
| 26 | emulation creates new VMAs instead of nonlinear mappings. It's going to
|
| 27 | work slower for rare users of remap_file_pages() but ABI is preserved.
|
| 28 |
|
| 29 | One side effect of emulation (apart from performance) is that user can hit
|
| 30 | vm.max_map_count limit more easily due to additional VMAs. See comment for
|
| 31 | DEFAULT_MAX_MAP_COUNT for more details on the limit.
|