A huge page memory management method and system for hierarchical large memory architecture

Abstract

The present invention discloses a huge page memory management method and system for hierarchical large memory architecture, the method comprising: when an application requests memory allocation, if it is a memory allocation based on mmap and the requested memory size is less than the length of a single physical huge page memory, a huge page memory reuse strategy is executed: firstly, whether there is a free memory fragment satisfying a first condition at the head, if so, memory of the requested memory size is allocated to the application; if not, whether the remaining free memory at the tail satisfies the condition, if so, memory of the requested memory size is allocated to the application. The present invention traverses all physical huge page memories allocated to the application to determine whether there is free memory satisfying the requested memory size, so that the requested memory size can be allocated to the used physical huge page memory when the condition is met, thereby making full use of memory space, reducing memory waste, and saving system resources.

Description

Technical Field

[0001] The present invention relates to the technical field of computer operating system performance optimization, and in particular to a huge page memory management method and system for a hierarchical large memory architecture. Background Art

[0002] Memory is one of the most important components in modern computer systems. Data, code and other key contents of program operation need to be loaded into memory before they can be accessed and executed by the processor. In modern computer systems, in order to better manage large memory architectures, virtual memory technology is widely used, especially the paging mechanism. The virtual memory paging mechanism divides physical memory and virtual memory into pages of fixed size, and greatly improves the flexibility of memory management and use by dynamically establishing a mapping relationship between the two pages. However, the virtual-to-real address conversion process in the paging mechanism introduces additional overhead for processor memory access.

[0003] In order to alleviate the overhead of virtual-to-real address conversion, modern processors are generally designed to support larger-granularity pages (from traditional 4k to 2M or even 1G, etc.), and improve application performance by using huge pages to reduce the TLB (Translation Lookaside Buffer) miss rate. For example, the Linux kernel adopts a user-imperceptible TransparentHugePage strategy to manage and allocate huge pages. When the process triggers a page fault interrupt, this strategy automatically allocates and maps physical huge pages for virtual memory that meets the alignment conditions, thereby transparently improving application performance.

[0004] However, Linux's transparent huge page strategy adopts a simple greedy strategy. As long as the virtual memory space meets the requirements for mapping huge pages (i.e., whether the starting address of the virtual memory space is aligned to the huge page size and whether the remaining length of the virtual memory space is greater than the huge page size), huge pages are allowed to be allocated for application use. Such a strategy will lead to great memory waste and memory fragmentation problems, and may also cause the consumption of a large amount of continuous physical memory space in the system, and may also cause the huge pages to be unable to be used in scenarios that really need to use huge pages. In addition, since many applications' memory requests adopt a small amount and multiple allocation mode, each individual memory allocation request does not meet the requirements for using huge pages in the Linux transparent huge page strategy, and thus huge pages cannot be allocated and mapped. But in fact, the sum of these small-scale memory allocation requests exceeds the huge page size. At present, a preset threshold can be set and the kernel can be controlled to map huge pages for memory allocation requests that exceed the threshold. However, this type of threshold-based method still cannot effectively balance the problem of huge page use and memory waste, and the threshold setting is also difficult to determine or set to a fixed value, and needs to be changed frequently, resulting in the actual scope of application of huge pages is still very limited. Many applications cannot actually use huge page memory to improve memory access performance during operation. Summary of the invention

[0005] The technical problem to be solved by the present invention is as follows: In view of the above-mentioned problems in the prior art, a huge page memory management method and system for a hierarchical large memory architecture are provided, so that ubiquitous applications that frequently use small-scale memory can allocate physical huge page memory even when the prerequisites for the use of huge pages are not met, thereby reducing the memory fragmentation and memory waste problems caused by the allocation of huge page memory by the operating system, and improving the utilization rate of huge page memory.

[0006] In order to solve the above technical problems, the technical solution adopted by the present invention is:

[0007] A huge page memory management method for a hierarchical large memory architecture, comprising:

[0008] When an application requests memory allocation, the memory allocation request type is determined. If it is an mmap-based memory allocation and the requested memory size is smaller than the length of a single physical huge page memory, the huge page memory reuse strategy is executed. According to the requested memory size, each physical huge page memory allocated to the application is traversed to find free memory that meets the first condition, and the requested memory size is allocated in the free memory. The first condition is that the size of the free memory is greater than or equal to the requested memory size. The execution steps of the huge page memory reuse strategy are:

[0009] First, determine whether there is a free memory fragment that meets the first condition at the head of the physical huge page memory. If so, allocate memory of the requested memory size to the application from the starting position of the free memory fragment, and move the starting position of the free memory fragment backward by the length of the requested memory size to update the remaining available space of the free memory fragment;

[0010] If there are no free memory fragments that meet the first condition at the head of the physical huge page memory, it is determined whether the remaining free memory at the tail of the physical huge page memory meets the first condition. If so, memory of the requested memory size is allocated to the application from the starting position of the remaining free memory at the tail, and the starting position of the remaining free memory at the tail is moved back by the length of the requested memory size to update the remaining length of the remaining free memory at the tail.

[0011] Furthermore, if no free memory that meets the first condition is found after traversing all physical huge page memories, an aggressive huge page memory allocation strategy is adopted, and one or more new virtual memory spaces with a length of a single physical huge page memory are allocated to the application in the user virtual memory space according to the requested memory size, until the total virtual memory space length is greater than or equal to the length of the requested memory size; a corresponding mapped physical huge page memory is mapped for each virtual memory space, and a huge page description object is created for each physical huge page memory, wherein the huge page description object is used to describe memory usage.

[0012] Furthermore, the aggressive huge page memory allocation strategy specifically includes:

[0013] Determine a first quantity N1 of physical huge page memories to be allocated according to a ratio of the requested memory size to a single physical huge page memory length by rounding up, and determine a first memory size to be allocated according to a product of the first quantity N1 and a single physical huge page memory length;

[0014] Finding a first free virtual memory of the size of the first memory in the user virtual memory space, and creating a vma object for describing the user virtual memory allocation situation;

[0015] Starting from the starting position of the vma object, mapping physical huge page memories to the first free virtual memory in sequence, until the first free virtual memory maps the first number N1 of physical huge page memories respectively, and creating a huge page description object describing memory usage for each physical huge page memory;

[0016] Finally, the first address of the vma object is returned.

[0017] Furthermore, if it is determined that the memory allocation request type of the application is brk-based memory allocation, the following operations are performed:

[0018] Determine whether the new position of the top pointer of the brk area after applying for memory through the brk call and the original position of the top pointer of the current brk area are within the range of the length of a single physical huge page memory. If not:

