"We examine this hypothesis by measuring the amount of swapping in these workloads with the vmstat Linux utility. As expected, we observe no swapping activity, indicating little value in providing the capability to swap."
Yes, but that's obvious - if your DB application starts swapping, you have badly misconfigured something. A well-tuned server should never have any swap activity.
But there is still page-oriented I/O for explicitly invoked I/Os, and it's still crucial to support that properly.
Granted, 4KB pages are probably too small for today's storage hardware. 2MB or 4MB pages might even be too small too. (multiply pagesize * I/O transfer rate, compare to average seek time. Ideally you want pagesize * rate to be greater than seek time, but that hasn't been true in decades.)
How difficult would it be to keep statistics for each page (in a separate "process" inside the CPU), and swap out pages according to these statistics? (Thus on every read and write operation, the page number would be streamed to a bookkeeper circuit.)
Alternatively, could malloc be given an extra parameter: the "priority" of the page the block will be allocated in. For example malloc(100, 1) would allocate a block of 100 bytes inside a priority-1 page. (Thus the OS would know the priority of each page, and swap them out accordingly; the heap allocator would assign these numbers).
Yes, but that's obvious - if your DB application starts swapping, you have badly misconfigured something. A well-tuned server should never have any swap activity. But there is still page-oriented I/O for explicitly invoked I/Os, and it's still crucial to support that properly.
Granted, 4KB pages are probably too small for today's storage hardware. 2MB or 4MB pages might even be too small too. (multiply pagesize * I/O transfer rate, compare to average seek time. Ideally you want pagesize * rate to be greater than seek time, but that hasn't been true in decades.)