Transparent large page fault processing method

Abstract

The invention relates to the technical field of fault processing, in particular to a transparent large page fault processing method, electronic equipment and a storage medium. The method comprises the steps of obtaining a page descriptor based on a physical address of a fault page; analyzing based on the page descriptor to obtain a fault page attribute; judging whether the fault page is a transparent large page or not based on the fault page attribute; if not, directly ending; if yes, continuing to judge whether the fault page is a file mapping transparent large page or an anonymous mapping transparent large page; if the transparent large page is anonymously mapped, entering a transparent large page processing flow; if the fault page is the file mapping transparent large page, continuing to judge whether the fault page is an unmapped clean transparent large page or not; if the fault page is an unmapped clean transparent large page, discarding the fault page; and if the fault page is not the unmapped clean transparent large page, entering a transparent large page processing flow. According to the method, the process can still use the transparent large page, and only the address mapping relation is migrated to the new transparent large page.

Description

Technical Field

[0001] This invention relates to the field of fault handling technology, and more specifically, to a fault handling method for transparent large pages. Background Technology

[0002] Servers are core components of large-scale data centers. With the development of cloud computing and high-performance computing, servers are becoming increasingly larger, integrating more and more processors, disk storage, PCIe modules, memory, and other hardware. Instability in data storage devices and data propagation buses poses a fatal threat to server reliability, leading to operational failures such as system crashes, device freezes, or data integrity failures such as data corruption and the propagation of erroneous data. Among these factors, memory failure is the most widespread and critical issue requiring the most attention. Traditionally, memory failures are handled through hardware detection and initial repair, followed by further containment and repair through the operating system. However, due to the complexity of memory management, current memory failure handling is not precise enough. For example, current operating systems do not adequately balance reliability and performance in handling transparent huge pages (THP). Since THP is a common technique for improving memory access performance, often used for managing large anonymous pages and large file pages, failure to properly address THP failures will cause problems with user task reliability and performance. Summary of the Invention

[0003] The main objective of this invention is to provide a transparent big page fault handling method. When the number of memory CE (Complete Execution) faults accumulates to a threshold within a specified time, the method first retrieves the corresponding page descriptor (struct page) from the page metadata area based on the physical address of the CE-faulted page. Then, it determines and processes transparent big pages based on their page attributes.

[0004] This invention provides a method for handling faults in transparent large pages, comprising the following steps: Step S1: Obtain the page descriptor of the fault page based on the physical address of the fault page of the CE fault; Step S2: Parse the page descriptor of the faulty page to obtain the attributes of the faulty page; determine whether the faulty page is a transparent large page based on the attributes of the faulty page; if the faulty page is a transparent large page, proceed to step S3; if the faulty page is not a transparent large page, end directly. Step S3: Determine whether the faulty page is a file-mapped transparent large page or an anonymously mapped transparent large page; if the faulty page is an anonymously mapped transparent large page, proceed to the transparent large page processing flow for decomposition processing; if the faulty page is a file-mapped transparent large page, proceed to step S4. Step S4: Determine if the faulty page is an unmapped clean transparent large page; if the faulty page is an unmapped clean transparent large page, invalidate the faulty page directly; if the faulty page is not an unmapped clean transparent large page, proceed to the transparent large page processing flow for decomposition processing.

[0005] Furthermore, in step S2, determining whether a faulty page is a transparent large page based on its attributes is done by combining the PageHuge() and PageTransHuge() functions.

[0006] Furthermore, when PageTransHuge(page) == true and PageHuge(page) == false, the faulty page is a transparent large page; where page refers to the faulty page.

[0007] Furthermore, it also includes step S0: when the number of CE failures occurring in the memory within a specified time exceeds a threshold, proceed to step S1.

[0008] Furthermore, the page descriptor is a struct page structure.

[0009] Furthermore, in step S3, the determination of whether the transparent page is a file-mapped transparent page or an anonymously mapped transparent page is made using the struct address_space pointer.

