Problem:

Translation overhead of page-based virtual memory are too high when: Large memory footprint && Poor locality

Note:The overhead comes from frequent page walks.

Note:The paper possibly questions the notion of page

Note: pages are nice b/c we can move pages around

Note: pages are nice b/c protection can be assigned with a fine granularity

Note: before paging, we had segments. Segments are not as flexible.

Note: pages came up b/c they allowed us a shared multi process systems w/ the same amount of memory.

Note: This paper argues that the need for page based system is not as much. Today, we can dedicate servers or systems to a few applications. Effectively, we can reduce the page faults. The intention is actually to avoid going to disk all together due to the high latency incurred in such scenario.

Note: This paper does not provide an alternative to page based systems entirely. There are scenario in which we might have to revert back to page based.

What happens when the program asks for a chunk of memory:

Programmer calls malloc.

Program sits on top of a run time system. (note: an application has a program and a run time system associated with it). (Note: libc is the runtime system for C.)

Libc reacts to malloc by using its memory allocator.

At this point OS takes over, with its memory manager to find some virtual memory.

Note that at this point OS has not allocated any memory yet. It only makes a page table to marks this amount of memory for this processes.

Solution

3 parts:

HW support:
L1 TLB;
L2 TLB + range TLB (with the priority on L2 TLB). update L1 TLB if found in range TLB;
If miss, page walk
If page in region, RT walk;
OS support:
range table, RT coherence, policies for breaking ranges
OS mem mgmt policies
Eager memory manager (allocator): when asked for memory, actually allocated memory;
→ + : can get regions
→-: fragmentation => bloat, additional book keeping overhead(e.g defragmentation), in some cases alot of I/O.
Note: One of the benefits of their solution is that it is backward compatible.

Evaluation:

They didn’t use simulation:

large memories is hard to simulate. Large memory needs long simulation and in addition, you need twice the memory=> sim memory bloat.
Lack of information about the behavior of current systems TLB behavior.

They Simulated a range table

They only looked at ideal scenarios for evaluating their system. They mentioned all the problems that one can run into using their solution but they never tested the system under these cases but over all convincing

They Modified linux to incorporate the policies discussed above.

They To get the number of TLB misses, they instrumented linux to fault on TLB misses.

They used the HW perf counter TLB miss cycles.

They evaluated the performance and memory bloat overhead.

They evaluated the sensitivity of the RT TLB.

Note: in their model, they didn’t consider the overlapping of execution and TLB misses time. However this is not as big of an issue since the OOO window is small enough.

Was it convincing:

They only looked at ideal scenarios for evaluating their system. They mentioned all the problems that one can run into using their solution but they never tested the system under these cases but over all convincing