[0019] The virtual memory interval corresponding to the brk area is expanded through the aggressive huge page memory allocation strategy, so that the top of the virtual memory interval is extended by several memory spaces with a length of a single physical huge page memory, until the new position of the top pointer of the brk area is included in the expanded virtual memory interval;

[0020] Map the corresponding number of physical huge page memories to the newly expanded memory space, and create a huge page description object describing the memory usage for each physical huge page memory;

[0021] Update the top pointer position of the brk area to the new top pointer position of the brk area after the memory is requested through the brk call;

[0022] If it is determined that the new position of the top pointer of the brk area after the memory is applied for through the brk call and the original position of the top pointer of the current brk area are within the range of the length of a single physical huge page memory, then the top pointer position of the brk area is directly updated to the new position of the top pointer of the brk area after the memory is applied for through the brk call.

[0023] Further, if it is determined that the memory allocation request type of the application is memory allocation based on stack extension, the following operations are performed:

[0024] The radical huge page memory allocation strategy is used to expand the virtual memory interval corresponding to the stack area according to the new bottom position of the stack after the stack is expanded, so that the bottom of the virtual memory interval is extended by several memory spaces with a length of a single physical huge page memory until the new bottom position of the stack is included in the expanded virtual memory interval;

[0025] Map the corresponding number of physical huge page memories to the newly expanded memory space, and create a huge page description object describing the memory usage for each physical huge page memory.

[0026] Furthermore, the huge page memory management method for the hierarchical large memory architecture also includes a huge page memory partial release strategy, specifically:

[0027] When requesting memory release, determine whether there is a free memory area that intersects with the memory interval to be released based on the memory interval to be released and the length of the memory to be released to determine the memory area to be released: if there is a free memory area that intersects with the memory interval to be released, merge the memory interval to be released with the free memory area as the memory area to be released, otherwise directly use the memory interval to be released as the memory area to be released.

[0028] Further, judging whether there is a free memory area intersecting with the memory interval to be released before and after according to the memory interval to be released and the length of the memory to be released to determine the memory area to be released, specifically includes:

[0029] Finding a corresponding huge page description object in a huge page linked list of the application according to the starting position of the memory interval to be released, wherein the huge page linked list includes all huge page description objects allocated to the application;

[0030] Determine whether the memory interval to be released covers or partially covers any free memory fragment according to the starting position of the memory interval to be released, the length of the memory to be released, and the starting position and length of all free memory fragments in the header of the huge page description object;

[0031] If the memory interval to be released covers or partially covers any free memory fragments, all the covered or partially covered free memory fragments are merged with the memory interval to be released, the starting address of the merged memory interval to be released is assigned to the starting position, and the length of the merged memory interval is assigned to the length of the memory to be released to obtain the memory area to be released, and all the covered or partially covered free memories are deleted from the free memory fragment list; if the memory interval to be released does not cover the free memory fragments, the memory area to be released is directly determined according to the starting position of the memory interval to be released and the length of the memory to be released.

[0032] Furthermore, the huge page memory partial release strategy also includes:

[0033] According to the starting position of the merged memory area to be released and the length of the memory to be released, it is determined whether the merged memory area to be released intersects with the starting position of the tail of the huge page description object. If they do not intersect, the merged memory area to be released is used as the final memory area to be released; if they intersect, the tail pointer describing the starting position of the tail of the huge page description object is updated to point to the starting position of the merged memory area to be released to update the remaining free memory at the tail, and the updated remaining free memory at the tail is used as the final memory area to be released.

[0034] The present invention also provides a huge page memory management system for a hierarchical large memory architecture, comprising a microprocessor and a memory connected to each other, wherein the microprocessor is programmed or configured to execute the huge page memory management method for the hierarchical large memory architecture.

[0035] The present invention also provides a computer-readable storage medium, in which a computer program / instruction is stored. The computer program / instruction is programmed or configured to execute the above-mentioned huge page memory management method for a hierarchical large memory architecture through a processor.

[0036] Compared with the prior art, the advantages of the present invention are:

[0037] The present invention traverses all physical huge page memories allocated to the application to see whether there is free memory that meets the requested memory size. When the first condition is met, the requested memory size can be preferentially allocated to the used physical huge page memories, thereby making full use of memory space, reducing memory waste, and saving system resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 A schematic diagram of a TLB miss occurring during application memory access.

[0039] Figure 2 Schematic diagram of the TLB performance optimization effect brought by huge page memory.

[0040] Figure 3 This is a schematic diagram of the TransparentHugePage transparent huge page strategy in Linux.

[0041] Figure 4 Schematic diagram of a huge page memory management method for a hierarchical large memory architecture according to an embodiment of the present invention.

[0042] Figure 5 This is a schematic diagram of the huge page memory usage view model in this embodiment.

[0043] Figure 6 Flow chart of the memory reuse strategy in this embodiment.

[0044] Figure 7 Schematic diagram of memory reuse strategy in a specific application embodiment, wherein part (a) is a schematic diagram of placing the requested memory in the head free fragment, and part (b) is a schematic diagram of placing the requested memory in the tail free area.

[0045] Figure 8 It is a schematic diagram of the aggressive memory allocation strategy under three different memory calling modes in a specific application embodiment.

[0046] Fig. 9 It is a flowchart of the aggressive memory allocation strategy under three different memory calling modes in a specific application embodiment.

[0047] Fig.10 This is a flowchart of the partial memory release strategy in this embodiment.

[0048] Fig.11It is a schematic diagram of the partial memory release strategy in a specific application embodiment, wherein part (a) is a schematic diagram of the release process when the area to be released is located at the head of huge page HP3 and does not intersect with the tail of huge page HP3, part (b) is a schematic diagram of the release process when the area to be released is located at the head of huge page HP0 and intersects with the tail of huge page HP0, part (c) is a schematic diagram of the release process when the area to be released is located at the head of huge page HP4 and intersects with the tail of huge page HP4, and part (d) is a schematic diagram of the release process when the area to be released is located at the head of huge page HP4 and does not intersect with the tail of huge page HP4. DETAILED DESCRIPTION

[0049] In order to better understand the above technical solution, the above technical solution will be described in detail below in conjunction with the accompanying drawings and specific implementation methods.