[0010] Furthermore, the struct address_space pointer refers to the mapping in the kernel.

[0011] Furthermore, the transparent large page processing workflow includes the following steps: Step A1: Mark the faulty page that has entered the transparent large page processing flow as the old transparent large page, and migrate the page content of the old transparent large page to the new transparent large page; Step A2: Break down the old transparent large page into regular small pages; Step A3: Set a fault isolation flag for the fault pages in the regular small pages; Step A4: Traverse and release all regular small pages.

[0012] Furthermore, in step A1, the page content of the old transparent page is migrated to the new transparent page using a page migration function.

[0013] Furthermore, in step A2, the old transparent large page is broken down into faulty small pages using the try_to_split_thp_page function.

[0014] The beneficial effects of this invention are as follows: 1. For transparent huge pages that are anonymously mapped or for dirty pages of files with existing mappings, the page content of the original faulty page needs to be migrated first, and then the original faulty page needs to be separated and reclaimed. This ensures that after the fault handling is completed, the process's access to the original virtual address still maps to the transparent huge page, thus ensuring that performance is not degraded.

[0015] 2. Transparent large pages are processed in a more detailed manner. Dirty pages that are in the page cache and have no mapping are simply removed from the page cache and no longer migrated, thereby improving the efficiency of transparent large page fault handling.

[0016] 3. During fault handling, when migrating transparent large pages, the new transparent large page is allocated into the local node memory where the process resides, improving migration and memory access efficiency.

[0017] 4. After the entire transparent large page is migrated to the new transparent large page, the old transparent large page is decomposed and recycled to avoid memory waste.

[0018] 5. Set a fault flag in the regular small page for faults (fault small page) to prevent the system from accessing the faulty memory again. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram illustrating the principle of obtaining page descriptors based on physical addresses according to the present invention; Figure 2 This is a schematic diagram of the fault classification of the present invention; Figure 3 This is a schematic diagram of the transparent large page fault handling process of the present invention. Detailed Implementation

[0021] The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments of the present invention. Many specific details are set forth in the following description to provide a thorough understanding of the present invention; however, the present invention may also be implemented in other ways different from those described herein. Those skilled in the art can make similar extensions without departing from the spirit of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0022] This invention proposes a transparent big page fault handling method. When the number of CE (Complete Execution) faults in a memory cell exceeds a threshold within a specified time, the corresponding page descriptor (struct page) is first obtained from the page metadata area based on the physical address of the CE-faulted page. Transparent big pages are then identified and processed based on their page attributes.

[0023] Memory fault detection and repair are accomplished through a combination of hardware and software. Hardware components with integrated ECC (Error Correction Code) functions, such as memory controllers, instruction prefetching units, and data cache units, are used to detect and repair memory faults. Due to technological limitations, currently, 1-bit memory faults can be detected and repaired, but 2-bit faults can only be detected but not repaired. Therefore, memory faults are represented by corrected errors (CE) and uncorrected errors (UCE) to represent 1-bit and 2-bit faults, respectively. 1-bit memory faults are relatively common in storage or transmission. Because ECC can repair these faults, the probability of them directly causing system problems is greatly reduced. However, industry research on memory faults has found that if a neighboring memory cell with a 1-bit fault also experiences a 1-bit fault, the fault escalates to a 2-bit fault (UCE). In this case, ECC cannot repair the fault, leading to system malfunction or data integrity corruption. To prevent the risk of fault escalation, the hardware counts when a CE (Completely Executable) fault is detected. If this count exceeds a preset threshold within a specified time (e.g., 30 occurrences in 24 hours), the operating system is notified to take the faulty page offline and isolate it, thereby preventing the probability of a CE escalating to a UCE (Unified Executable) fault. Figure 2 As shown, CE (Complete Execution) faults exist in three states within the operating system: in the LRU (Least Recently Used) list, in the standard HugePage, and in the free list managed by the memory allocator Buddy. The LRU list is further divided into ordinary pages and transparent HugePages. This invention provides an in-depth analysis of the case where the CE fault page attribute is a transparent HugePage and proposes a more reasonable fault handling scheme. This scheme can solve the problem of transparent HugePages being taken offline and marked with a fault identifier after a fault occurs. More importantly, the process using the transparent HugePage will still enjoy the performance benefits brought by using the transparent HugePage. Specific Implementation Example 1:

