TECHNICAL FIELD

The subject matter described herein relates to virtual memory management. More specifically, the subject matter relates to methods, systems, and computer readable media for performing page fault handling.

BACKGROUND

Virtual memory is a memory management technique used in modern computer systems. Virtual memory allows applications to allocate or own more memory than is physically available. In practice, virtual memory utilizes two fundamental techniques: lazy allocation and swapping.

Lazy allocation is a memory management concept where memory (e.g., a virtual memory page) is allocated only when it is being accessed or needed. Using lazy allocation, a memory subsystem of an operating system (OS) can avoid giving applications memory before the applications begin execution. Lazy allocation generally works well because it is very rare for an application to touch or access all pages it requires immediately after executing and usually the working sets of programs are much smaller than their whole memory footprints. Based on this characteristic of programs, memory subsystems can let multiple applications concurrently execute, thereby improving the system overall performance without the system running out of memory.

While lazy allocation can reduce memory usage, it is still possible for all memory to be allocated, e.g., if too many applications are executing concurrently in the systems. If the memory runs out, a swapping mechanism can store the content of some pages in non-volatile storage devices so that those pages can be reused (e.g., re-allocated) by other applications.

Lazy allocation and swapping usually work as part of a kernel's page fault exception handling. For example, when memory is “allocated” (such as mmap or malloc) by programs, actually only a region of virtual memory address space is created by the kernel for the calling programs, and none of the physical pages is allocated. So, the following memory access within this newly created region may trigger a page fault exception by a hardware-implemented page walker, and then a software-implemented exception handler will check and confirm this access as legal and in turn allocates a page for it.

The exception handler may need to perform a significant number of operations to handle a page fault, from checking validity of a faulting address, acquiring a page from available free memory pages, filling the page with the corresponding data content from a storage device (e.g., major page fault) or zeroing the page (e.g., minor page fault), to creating some data structures for the memory management. Related context switch overhead associated with a major page fault may not be a serious problem if the underlying storage devices are solid-state drives (SSDs) or hard disk drives (HDDs) because access latency for such storage devices are several orders more than that of dynamic random-access memory (DRAM), and as such, in these cases, the context switch overhead would only contribute a relatively small portion of the total access latency. However, when using emerging non-volatile memories (NVM) as storage devices, related context switch overhead may be a more significant issue since these types of memory have significantly less access latency than SSDs or HDDs, and as such, in these cases, the context switch overhead would be responsible for a significant portion of the total access latency.

SUMMARY

Methods, systems, and computer readable media for performing page fault handling are disclosed. According to one method, the method includes: after a translation lookaside buffer (TLB) miss associated with a virtual memory page occurs, identifying, in a page table, a page table entry (PTE) associated with the virtual memory page; determining, using a first indicator in the PTE, that the virtual memory page is not present in a main memory; determining, using a second indicator in the PTE, that the virtual memory page is associated with a valid memory address and that the virtual memory page is capable of using pre-allocated pages; obtaining, from a pre-allocation table, a page frame number associated with a pre-allocated page; and updating the PTE to indicate the page frame number.

According to one system, the system includes at least one processor; and a page fault handling offload engine (POE) implemented using the at least one processor, wherein the POE is configured for: after a TLB miss associated with a virtual memory page occurs, identifying, in a page table, a PTE associated with the virtual memory page; determining, using a first indicator in the PTE, that the virtual memory page is not present in a main memory; determining, using a second indicator in the PTE, that the virtual memory page is associated with a valid memory address and that the virtual memory page is capable of using pre-allocated pages; obtaining, from a pre-allocation table, a page frame number associated with a pre-allocated page; and updating the PTE to indicate the page frame number.

The subject matter described herein can be implemented in software in combination with hardware and/or firmware. For example, the subject matter described herein can be implemented in software executed by a processor. In one example implementation, the subject matter described herein may be implemented using at least one computer readable medium having stored thereon computer executable instructions that when executed by the processor of a computer cause the computer to perform steps or operations. Exemplary computer readable media suitable for implementing the subject matter described herein include non-transitory devices, such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms.

As used herein, the terms “node” and “host” refer to a physical computing platform or device including one or more processors and memory.

As used herein, the terms “module” and “engine” refers to hardware, firmware, or software in combination with hardware and/or firmware for implementing features described herein.