[0050] In traditional computer systems, a single type of memory, such as synchronous dynamic random access memory (SDRAM), is generally used as internal memory. In addition, there are high-bandwidth memory (HBM) and non-volatile memory (NVM) for high-performance computing. Each type of memory technology has corresponding advantages and disadvantages. In order to combine the advantages of various types of memory, a hierarchical large memory architecture technology has emerged in modern operating systems. This memory architecture uses technologies such as CXL (Compute Express Link, open interconnection) to hierarchically interconnect multiple storage technologies according to the access speed, storage cost and other characteristics of each storage technology, and combines non-volatile memory with persistent storage characteristics to achieve key data persistence, forming a hierarchical large memory architecture with large capacity and high performance. In order to better manage the large memory architecture, the operating system needs to be optimized accordingly.

[0051] In modern computer systems, although modern processors have added TLB to assist in the virtual-to-real address conversion in the paging mechanism, Figure 1 As shown in the figure, for memory-intensive applications, there is still overhead caused by TLB misses in converting virtual memory space to physical memory space. Furthermore, the limited capacity of TLB will be even more stretched when facing a hierarchical large memory architecture, making the problem of TLB misses more serious.

[0052] In order to alleviate the overhead of virtual-to-real address translation, huge pages can be used to effectively improve application performance by reducing the TLB miss rate, such as Figure 2 In order to adapt and support the huge page capabilities provided by the hardware, the upper-layer software also needs to provide corresponding huge page management. Taking the Linux kernel as an example, it adopts a user-unaware TransparentHugePage strategy to manage and allocate huge pages, such as Figure 3As shown in the figure, whenever an application requests memory, a corresponding number of huge pages are allocated according to the required memory size. However, this simple allocation strategy will lead to great memory waste and memory fragmentation problems, resulting in the consumption of a large amount of continuous physical memory space in the system, and may also lead to the inability to use huge pages in scenarios that really need to use huge pages. In order to solve the problems caused by the Linux transparent huge page strategy, practitioners have proposed a series of novel and effective memory compression and defragmentation mechanisms to support the effective management of huge pages. In addition, by accurately predicting and selecting the application scenarios that most need huge pages, the over-allocation of huge pages is further avoided.

[0053] However, there is another problem in the Linux transparent huge page strategy. According to the observation and statistics of actual applications, the memory allocation mode of many applications is small amount and multiple times, resulting in each single memory allocation not meeting the requirements of using huge pages. Figure 3 As shown. However, this type of memory allocation mode cannot allocate and map huge pages under the existing Linux transparent huge page policy, but in fact, the sum of these small-scale memory allocation requests exceeds the huge page size. This application scenario is very wide, but currently there is only a strategy that presets a threshold and controls the kernel to map huge pages for memory allocation requests that exceed the threshold. This type of threshold-based method still cannot effectively balance the problem of huge page use and memory waste, and the threshold setting is difficult to determine or set to a fixed value, and needs to be changed frequently.

[0054] In summary, although the huge page mechanism provided by hardware and system software in modern computer systems can improve memory access performance, there are still many limitations in the current operating system's management and use of huge page memory, resulting in a very limited scope of application of huge pages. Many applications cannot actually use huge page memory to improve memory access performance during operation.

[0055] In order to improve the utilization rate and application scope of the huge page memory of the operating system, so that the application program applying for small-scale memory can also obtain the performance improvement brought by the huge page, and at the same time reduce the memory waste and memory fragmentation problems caused by allocating huge pages, the present invention adopts a radical huge page memory allocation strategy when facing the memory allocation application initiated by the user program: facing any memory allocation application initiated by the user program, the system will allocate and map the huge page memory for it, even if the memory allocation application of the user program does not meet the use prerequisites for the huge page in the traditional operating system, the radical huge page memory allocation strategy proposed by the present invention will also allocate huge pages for it. In addition, in order to avoid the huge page memory waste and memory fragmentation problems that may be caused by the radical huge page memory allocation strategy, the present invention also adopts a huge page memory reuse strategy, which can place the memory allocation request of the user program on the huge page that has been allocated to the program and has free space, thereby improving the utilization rate of the huge page and avoiding the memory fragmentation and memory waste problems.

[0056] like Figure 4 As shown, an embodiment of the present invention provides a huge page memory management method for a hierarchical large memory architecture, comprising:

[0057] When an application requests memory allocation, the memory allocation request type is determined. If it is an mmap-based memory allocation and the requested memory size is smaller than the length of a single physical huge page memory, the huge page memory reuse strategy is executed. According to the requested memory size req_size, each physical huge page memory allocated to the application is traversed to find free memory that meets the first condition, and the requested memory size is allocated in the free memory. The first condition is that the size of the free memory is greater than or equal to the requested memory size req_size. The execution steps of the huge page memory reuse strategy are as follows:

[0058] First, determine whether there is a free memory fragment that meets the first condition at the head of the physical huge page memory. If so, allocate memory of the requested memory size req_size to the application from the starting position of the free memory fragment, and move the starting position of the free memory fragment back by the length of the requested memory size req_size to update the remaining available space of the free memory fragment;

[0059] If there is no free memory fragment that meets the first condition at the head of the physical huge page memory, determine whether the remaining free memory at the tail of the physical huge page memory meets the first condition. If so, allocate memory of the requested memory size req_size to the application from the starting position of the remaining free memory at the tail, and move the starting position of the remaining free memory at the tail back by the length of the requested memory size req_size to update the remaining length of the remaining free memory at the tail.