[0025] This embodiment is a method for handling transparent large page faults, including the following steps: Step S0: When the number of CE failures in the memory exceeds the threshold within a specified time, proceed to step S1.

[0026] Step S1: Obtain the page descriptor of the faulty page based on its physical address. After obtaining the physical address of the faulty page, the operating system only needs to add the physical page frame number (PFN) corresponding to the physical address of the faulty page to vmemmap to obtain the page descriptor structure `struct page`. `vmemmap` refers to the virtual address space.

[0027] Step S2: Parse the page descriptor of the faulty page to obtain the attributes of the faulty page; determine whether the faulty page is a transparent large page based on the attributes of the faulty page; if the faulty page is a transparent large page, proceed to step S3; if the faulty page is not a transparent large page, end directly.

[0028] The kernel provides the PageHuge() and PageTransHuge() functions. By combining these two functions, it is possible to determine whether a faulty page is a transparent large page.

[0029] The PageHuge() function is true only for hugebfs pages.

[0030] The PageTransHuge() function is true for both transparent large pages and hugebfs pages. Essentially, it checks PageHead(page) (the head page of a compound page).

[0031] When PageTransHuge(page) == true and PageHuge(page) == false, the faulty page is a transparent large page; in the above function, page refers to the faulty page.

[0032] Step S3: Determine whether the faulty page is a file-mapped transparent large page or an anonymously mapped transparent large page; if the faulty page is an anonymously mapped transparent large page, proceed to the faulty page processing flow to decompose the transparent large page; if the transparent large page is a file-mapped transparent large page, proceed to step S4. Specifically, determining whether a faulty page is a file-backed transparent page or an anonymously mapped transparent page is done using a standard `struct address_space` pointer. This pointer refers to the mapping in the kernel. When used, the kernel retrieves the mapping from the page: `page->mapping` (in Folio, it's `folio->mapping`). If the last bit of the mapping is 0, it represents a file-backed transparent page. If the last bit of the mapping is 1, it represents an anonymously mapped transparent page.

[0033] Step S4: Determine if the faulty page is an unmapped clean, transparent large page; if the faulty page is an unmapped clean, transparent large page (corresponding to...) Figure 3 If the file mapping transparent large page is not an unmapped clean transparent large page, then the faulty page is discarded directly; if the file mapping transparent large page is not an unmapped clean transparent large page, then the transparent large page processing flow is entered to decompose the transparent large page.

[0034] File-mapped transparent large pages have an invalidate fast path: unmapped clean transparent large pages are stored in the page cache and have a disk backup. Therefore, they can be discarded directly (i.e., the faulty page does not need to enter the transparent large page processing flow for migration and decomposition; it can be directly deleted from the page cache management structure, the radix tree). The reason why only mapped clean transparent large pages can pass through the fast path is that if it is a dirty page (i.e., data has not been written back), directly deleting the page will result in data loss; if the page is in a mapped state (i.e., the user-space page table entry PMD (or PTE for ordinary pages) points to the page), deleting the page from the page cache will cause the page table entry to become a dangling mapping, leading to inaccurate data.

[0035] like Figure 3 As shown, the transparent big page processing flow includes four sequential steps (migrate->split->poison->free): first, the old transparent big page is migrated; then, the old transparent big page is decomposed; after decomposition, a fault mark is set for the faulty regular small pages to prevent the memory allocator Buddy from re-allocating them; finally, the regular small pages are released back to the free list of the memory allocator Buddy.

[0036] The specific steps are as follows: Step A1 (migrate step): Mark the faulty page that has entered the transparent large page processing flow as the old transparent large page, and migrate the page content of the old transparent large page to a new transparent large page; During migration, the kernel's existing standard page migration function (migrate_pages function) is used, and the migration_pages function parameters are set to satisfy the allocation of memory from the memory node where the migrated page (old transparent big page) is located to the new memory node, so as to meet the memory allocation performance during the migration process and the memory access performance when accessing the new transparent big page after migration.

[0037] The page content of the old transparent big page is migrated to the new transparent big page. If there is a mapping relationship between the old transparent big page and the process, the mapping relationship is also reset to point to the new transparent big page, so that memory access operations still have the performance advantages brought by transparent big pages: high TLB and cache hit rate, short page table lookup links, etc.

[0038] Step A2 (split step): Break down the old transparent large page into regular small pages.

[0039] After migration, the old transparent large page needs to be released to save memory. If it is released directly to the memory allocator Buddy, it will still be a whole in Buddy's free list. Therefore, when the whole large page containing the faulty small pages is reallocated, it will still trigger a fault. So, the old transparent large page needs to be split into regular small pages first, and then the regular small pages are released independently. This ensures effective memory reclamation and subsequent utilization. The method of splitting transparent large pages can use the try_to_split_thp_page function. Its core principle is as follows: a 2MB / 128MB / 256M compound page (in this example, the old transparent large page) is broken down into 512 independent 4KB / 16KB / 64KB regular small pages, and the page table mapping is updated synchronously.

[0040] Step A3 (poison step): Set up a fault isolation indicator on the fault page within the regular small page.

[0041] When regular small pages are released to the memory allocator Buddy, faulty small pages within them need to be marked with a fault isolation flag to prevent them from being allocated again. When the HWPoison flag is set in the page attribute of the struct page corresponding to the faulty small page, when a memory request is made from the memory allocator Buddy, the system checks the page attribute of the regular small page. If the page attribute contains the HWPoison flag, the request for that regular small page is skipped. This also ensures that faulty small pages do not cause secondary pollution.

[0042] Step A4: Traverse all regular small pages and release them.

[0043] The release process requires iterating through and releasing each of the 512 regular small pages. This is done by manipulating the page descriptors of each regular small page. Since these regular small pages are contiguous, their corresponding page descriptor addresses are also contiguous, allowing for a one-by-one traversal.

[0044] After the above processing steps, the data of the faulty page is migrated to a new page on the memory node where the fault occurred. The page mapping method remains transparent big page, thus ensuring both migration and memory access efficiency. Furthermore, the original faulty data is decomposed, and the smallest faulty page is marked and isolated to avoid accessing it again. This also helps prevent memory waste and secondary contamination caused by the fault.

[0045] The method in this embodiment greatly benefits processes using transparent big pages, such as large database applications or large-scale matrix operations (HPC services) that require requesting and mapping contiguous physical pages (i.e., standard big pages or transparent big page mapping mechanisms). The advantages include fewer TLB misses and page table lookups during memory access. Furthermore, due to the spatiotemporal locality of reference in programs, contiguous physical pages result in better cache hit rates, thus improving overall memory access efficiency. Processes using the method of this invention can still use transparent big pages; only the address mapping relationship is migrated to a new transparent big page. This does not negatively impact the overall performance improvement brought about by the reliance on big pages for the business. Specific Implementation Example 2:

[0047] This embodiment explains why the page descriptor of a fault page can be obtained from the physical address of the fault page based on a CE fault.

[0048] like Figure 1 As shown, vmemmap refers to the virtual address space: in the virtual space of the 64-bit kernel, a huge contiguous region is allocated specifically for it, with the starting address being VMEMMAP_START. Figure 1 The kernel has two virtual address spaces: Section 0 and Section 2. There is a gap between Section 0 and Section 2 (e.g., an address reserved for PCIe devices). The kernel configures page tables for vmemmap. Each page in the page table corresponds to a physical page frame. For example, for Section 0, the page table points its corresponding virtual address (VMEMMAP_START+0) to the physical memory layer (corresponding to...). Figure 1 The page table (in the physical memory layout) stores the physical memory for Section 0. For Section 2, the page table points its virtual address to the physical memory where Section 2 is stored.

[0049] When the kernel starts, it creates a corresponding struct page structure (i.e., page descriptor) for each physical page frame. The array of these structures is called the page metadata area. In the physical memory layer, the page metadata area is specifically stored by the memblock allocator carving out multiple small blocks of physical memory (if the server has a multi-node architecture, these small areas are distributed across their respective nodes).

[0050] Therefore, vmemmap is essentially a contiguous array. When vmemmap+PFN is executed, regardless of how fragmented the physical memory is, the correct struct page structure will be automatically found through the page table.

[0051] Therefore, after the operating system obtains the physical address of the faulty page, it only needs to add the physical page frame number (PFN) corresponding to the physical address of the faulty page to vmemmap to obtain the page descriptor struct page structure.

[0052] Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

Claims

1. A method for handling faults in transparent large pages, characterized in that, Includes the following steps: Step S1: Obtain the page descriptor of the fault page based on the physical address of the fault page of the CE fault; Step S2: Obtain the attributes of the faulty page by parsing the page descriptor of the faulty page; Determine whether the fault page is a transparent large page based on its attributes; If the faulty page is a large transparent page, proceed to step S3; If the faulty page is not a large transparent page, the process will end directly. Step S3: Determine whether the faulty page is a file-mapped transparent large page or an anonymously mapped transparent large page; If the faulty page is an anonymously mapped transparent large page, it will enter the transparent large page processing flow for decomposition and processing. If the faulty page is a large, transparent file-mapped page, proceed to step S4. Step S4: Determine if the faulty page is a clean, transparent, unmapped large page; If the faulty page is a clean, transparent, unmapped large page, then invalidate the faulty page directly. If the faulty page is not a clean, transparent large page that is not mapped, it will enter the transparent large page processing flow for decomposition and processing.

2. The method for handling faults in transparent large pages according to claim 1, characterized in that, In step S2, determining whether a faulty page is a transparent large page based on its attributes is done by combining the PageHuge() and PageTransHuge() functions.

3. The method for handling faults in transparent large pages according to claim 2, characterized in that, When PageTransHuge(page) == true and PageHuge(page) == false, the faulty page is a transparent large page; where page refers to the faulty page.

4. The method for handling faults in a transparent large page according to claim 1, characterized in that, It also includes step S0: when the number of CE failures in the memory within a specified time exceeds the threshold, proceed to step S1.

5. The method for handling faults in a transparent large page according to claim 1, characterized in that, The page descriptor is a structpage structure.

6. The method for handling faults in a transparent large page according to claim 1, characterized in that, In step S3, the determination of whether the transparent page is a file-mapped transparent page or an anonymously mapped transparent page is made by using the struct address_space pointer.

7. The method for handling faults in a transparent large page according to claim 6, characterized in that, The struct address_space pointer refers to the mapping in the kernel.

8. The method for handling faults in a transparent large page according to claim 6, characterized in that, The transparent large page processing workflow includes the following steps: Step A1: Mark the faulty page that has entered the transparent large page processing flow as the old transparent large page, and migrate the page content of the old transparent large page to the new transparent large page; Step A2: Break down the old transparent large page into regular small pages; Step A3: Set a fault isolation flag for the fault pages in the regular small pages; Step A4: Traverse and release all regular small pages.

9. A method for handling faults in transparent large pages according to claim 8, characterized in that, In step A1, the page content of the old transparent page is migrated to the new transparent page using a page migration function.

10. A method for handling faults in transparent large pages according to claim 8, characterized in that, In step A2, the old transparent large page is broken down into faulty small pages using the try_to_split_thp_page function.

Images