
Efficient Virtual Memory for Big Memory Servers [pdf] - adamnemecek
http://research.cs.wisc.edu/multifacet/papers/isca13_direct_segment.pdf
======
hyc_symas
"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.)

------
amelius
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).

Would this solve something?

------
alexnewman
I can't wait for super pages. Going to be so funny. What's new is old!

~~~
hyc_symas
Time to dust off my old MC68451 segmented MMU and fire up a copy of MULTICS.