[0060] In a specific application embodiment, each time a corresponding virtual memory space is allocated to an application and a corresponding physical huge page memory is mapped, a huge page usage view model (i.e., a huge page description object hg_unit) needs to be constructed first, that is, for the physical huge page memory allocated and mapped by the operating system for the memory request of the application, a huge page usage view model (e.g., Figure 5 The huge page memory usage view model is a logical abstraction of the huge pages allocated by the operating system to the application. It describes the usage status and idle state of a huge page memory. It is a new logical model concept that is introduced for the first time to describe and record huge page memory in the system. In the cycle after a physical huge page memory is allocated and before it is recycled, the operating system will dynamically record and maintain the specific data structure of the huge page usage view model based on its usage. The construction and maintenance of the huge page usage view model specifically includes the following steps:

[0061] Step A1.1, when the operating system allocates and maps a physical huge page memory to the user virtual memory space, the system will create a data structure object hg_unit for it to describe the usage of the physical huge page memory, and update the data structure members according to the actual memory size requested by the user;

[0062] Step A1.2, when the memory of the allocated physical huge page memory changes, the system will dynamically update and maintain the relevant members of the hg_unit object of the physical huge page memory;

[0063] Step A1.3, when the physical huge page memory is completely released, the huge page description object hg_unit of the physical huge page memory is also released synchronously.

[0064] Specifically, the huge page description object hg_unit described in step A1.1 includes members such as the huge page size h_size, the current idle tail pointer idle_tail (pointing to the starting position of the idle area at the tail of the huge page), the header idle fragment list fragments_list (used to record the idle fragments dynamically and partially released by the user in the header of the huge page), the huge page physical start address start_paddr, and the mapped virtual start address start_vaddr, such as Figure 5 The header free fragment list fragments_list is composed of several free fragments in the header space of the physical huge page memory. Each free fragment is described by a fragment_unit data structure object. Figure 5As shown in the figure, the fragment_unit data structure describes the physical starting position f_start_paddr, virtual starting position f_start_vaddr, and length f_len of a free fragment. By defining the corresponding data structure types, the huge page usage view model is recorded and maintained in the operating system.

[0065] Accordingly, the operating system organizes a huge page memory usage view object list hg_unit_list for each application, which records all physical huge page memories allocated to the application.

[0066] In step A1.2, the change of the allocated physical huge page memory includes: partially releasing the physical huge page memory and reusing the free part of the physical huge page memory. Dynamic update and maintenance of the hg_unit object of the allocated physical huge page memory refers to updating the position of the idle tail pointer idle_tail or deleting or adding nodes in the head free fragment list fragments_list according to the change of the physical huge page memory.

[0067] For the allocated physical huge page memory, there may be free parts in its internal space. Figure 6 The flowchart of reusing free memory is shown. Specifically, the following steps can be used to implement the huge page memory reuse strategy (assuming that the memory size to be allocated this time is req_size):

[0068] Step A2.1, take a physical huge page memory from the huge page linked list allocated by this application, and traverse its head fragment list fragments_list (the allocated huge page linked list refers to a linked list established by the operating system for the user application, which stores all the huge page description objects hg_unit allocated to the program);

[0069] Step A2.1.1, if there is a free fragment object in the list whose length is greater than or equal to req_size, the virtual start address of the fragment is returned to the user as a memory allocation structure, and the operating system synchronously updates the description structure fragment_unit of the free fragment;

[0070] Step A2.1.2: If there is no fragment in the list that meets the requested size req_size, proceed to step A2.2;

[0071] Step A2.2, according to the position of the current tail pointer idle_tail of the physical huge page memory and the huge page size h_size, calculate the length of the remaining free space idle_len at the current tail of the physical huge page memory;

[0072] Step A2.2.1, if the current tail idle length idle_len is greater than or equal to the current request size req_size, then the current tail idle pointer is returned as the user memory allocation result, and the operating system synchronously updates the tail pointer position of the physical huge page memory;

[0073] Step A2.2.2, if the current tail idle length idle_len cannot satisfy the current request size req_size, then the physical huge page memory does not have enough free memory to place the current memory allocation request req_size.

[0074] Specifically, the updating of the free fragment description structure fragment_unit in step A2.1.1 means that after the operating system reuses the free fragment starting from the starting position and the length of req_size and allocates it to the user, the f_start_paddr, f_start_vaddr and f_len members of fragment_unit are adjusted to correctly describe the remaining part of the fragment. Figure 7 As shown in part (a).

[0075] In step A2.1.1, when the current user memory request req_size is exactly equal to the length of a free fragment, the system will directly delete the fragment object from the free fragment list fragments_list at the head of the physical huge page memory.

[0076] Updating the tail pointer of the physical huge page memory described in step A2.2.1 means that after the operating system reuses and allocates the portion of the physical huge page memory starting from the current tail pointer idle_tail position and the length of req_size to the user, the idle_tail member of hg_unit is adjusted to correctly describe the idle portion at the tail of the physical huge page memory. The process is as follows: Figure 7 As shown in part (b).

[0077] In an exemplary specific application embodiment, as Figure 7 The following figure describes the execution process of the huge page memory reuse strategy. Figure 7 The following describes the state changes of a physical huge page memory allocated to an application program after it is reused under two memory allocation requests from the application program. Specifically,

[0078] In step T1, in state 1, the physical huge page memory is in a state of being allocated to the application, and has 2 free fragments and a tail continuous free memory.

[0079] In step T2, when the application's memory allocation request 1 (Req1) arrives, the huge page enters state 2. At this time, the operating system checks the huge page's usage view model based on the huge page memory reuse strategy and finds that the huge page has available free fragments (the second free fragment in the figure).

[0080] Step T3: the operating system locates the available fragment and reuses the free memory of the fragment starting from the starting address and having a length equal to the size of the current memory request to accommodate the current memory allocation request.

[0081] Step T4, the operating system updates the fragment status. If the free fragment length is exactly equal to the length of this memory request, the huge page free fragment description object fragment_unit is deleted from the huge page free fragment list fragments_list. Otherwise, the operating system only updates the fragment start address and fragment length recorded in the fragment_unit. At this time, the huge page state comes to state 3.

[0082] In step T5, when the application's memory allocation request 2 (Req2) arrives, the huge page enters state 4. Based on the huge page memory reuse strategy, the operating system checks the huge page free fragments and finds that there are no available free fragments.

[0083] Step T6, the operating system checks the free memory area at the end of the huge page, and finds that the free area at the end can accommodate the current memory allocation request.

[0084] Step T7, the operating system uses the idle memory starting from the current tail pointer idle_tail and having a length equal to the length of this memory allocation request to place this memory allocation request, and updates the tail pointer idle_tail in the backward huge page hg_unit structure. At this time, the huge page state reaches state 5.

[0085] It should be noted that if a memory allocation request cannot be correctly placed by the huge page free fragments and the huge page tail free area under the huge page memory reuse strategy of the operating system, the huge page memory reuse strategy will return failure. For the subsequent processing of this memory allocation request, the aggressive huge page memory allocation strategy will allocate a new physical huge page memory for the memory allocation request.

[0086] It can be understood that the above huge page memory reuse strategy can allocate the requested memory size to the used physical huge page memory preferentially when the first condition is met by traversing whether there is free memory that meets the requested memory size in all physical huge page memories allocated to the application, thereby making full use of the memory space, reducing memory waste, and saving system resources.

[0087] In this embodiment, if no free memory that meets the first condition is found after traversing each physical huge page memory, an aggressive huge page memory allocation strategy is adopted, and one or more new virtual memory spaces with a length of a single physical huge page memory are allocated to the application in the user virtual memory space according to the requested memory size req_size, until the total virtual memory space length is greater than or equal to the length of the requested memory size; the corresponding physical huge page memory is mapped for each virtual memory space, and a huge page description object hg_unit is created for each physical huge page memory, wherein the huge page description object hg_unit is used to describe memory usage. That is, when the operating system initiates a memory allocation request to the user application, it always responds to the user program request by allocating and mapping the physical huge page memory. Since the memory allocation request types generated by the application during operation are divided into mmap system call, brk system call and passive stack extension, corresponding aggressive huge page allocation strategies can be respectively performed for these three types of memory allocation requests.

[0088] The mmap system call refers to the mmap system call interface for users to apply for memory in the traditional Linux kernel. In order to maintain compatibility and transparency with existing user programs, the present invention implements transparent support for the mmap system call. In this embodiment, the aggressive huge page memory allocation strategy based on mmap (memory mapping) memory allocation specifically includes:

[0089] Step A3.1, the user initiates the mmap system call and requests a memory size of req_size;

[0090] Step A3.2, the operating system checks req_size and determines the size relationship between the requested memory size req_size and the single physical huge page memory length HUGE_SIZE. If the requested memory size req_size is greater than or equal to the single physical huge page memory length HUGE_SIZE:

[0091] Step A3.2.1, determine the first number N1 of physical huge page memories to be allocated according to the ratio of the requested memory size req_size to the length of a single physical huge page memory HUGE_SIZE by rounding up, and determine the first memory size align_size to be allocated according to the product of the first number N1 and the length of a single physical huge page memory HUGE_SIZE;

[0092] Step A3.2.2, find the first free virtual memory of the first memory size align_size in the user virtual memory space, and create a vma object for describing the user virtual memory allocation (the vma object specifically refers to a data structure object in the operating system for recording and describing a section of allocated user virtual memory);

[0093] Step A3.2.3, starting from the starting position of the vma object, mapping the first free virtual memory to the physical huge page memory in sequence, until the first free virtual memory is respectively mapped to the first number N1 of physical huge page memories (that is, the virtual memory space of the entire vma object is mapped);

[0094] Step A3.2.4, returns the first address of the vma object.

[0095] In addition, when the requested memory size req_size is smaller than the single physical huge page memory length HUGE_SIZE, the huge page memory reuse strategy is used to preferentially place the requested memory in the free position of the allocated memory. If no memory can be found to place the requested memory, a new physical huge page memory is allocated. The specific steps are as follows:

[0096] Step A3.3, if the requested memory size req_size is smaller than the single physical huge page memory length HUGE_SIZE:

[0097] Step A3.3.1, according to step S3, find out whether there is free memory that meets the first condition (that is, use the huge page memory reuse strategy to determine a virtual memory location that can be placed and has mapped huge pages for this memory allocation request);

[0098] Step A3.3.2, if there is free memory that meets the first condition, it is allocated to the application and the corresponding virtual memory address is returned;

[0099] Step A3.3.3, if there is no free memory that meets the first condition, find the second free virtual memory of the size of a single physical huge page memory length HUGE_SIZE in the user virtual memory space, create a virtual memory space vma object, start from the starting position of the vma object, map a physical huge page memory for the second free virtual memory, and return the first address of the vma object (that is, enter step A3.2.1, re-search the virtual memory interval vma for this memory allocation request, allocate and map a new physical huge page memory). Among them, the single physical huge page memory length HUGE_SIZE is preferably 2Mbytes.

[0100] In a specific application embodiment, Figure 8 The following is a schematic diagram of the aggressive huge page memory allocation strategy. Fig. 9 This is a flowchart of aggressive huge page memory allocation, where the aggressive huge page memory allocation strategy of mmap is as follows:

[0101] Step L1, the user initiates the first mmap system call Req1, and the request length of the system call is smaller than the single physical huge page memory length HUGE_SIZE;

[0102] Step L2, assuming that the operating system has not yet allocated any huge pages to the application, the system will create a virtual memory interval vma1 for this mmap system call request, and the length of the virtual memory interval is equal to the length of a physical huge page memory HUGE_SIZE;

[0103] Step L3, the operating system allocates and maps a physical huge page memory for the virtual memory interval vma1, and then returns the first address of vma1. At this time, only the initial part of the memory space of vma1 and the huge page allocated to it is used as response1, and the rest is free;

[0104] Step L4, the user initiates a second mmap system call Req2, and the length is also smaller than the single physical huge page memory length HUGE_SIZE;

[0105] Step L5, the operating system checks the huge page usage view linked list of the application program, and if it finds that there is an allocated huge page, it calls the huge page memory reuse strategy for the allocated huge page;

[0106] Step L6: Since the huge page has no free fragments but has enough free areas at the end, the adjacent space on the huge page memory is returned to the user as response 2 according to the huge page memory reuse strategy.

[0107] It should be noted that the "huge page memory reuse strategy" proposed in the present invention is specifically for the mmap system call. When determining which vma it should use, it will give priority to "reusing" the vma that has currently mapped the huge page and has remaining free space, thereby making full use of the memory space, reducing memory waste, and saving system resources.

[0108] In brk-based memory allocation, brk changes the size of the program's heap space. By calling the brk system call, the program can request the operating system to increase or decrease its heap space to dynamically manage memory. In order to maintain compatibility and transparency with existing user programs, the present invention implements transparent support for the brk system call. In the Linux system, the brk area refers to the heap area that always grows upward in the user's virtual memory space, and the top of the area is indicated by a heap top pointer. Generally, the brk area will be described by a vma object (brk_vma), and the brk area will expand from a low address to a high address, that is, brk_vma->vm_end (the heap top of the brk_vma virtual memory interval) will increase dynamically in units of standard pages. In addition, the system will also use the brk pointer to describe the current use position of the brk area, and the brk pointer position must be less than or equal to the brk_vma->vm_end heap top position. In this embodiment, if it is determined that the memory allocation request type of the application is brk-based memory allocation, the following operations are performed (when the user applies for memory through the brk system call, the top pointer of the current brk area is set to old_brk, the top position of the new brk specified by the user is set to new_brk, and the address value of new_brk is greater than the address value of old_brk):

[0109] Step A4.1, determine whether the new position new_brk of the top pointer of the brk area after the memory is requested through the brk call and the original position old_brk of the top pointer of the current brk area are in the same huge page range (referring to the range of the length HUGE_SIZE of a single physical huge page memory). If they are not in the same huge page range:

[0110] Step A4.1.1, the operating system first expands the virtual memory interval brk_vma corresponding to the brk area, so that the top of the virtual memory interval brk_vma is expanded by N2 memory spaces of a length of a single physical huge page memory length HUGE_SIZE, until the new position new_brk of the top pointer of the brk area is included in the expanded virtual memory interval brk_vma;

[0111] Step A4.1.2, the operating system maps a corresponding number N2 of physical huge page memories to the newly expanded memory space, and creates a huge page description object describing the memory usage for each physical huge page memory;

[0112] Step A4.1.3, return the old_brk pointer to the user, and update the top pointer position of the brk area to the new top pointer position new_brk of the brk area after the memory is requested through the brk call;

[0113] In step A4.1.4, if it is determined that the new position new_brk of the top pointer of the brk area after the memory is requested through the brk call and the original position old_brk of the top pointer of the current brk area are located in the same huge page range, then the operating system directly returns old_brk to the user and updates the position of the top pointer of the brk area to the new position new_brk of the top pointer of the brk area after the memory is requested through the brk call.

[0114] In a specific application embodiment, Figure 8 and Fig. 9 Explain the aggressive huge page memory allocation strategy for the brk system call:

[0115] Step M1, the user initiates a brk system call, and sets the top address of the new brk to be new_brk, which is greater than the current old_brk;

[0116] Step M2, the operating system checks the relative position of old_brk and new_brk: if new_brk and old_brk are located in the same huge page memory range, assign the pointer of old_brk to the return address ret_addr, then update old_brk to new_brk, and return ret_addr;

[0117] Step M3: Otherwise, it means that the virtual memory interval brk_vma needs to be extended. The extension length is Len and is calculated according to the following formula (1). Formula (1) represents the difference between the end address of new_brk after aligning it upward to the huge page size and the end address of the current brk_vma virtual memory interval.

[0118] (1)

[0119] In the above formula, It is the new brk area heap top pointer. is the length of a single physical huge page memory, & is the bitwise AND operation, ~ is the bitwise inversion, The end address of the current brk_vma virtual memory range (heap top pointer);

[0120] Step M4, allocating physical huge page memory for the newly extended length Len of brk_vma and mapping them one by one;

[0121] Step M5, assign old_brk to the return address ret_addr, then update old_brk to new_brk, and return ret_addr.

[0122] It should be noted that the virtual memory interval of brk is generally the same vma, so there is no need to use the huge page reuse strategy to reselect vma, and the brk virtual memory interval can be expanded directly. Since the present invention adopts an aggressive huge page memory allocation strategy, the optimization of the brk system call is mainly to modify the "standard page" during native expansion to the huge page size. Therefore, each brk expansion is based on the huge page size, so it is necessary to calculate the tail address of the huge page where new_brk is located, that is, to align new_brk upward to the huge page size, and then you can get the address to which brk should be expanded this time.

[0123] Stack extension refers to the process of extending the stack area in the user virtual memory space from high addresses to low addresses. In the operating system, a stack_vma structure is generally used to describe and record the stack area range. The stack extension behavior is not caused by the user's spontaneous call to a system call, but during the running of the user program, the stack bottom pointer continues to expand beyond the current stack_vma->vm_start (stack bottom). At this time, relevant exception processing will be generated, and stack_vma will be extended in the exception processing. Figure 8 and Fig. 9 As shown, in this embodiment, if it is determined that the memory allocation request type of the application is memory allocation based on stack extension, the following operations are performed (during the running of the application, stack extension behavior occurs, and it is assumed that the new stack bottom position is addr):

[0124] Step A5.1, expand the virtual memory interval corresponding to the stack area according to the new stack bottom position addr after the stack area is expanded, so that the stack bottom of the virtual memory interval is expanded by N3 memory spaces with a length of a single physical huge page memory length HUGE_SIZE, until the new stack bottom position is included in the expanded virtual memory interval; the extended length Len is the current starting address of the stack virtual memory space minus the starting address of the huge page where the address addr causing the current page fault is located, specifically calculated according to the following formula (2):

[0125] (2)

[0126] In the above formula, is the starting address of the stack virtual memory area, is the new bottom position of the stack;

[0127] In step A5.2, a corresponding number N3 of physical huge page memories are mapped to the newly expanded memory space of stack_vma, and a huge page description object hg_unit describing the memory usage is created for each physical huge page memory.

[0128] Similarly, the stack expansion in the present invention also adopts an aggressive huge page memory allocation strategy, and also changes the "standard page" in the native stack expansion process to expansion in units of huge pages. In this process, only the same stack_vma will be used, so there is no need to use the huge page reuse strategy.

[0129] It can be understood that the above-mentioned aggressive huge page memory allocation strategy for three different memory call applications allocates appropriate physical huge page memory to the application according to the memory requirements of the application when the application requests memory allocation. This can enable common applications that frequently use small-scale memory to allocate physical huge page memory even when the prerequisite for huge page use is not met (that is, the amount of memory requested at a single time is less than the minimum requirement for huge page use), greatly improving the scope of huge page memory use and solving the problem that physical huge page memory cannot be allocated and mapped for applications with small-scale memory usage requirements under the existing Linux transparent huge page mechanism.

[0130] In this embodiment, when requesting memory release, it is determined whether there is a free memory area that intersects with the memory interval to be released based on the memory interval to be released and the length of the memory to be released to determine the memory area to be released: if there is a free memory area that intersects with the memory interval to be released, the memory interval to be released and the free memory area are merged as the memory area to be released; otherwise, the memory interval to be released is directly used as the memory area to be released.

[0131] In this embodiment, the huge page memory partial release strategy means that when the allocated physical huge page memory is partially released during the running of the user program, the operating system will not disassemble the relevant huge page memory into standard pages, but continue to maintain the mapping relationship between the part of virtual memory and the complete huge page, and update the free memory on the huge page usage view (that is, the huge page description object hg_unit) to Fig.10 The following is a detailed description of the specific steps of the huge page memory partial release strategy.

[0132] Step A6.1, the user specifies to release the memory space with a length of len starting from address vaddr;

[0133] Step A6.2, the operating system finds the corresponding huge page description object hg_unit in the huge page list of the application according to the starting position vaddr of the memory interval to be released, and the huge page list includes all huge page description objects hg_unit allocated to the application;

[0134] Step A6.3, according to the starting position vaddr of the memory interval to be released, the length len of the memory to be released, and the starting position and length of all free memory fragments in the header of the huge page description object hg_unit, determine whether the memory interval to be released described by (vaddr, len) covers or partially covers any free memory fragment;

[0135] Step A6.3.1, if the memory interval to be released covers or partially covers any free memory fragment fragment_unit, then all the covered or partially covered free memory fragments are merged with the memory interval to be released;

[0136] Step A6.3.2, assign the starting address of the merged memory interval to be released to the starting position vaddr, and assign the length of the merged memory interval to the length of the memory to be released len;

[0137] Step A6.3.3, deleting all the covered or partially covered free memory from the free memory fragment list;

[0138] Step A6.4, according to the starting position vaddr of the merged memory interval to be released and the length len of the memory to be released, determine the position of the merged memory interval to be released described by (vaddr, len) on the huge page:

[0139] Step A6.4.1, if the merged memory interval to be released is located at the head of the huge page and does not intersect with the tail starting position of the huge page description object hg_unit (i.e., the huge page tail pointer idle_tail), then the merged memory interval to be released is used as the final memory interval to be released, and a new node is added to the idle fragment linked list of the huge page hg_unit object to describe the release interval;

[0140] Step A6.4.2, if the merged memory interval to be released intersects with the current huge page tail pointer idle_tail, then the tail pointer idle_tail describing the tail starting position of the huge page description object hg_unit is updated to point to the starting position vaddr of the merged memory interval to be released to update the remaining free memory at the tail, and the updated remaining free memory at the tail is used as the final memory interval to be released.

[0141] In a specific application embodiment, Fig.10 The huge page memory partial release strategy flow chart shown in Fig.11The schematic diagram shown in the figure illustrates the huge page memory partial release strategy. The huge page memory partial release strategy refers to the behavior of an operating system when processing the memory release behavior of an application. Specifically, it refers to the process in which when an application releases the memory space obtained by the aggressive huge page allocation strategy, the operating system updates the free memory area information on the memory usage view of the huge page involved according to the area to be released.

[0142] Step N1, when the user requests to release the to-be-released area 1, the operating system checks the huge page linked list and finds that it covers four huge pages HP0, HP1, HP2, and HP3;

[0143] Step N2, for huge pages HP1 and HP2, they are completely covered by the to-be-released area 1, so the system can release them all;

[0144] Step N3, for huge page HP3, its first half is covered by the to-be-released area 1, and its partial release process is as follows: Fig.11 As shown in part (a);

[0145] Step N3.1, first the system checks that there are free fragments in the free fragment list of HP3 that intersect with the area to be released, then merge all the fragment areas with the area to be released to form the final area to be released;

[0146] Step N3.2, release all these intersecting fragment_unit objects and delete them from the fragment list of the HP3 huge page;

[0147] Step N3.3, create a new fragment_unit object for the newly formed final area to be released and add it to the fragment list of the HP3 huge page;

[0148] Step N3.4, preferably, if the final to-be-released area intersects with the idle tail pointer idle_tail of HP3, the entire huge page is idle and can be released as a whole;

[0149] Step N4, for huge page HP0, its second half is covered by the to-be-released area 1, and its partial release process is as follows Fig.11 As shown in part (b);

[0150] Step N4.1, first the system checks that there are free fragments in the free fragment list of HP0 that intersect with the area to be released, then merges all the fragment areas with the area to be released to form the final area to be released;

[0151] Step N4.2, release all these intersecting fragment fragment_unit objects and delete them from the fragment list of the HP0 huge page;

[0152] Step N4.3, update the tail pointer idle_tail of the huge page HP1 to the starting position of the final area to be released.

[0153] When the user requests to release area 2, the operation is performed as follows:

[0154] Step P1, when the user requests to release area 2, the following two situations can be classified according to the relative position relationship between the area to be released and the huge page HP4:

[0155] Step P2, if the area to be released 2 is located inside the huge page HP4 and intersects with the idle tail pointer idle_tail, its partial release process is as follows Fig.11 As shown in part (c):

[0156] Step P2.1, first the system checks that there are free fragments in the free fragment list of HP4 that intersect with the area to be released, then merge all the fragment areas with the area to be released to form the final area to be released;

[0157] Step P2.2, release all these intersecting fragment_unit objects and delete them from the fragment list of the HP4 huge page;

[0158] Step P2.3, update the tail pointer idle_tail of huge page HP5 to the starting position of the final area to be released;

[0159] Step P3, if the area to be released 2 is located inside the huge page HP4 and does not intersect with the idle tail pointer idle_tail, its partial release process is as follows Fig.11 As shown in part (d):

[0160] Step P3.1, first the system checks that there are free fragments in the free fragment list of HP4 that intersect with the area to be released, then merge all the fragment areas with the area to be released to form the final area to be released;

[0161] Step P3.2, release all these intersecting fragment_unit objects and delete them from the fragment list of the HP4 huge page;

[0162] Step P3.3, create a new fragment_unit object for the newly formed final area to be released and add it to the fragment list of the HP4 huge page.

[0163] It can be understood that the above partial memory release strategy can reuse the allocated physical huge page memory to the greatest extent when releasing memory by judging the intersection of the memory range to be released and the existing free memory area, which can effectively reduce the memory fragmentation and memory waste problems caused by the operating system allocating physical huge page memory, and greatly improve the utilization rate of huge page memory.

[0164] The present invention further provides a huge page memory management system for a hierarchical large memory architecture, comprising a microprocessor and a memory connected to each other, wherein the microprocessor is programmed or configured to execute a huge page memory management method for a hierarchical large memory architecture.

[0165] The present invention further provides a computer-readable storage medium having a computer program / instruction stored therein, wherein the computer program / instruction is programmed or configured to execute a huge page memory management method for a hierarchical large memory architecture through a processor.

[0166] The system and medium product of the present invention correspond to the above method and also have the advantages described in the above method.

[0167] The present invention implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing related hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by the processor, the steps of the above-mentioned method embodiment can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. Computer-readable media include: any entity or device that can carry computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, RandomAccess Memory), electric carrier signal, telecommunication signal and software distribution medium. The memory is used to store computer programs and / or modules. The processor implements various functions by running or executing computer programs and / or modules stored in the memory, and calling data stored in the memory. The memory may include a high-speed random access memory and may also include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card (Flash Card), at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0168] The above is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiments. All technical solutions under the concept of the present invention belong to the protection scope of the present invention. It should be pointed out that for ordinary technicians in this technical field, some improvements and modifications without departing from the principle of the present invention should also be regarded as the protection scope of the present invention.

