Skip to content
About
Main content

Two live claims: mmap and cheap RAM

Why can residency not be handed to mmap, and why does cheap RAM not make buffer pools obsolete?

Two live claims worth typing honestly

"Just mmap the file and let the kernel handle residency."

This is wrong for a reason stronger than performance, which is why it keeps coming back and keeps failing. Crotty, Leis and Pavlo (2022) catalogue the problems:

  1. You cannot control when a page is evicted, so you cannot enforce the WAL ordering rule. This is the correctness argument, and on its own it is decisive.
  2. Page-fault I/O is invisible to the engine, so stalls happen inside critical sections that were written assuming memory speed.
  3. Error handling arrives as a SIGBUS signal rather than a return code.
  4. TLB shootdown cost on unmap (the cost of telling every core to forget a translation) scales with the core count.

The residency decision cannot be delegated because correctness depends on its timing, not because the kernel is slow. That is the ownership argument of Ownership in its strongest available form.

"RAM is cheap enough that buffer pools are obsolete."

There are two answers, of different kinds.

The economic answer: the five-minute rule (Gray and Putzolu, 1987, recomputed roughly each decade since). Keep a page resident if its re-reference interval is shorter than

Data table
Break-even re-reference interval by RAM price (8 KB pages, $0.003 per access per second)
RAM price ($ per GB)Keep in RAM if re-read within
0.5786 s
0.524751 s
0.548717 s
0.574685 s
0.601654 s
0.63624 s
0.659596 s
0.69569 s
0.723544 s
0.757519 s
0.793496 s
0.83474 s
0.87452 s
0.911432 s
0.954412 s
0.999394 s
1.05376 s
1.09359 s
1.15343 s
1.2327 s
1.26313 s
1.32299 s
1.38285 s
1.44272 s
1.51260 s
1.58248 s
1.66237 s
1.74226 s
1.82216 s
1.9206 s
1.99197 s
2.09188 s
2.19180 s
2.29172 s
2.4164 s
2.51157 s
2.63150 s
2.75143 s
2.88136 s
3.02130 s
3.16124 s
3.31119 s
3.47113 s
3.63108 s
3.8103 s
3.9898.7 s
4.1794.3 s
4.3790 s
4.5786 s
4.7982.1 s
5.0178.4 s
5.2574.9 s
5.571.5 s
5.7668.3 s
6.0365.2 s
6.3262.3 s
6.6159.5 s
6.9356.8 s
7.2554.2 s
7.5951.8 s
7.9549.4 s
8.3347.2 s
8.7245.1 s
9.1343.1 s
9.5641.1 s
1039.3 s
10.537.5 s
1135.8 s
11.534.2 s
1232.7 s
12.631.2 s
13.229.8 s
13.828.4 s
14.527.2 s
15.225.9 s
15.924.8 s
16.623.6 s
17.422.6 s
18.221.6 s
19.120.6 s
2019.7 s

The formula is the point, not the number: the number moves with hardware prices and has landed in the range of minutes for every DRAM/secondary-storage pair so far. (The prices that set it come from cost mechanics; the decision belongs to whoever sizes the pool.)

The engineering answer: pointer swizzling (Graefe; the LeanStore system). Replace the page-id → frame hash lookup with a pointer that is either a memory address or a page identifier, distinguished by a tag bit. A workload that is entirely in memory then pays essentially nothing for buffer management, while the system can still exceed memory. The complaint was the overhead of the , and it turned out to be removable without removing the pool. Treat this as active engineering reality, not settled practice.