[quotemstr]

It's funny how people think they're disabling swapping just because they don't have a swap file. Where do you think mmap()-ed file pages go? Your machine can still reclaim resident file-backed pages (either by discarding them if they're clear or writing them to their backing file if dirty) and reload them later. That's.... swap.

Instead of achieving responsiveness by disabling swap entirely (which is silly, because everyone has some very cold pages that don't deserve to be stuck in memory), people should mlockall essential processes, adjust the kernel's VM swap propensity, and so on.

Also, I wish we'd just do away with the separation between the anonymous-memory and file-backed memory subsystems entirely. The only special about MAP_ANONYMOUS should be that its backing file is the swap file.

[kevin_thibedeau]

mmap is not swap. It's using the same virtual memory mechanisms to load/dump pages to disk. The policy for when to read and write those pages is completely different.

[Dylan16807]

When the room for memory mapped files gets low enough you get bad thrashing anyway, so the policy difference isn't that important.

Having no swap limits how much you can overburden your computer, but you also hit problems earlier. Here's some example numbers for 64GB of memory: With swap you can go up to 62GB of active program data (85GB allocated and used) before you have performance issues. Without swap you can go up to 45GB of active program data (63GB allocated and used) before you hit a brick wall of either thrashing or killing processes. The no-swap version is better at maintaining snappiness within its happy range, but it's a tradeoff.

[quotemstr]

It is doing exactly what swap is doing. That it's swap with a different policy doesn't make it not-swap.

Also, that separate policy shouldn't even exist. For LRU/active-list/inactive-list purposes, why does it matter whether a page is anonymous or file-backed? If you need it, you need it, and if you don't, you don't. No reason for anonymous and file-backed memory to be separate sub-sub-systems under vm.

[man8alexd]

Anonymous memory and files have different access patterns. Files are frequently read sequentially and only once, so there is no need to keep them in memory. When files are read, cached memory pages are put into inactive file LRU first and promoted to active LRU only on the second access.

[quotemstr]

It is possible to unify things behind a single mechanism, yet apply different policies to different instances of this mechanism depending on circumstances and heuristics. We do not need almost entirely disjoint paging systems in the Linux kernel to notice that some kinds of memory have access patterns different from other kinds of memory. Instead of guessing based on whether someone used MAP_ANONYMOUS, we should observe what a program is actually doing.

[man8alexd]

All LRUs, file-backend and anonymous are handled by the same code. There are some conditionals here and there - executable pages are promoted to active LRU on the first access, locked pages (if I remember correctly) too, but all pages go through the same cycle. See this Linux Plumbers conference presentation https://www.youtube.com/watch?v=0bnWQF7WQP0 with the following slides https://d3s.mff.cuni.cz/files/teaching/nswi161/2023_24/08_li...

[retrac]

The ghost of Multics walks yet the page tables awaiting recorporealization.