Claims

1. A huge page memory management method for a hierarchical large memory architecture, characterized in that: include: When an application requests memory allocation, the memory allocation request type is determined. If it is an mmap-based memory allocation and the requested memory size is smaller than the length of a single physical huge page memory, the huge page memory reuse strategy is executed. According to the requested memory size, each physical huge page memory allocated to the application is traversed to find free memory that meets the first condition, and the requested memory size is allocated in the free memory. The first condition is that the size of the free memory is greater than or equal to the requested memory size. The execution steps of the huge page memory reuse strategy are: First, determine whether there is a free memory fragment that meets the first condition at the head of the physical huge page memory. If so, allocate memory of the requested memory size to the application from the starting position of the free memory fragment, and move the starting position of the free memory fragment backward by the length of the requested memory size to update the remaining available space of the free memory fragment; If there are no free memory fragments that meet the first condition at the head of the physical huge page memory, it is determined whether the remaining free memory at the tail of the physical huge page memory meets the first condition. If so, memory of the requested memory size is allocated to the application from the starting position of the remaining free memory at the tail, and the starting position of the remaining free memory at the tail is moved back by the length of the requested memory size to update the remaining length of the remaining free memory at the tail.

2. The huge page memory management method for hierarchical large memory architecture according to claim 1, characterized in that: If no free memory satisfying the first condition is found after traversing all physical huge page memories, an aggressive huge page memory allocation strategy is adopted to allocate one or more new virtual memory spaces of a length of a single physical huge page memory to the application in the user virtual memory space according to the requested memory size, until the total virtual memory space length is greater than or equal to the length of the requested memory size; A corresponding mapped physical huge page memory is mapped for each virtual memory space, and a huge page description object is created for each physical huge page memory, wherein the huge page description object is used to describe memory usage.

