Perforated Page: Supporting Fragmented Memory Allocation for Large Pages

Abstract

The availability of large pages has dramatically improved the efficiency of address translation for applications that use large contiguous regions of memory. However, large pages can be difficult to allocate due to fragmented memory, non-movable pages, or the need to split a large page into regular pages when part of the large page is forced to have a different permission status from the rest of the page. Furthermore, they can also be expensive due to memory bloating caused by sparse accesses to application data. In this work, we enable the allocation of large 2MB pages even in the presence of fragmented physical memory via perforated pages. Perforated pages permit the OS to punch 4KB page-sized holes in the physical address range allocated to a large page and re-map them to other addresses as needed. This not only enables the system to benefit from large pages in the presence of fragmentation, but also allows for different permissions to exist within a large page, enhancing sharing flexibility. In addition, it allows unused parts of a large page to be used elsewhere, mitigating memory bloating. To minimize changes to the system, perforated pages reuse the 4KBlevel page table entries to store the hole locations and translates holes into regular 4KB pages. For performance, the proposed technique caches the translations for hole pages in the TLBs and track holes via cached bitmaps in the L2 TLB. By enabling large pages in the presence of physical memory fragmentation, perforated pages increase the applicability and resulting benefits of large pages with only minor changes to the hardware and OS. In this work, we evaluate the effectiveness of perforated pages with timing simulations under diverse and realistic fragmentation scenarios. Our results show that even with fragmented memory, perforated pages accomplish 93.2% to 99.9% of the performance achievable by ideal memory allocation, and 2.0% to 11.5% better performance over the conventional system running with fragmented memory.

CCoW: Optimizing Copy-on-Write Considering the Spatial Locality in Workloads

“…Zhu et al [15] generalize the processes of using huge pages, and optimize the lifecycle of huge pages. Part et al [16] allow holes in huge page, providing the flexibility in memory management with huge pages.…”

“…If an allocated address range is smaller than the huge page size, the rest of the page cannot be utilized and gets wasted. This so-called memory bloat can significantly decrease memory utilization on the systems with huge pages [12][13][14][15][16][17]. The increased page size can negatively affect program performance as well.…”

“…Many state-of-the-art designs [12][13][14][15][16][17] have been proposed to optimize the use of huge pages in the OS. These systems, in common, present a scheme to identify the best candidate pages to be converted to huge pages and to efficiently promote to (i.e., convert base pages to a huge page) or demote from (i.e., converts a huge page into base pages) huge pages.…”

Reducing Minor Page Fault Overheads through Enhanced Page Walker

“…Large pages have been proposed to reduce the costs of number of page faults to be handled [16,20,24,25] and sometimes to increase the reach of the TLBs [28]. Large pages are beneficial when addresses are allocated over contiguous ranges, but many new applications allocate small objects [12], and have required additional support for efficiencies [26]. Our approach here works across different workloads and moves much of the memory management overhead away from inline processes.…”

Page Tables: Keeping them Flat and Hot (Cached)

“…Bloating occurs when the larger pages do not match the application's sparse allocation/deallocation pattern. As a result, many large pages end up with unused holes [32], [38], but still need to be fully allocated in physical memory, thereby wasting physical memory. Variability occurs when a large enough region of contiguous and aligned physical memory region cannot be immediately found and the operating system must compact and relocate pages to create it [32], [36].…”