3. The huge page memory management method for hierarchical large memory architecture according to claim 2, characterized in that: The aggressive huge page memory allocation strategy specifically includes: Determine a first quantity N1 of physical huge page memories to be allocated according to a ratio of the requested memory size to a single physical huge page memory length by rounding up, and determine a first memory size to be allocated according to a product of the first quantity N1 and a single physical huge page memory length; Finding a first free virtual memory of the size of the first memory in the user virtual memory space, and creating a vma object for describing the user virtual memory allocation situation; Starting from the starting position of the vma object, mapping physical huge page memories to the first free virtual memory in sequence, until the first free virtual memory maps the first number N1 of physical huge page memories respectively, and creating a huge page description object describing memory usage for each physical huge page memory; Finally, the first address of the vma object is returned.

4. The huge page memory management method for hierarchical large memory architecture according to claim 1, characterized in that: If it is determined that the memory allocation request type of the application is brk-based memory allocation, the following operations are performed: Determine whether the new position of the top pointer of the brk area after applying for memory through the brk call and the original position of the top pointer of the current brk area are within the range of the length of a single physical huge page memory. If not: The virtual memory interval corresponding to the brk area is expanded through the aggressive huge page memory allocation strategy, so that the top of the virtual memory interval is extended by several memory spaces with a length of a single physical huge page memory, until the new position of the top pointer of the brk area is included in the expanded virtual memory interval; Map the corresponding number of physical huge page memories to the newly expanded memory space, and create a huge page description object describing the memory usage for each physical huge page memory; Update the top pointer position of the brk area to the new top pointer position of the brk area after the memory is requested through the brk call; If it is determined that the new position of the top pointer of the brk area after the memory is applied for through the brk call and the original position of the top pointer of the current brk area are within the range of the length of a single physical huge page memory, then the top pointer position of the brk area is directly updated to the new position of the top pointer of the brk area after the memory is applied for through the brk call.

5. The huge page memory management method for hierarchical large memory architecture according to claim 1, characterized in that: If it is determined that the memory allocation request type of the application is memory allocation based on stack extension, the following operations are performed: The radical huge page memory allocation strategy is used to expand the virtual memory interval corresponding to the stack area according to the new bottom position of the stack after the stack is expanded, so that the bottom of the virtual memory interval is extended by several memory spaces with a length of a single physical huge page memory until the new bottom position of the stack is included in the expanded virtual memory interval; Map the corresponding number of physical huge page memories to the newly expanded memory space, and create a huge page description object describing the memory usage for each physical huge page memory.

6. The huge page memory management method for hierarchical large memory architecture according to claim 1, characterized in that: The huge page memory management method for hierarchical large memory architecture also includes a huge page memory partial release strategy, specifically: When requesting memory release, determine whether there is a free memory area that intersects with the memory interval to be released based on the memory interval to be released and the length of the memory to be released to determine the memory area to be released: if there is a free memory area that intersects with the memory interval to be released, merge the memory interval to be released with the free memory area as the memory area to be released, otherwise directly use the memory interval to be released as the memory area to be released.

7. The huge page memory management method for hierarchical large memory architecture according to claim 6, characterized in that: According to the memory range to be released and the length of the memory to be released, it is judged whether there is a free memory area that intersects with the memory range to be released before and after to determine the memory range to be released, specifically including: Finding a corresponding huge page description object in a huge page linked list of the application according to the starting position of the memory interval to be released, wherein the huge page linked list includes all huge page description objects allocated to the application; Determine whether the memory interval to be released covers or partially covers any free memory fragment according to the starting position of the memory interval to be released, the length of the memory to be released, and the starting position and length of all free memory fragments in the header of the huge page description object; If the memory interval to be released covers or partially covers any free memory fragments, all the covered or partially covered free memory fragments are merged with the memory interval to be released, the starting address of the merged memory interval to be released is assigned to the starting position, and the length of the merged memory interval is assigned to the length of the memory to be released to obtain the memory area to be released, and all the covered or partially covered free memories are deleted from the free memory fragment list; if the memory interval to be released does not cover the free memory fragments, the memory area to be released is directly determined according to the starting position of the memory interval to be released and the length of the memory to be released.

8. The huge page memory management method for hierarchical large memory architecture according to claim 7, characterized in that: The huge page memory partial release strategy also includes: According to the starting position of the merged memory area to be released and the length of the memory to be released, it is determined whether the merged memory area to be released intersects with the starting position of the tail of the huge page description object. If they do not intersect, the merged memory area to be released is used as the final memory area to be released; if they intersect, the tail pointer describing the starting position of the tail of the huge page description object is updated to point to the starting position of the merged memory area to be released to update the remaining free memory at the tail, and the updated remaining free memory at the tail is used as the final memory area to be released.

9. A huge page memory management system for a hierarchical large memory architecture, comprising a microprocessor and a memory connected to each other, characterized in that: The microprocessor is programmed or configured to execute the huge page memory management method for a hierarchical large memory architecture as described in any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program / instruction stored therein, characterized in that: The computer program / instruction is programmed or configured to execute the huge page memory management method for a hierarchical large memory architecture as claimed in any one of claims 1 to 8 through a processor.

Images