Memory management method, system and device, program product and storage medium

Abstract

The invention provides a memory management method, system and device, a program product and a storage medium, the method is applied to a management function for managing a private memory pool, and the private memory pool is used by a private process; the management function is used for replacing a transparent large page function in an operation system in the operation process of the operation system; the method comprises the following steps: receiving a call request representing that a current process in operation needs to use a transparent large page; and in response to the calling request, if it is determined that the current process is the private process, providing a transparent large page function for the current process through the private memory pool.

Description

Technical Field

[0001] This specification relates to the field of operating system technology, and in particular to memory management methods, systems, devices, program products and storage media. Background Technology

[0002] Traditional operating systems like Linux offer Transparent Huge Pages (THP) functionality. THP allows multiple regular pages to be merged into a single larger page, reducing the likelihood of missing Translation Lookaside Buffer (TLB) cache entries. This means that address mappings can be found faster when accessing memory, thus improving performance. THP includes the `khuged` function, which scans processes to determine if they need to use THP. Processes scanned by `khuged` are often those experiencing page faults; however, processes that have been running stably for a long time in the operating system have a low probability of triggering page faults, making it difficult for these processes to utilize THP. Summary of the Invention

[0003] To overcome the problems existing in related technologies, this specification provides memory management methods, systems, devices, program products, and storage media.

[0004] According to a first aspect of the embodiments of this specification, a memory management method is provided, the method being applied to a management function that manages a private memory pool, the private memory pool being used by a private process; the management function is used to replace the transparent page function in the operating system during the operation of the operating system; the method includes:

[0005] Receives a request from a currently running process that requires the use of a transparent big page;

[0006] In response to the call request, if it is determined that the current process is the private process, the transparent big page function is provided to the current process through the private memory pool.

[0007] According to a second aspect of the embodiments of this specification, the method is applied to an operating system, the operating system including transparent large page functions; the method includes:

[0008] Determine the management functions to be used to manage the private memory pool;

[0009] During operation, the transparent big page function is replaced with the management function so that when the current process running in the operating system needs to use transparent big pages, the management function executes the steps of the method described in the first aspect.

[0010] According to a third aspect of the embodiments of this specification, an operating system is provided for performing the method described in the second aspect.

[0011] According to a fourth aspect of the embodiments of this specification, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method embodiments described in the first or second aspect above.

[0012] According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the method embodiments described in the first or second aspect above.

[0013] According to a sixth aspect of the embodiments of this specification, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method embodiments described in the first or second aspect above.

[0014] The technical solutions provided in the embodiments of this specification may include the following beneficial effects:

[0015] In this embodiment, a private memory pool specifically designed for a particular private process is presented, along with a new management function that enables the private process to use transparent huge pages based on the private memory pool. Since the operating system itself has a transparent huge page function, this embodiment replaces the operating system's transparent huge page function with the management function of this embodiment during operating system operation. Therefore, when the management function is called, it can determine whether the current process requiring transparent huge pages is a private process. If so, it provides transparent huge pages to the current process through the private memory pool. Thus, this embodiment ensures that a specific private process can use the transparent huge page function.

[0016] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0017] Figure 1A This is a flowchart illustrating a memory management method according to an exemplary embodiment of this specification.

[0018] Figure 1B This is a flowchart illustrating a memory management method according to an exemplary embodiment of this specification.

[0019] Figure 2A This is a schematic diagram illustrating a memory large page, a memory small page, and related metadata according to an exemplary embodiment of this specification.

[0020] Figure 2B This is a schematic diagram of a physical machine illustrated in this specification according to an exemplary embodiment.

[0021] Figure 3 This specification is a hardware structure diagram of a computer device containing a memory management device according to an exemplary embodiment.

[0022] Figure 4 This is a block diagram illustrating a memory management device according to an exemplary embodiment.

[0023] Figure 5 This is a block diagram illustrating a memory management device according to an exemplary embodiment. Detailed Implementation

[0024] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this specification as detailed in the appended claims.

[0025] The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of this specification. The singular forms “a,” “the,” and “the” as used in this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0026] It should be understood that although the terms first, second, third, etc., may be used in this specification to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0027] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data shall comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points shall be provided for users to choose to authorize or refuse.

[0028] Transparent Huge Pages (THP) in Linux systems are an important feature of the Linux kernel designed to improve memory management efficiency. It offers the following advantages:

[0029] 1) Reduced TLB misses: THP allows multiple regular pages (typically 4KB) to be merged into a larger page (typically 2MB or 1GB), thereby reducing associated translation back lookup (TLB) misses. This means that when accessing memory, the processor can find the address mapping faster, thus improving performance.

[0030] 2) Improve memory management efficiency: Large page management reduces the workload of the kernel in some cases because fewer pages mean fewer page table entries, thereby reducing the overhead required for memory management.

[0031] 3) Improve memory bandwidth utilization: Since large pages can transfer more data in a single memory operation, THP can improve memory bandwidth utilization, thereby improving application performance.

[0032] 4) Automated management: THP allows the kernel to automatically handle page conversion and management in the background, reducing the complexity of large page management for developers.

[0033] At the same time, THP also has some obvious drawbacks, including:

[0034] 1) Memory fragmentation: Using THP may cause memory fragmentation problems, especially when the system's memory requirements change significantly, which may cause large pages to be used inefficiently.

[0035] 2) Performance fluctuations: In certain scenarios, THP may lead to performance degradation. For example, scanning to merge large pages can incur significant kernel overhead, thus offsetting the performance gains from using large pages.

[0036] 3) Compatibility issues: Some applications or libraries may not support THP, which may cause compatibility issues or instability when using it.

[0037] 4) Management complexity: Although THP is designed to simplify large page management, tuning THP behavior may introduce additional complexity under certain environments or loads.

[0038] While traditional operating systems often utilize the kernel's Transparent Pages (THP) feature to allocate transparent huge pages for processes to improve performance, long-running operating systems suffer from memory fragmentation. Large pages require merging contiguous smaller pages, making it difficult to allocate sufficient large pages to meet this demand, leading to THP memory allocation failures. Pre-reserving a memory pool, if a process doesn't require transparent huge pages, results in wasted memory resources. Furthermore, for existing processes that have been running for some time, their ability to use THP depends on the THP khuge function. This function scans for processes that need THP, but a process's detection often depends on having triggered a page fault. Long-running processes are typically in a stable state, with a low probability of page faults, and may not trigger them for a long time, making it difficult to use THP in real-time.

[0039] Based on this, the embodiments of this specification provide a memory management method that enables specific processes to use the THP function in real time. The embodiments of this specification will now be described in detail.

[0040] like Figure 1A The diagram shown is a flowchart illustrating a memory management method according to an exemplary embodiment of this specification. In this embodiment, a private memory pool is set up for use by specific private processes, and management functions for managing the private memory pool are configured. The operating system (hereinafter referred to as the kernel) originally has the THP function. To enable communication with the private memory pool, this embodiment, described from the perspective of the operating system, may include the following steps:

[0041] In step 112, determine the management function used to manage the private memory pool.

[0042] In step 114, during the operation, the transparent big page function is replaced with the management function so that when the current process running in the operating system needs to use transparent big pages, the management function is executed.

[0043] like Figure 1B The diagram shown is a flowchart illustrating another memory management method according to an exemplary embodiment of this specification. This embodiment is described from the perspective of management functions and may include the following steps:

[0044] In step 122, receive a request indicating that the currently running process needs to use a transparent big page;

[0045] In step 124, in response to the call request, if it is determined that the current process is the private process, the transparent big page function is provided to the current process through the private memory pool.

[0046] To enable specific processes to use the THP function in real time, this embodiment sets up a private memory pool dedicated to private processes, as well as management functions for managing the private memory pool. Since the kernel originally has the THP function, it is necessary to connect the private memory pool with the kernel's THP function, that is, to enable the kernel to use the private memory pool to provide the THP function for private processes.

[0047] As an example, considering the existing operating environment, the kernel's THP function can be replaced with the private memory pool management function of this embodiment through hot patching. The specific hot patching method can be configured according to actual needs, and this embodiment does not limit it.

[0048] As an example, the hot patching process can be performed in either the guest operating system (Guest OS) or the host operating system (Host OS). The execution of management functions can occur in either the guest OS or the host OS.

[0049] In some examples, the timing of private memory pool allocation can be configured as needed; for instance, the private memory pool is allocated from memory by the operating system within a preset time period after the physical machine starts up, based on a set size. This is because when the physical machine first boots up, the memory space is usually relatively empty, with less fragmentation, and there is a higher probability that a private memory pool can be allocated. The preset time period can be set as needed, and this embodiment does not limit it. As an example, the management function in this embodiment includes a private memory pool allocation function. For existing operating systems, hot patching can be used directly, followed by executing the allocation function to allocate the private memory pool. For incremental cases, hot patching can be performed within a preset time period after the physical machine starts up. After the hot patch, the allocation function in the management function is executed, thereby requesting the guest operating system to allocate the private memory pool.

[0050] The kernel typically manages the memory space allocated to processes in 4KB granularity. In this embodiment, the memory pages managed by the kernel are referred to as small pages. Large pages in the private memory pool have a larger granularity, such as 2MB or 1GB, and can be configured as needed in practical applications. Optionally, each large page in the private memory pool consists of multiple contiguous small pages. On the host operating system side, the large pages in the private memory pool can be contiguous or non-contiguous; this embodiment does not impose any limitations on this. From the perspective of the guest operating system, the large pages in the private memory pool are contiguous because, on the host side, the contiguousness of the private memory pool is transparent to the guest.

[0051] As an example, the management functions include allocation functions for private memory pools and deallocation functions for private memory pools; the transparent big page functions include memory allocation functions, memory deallocation functions, and a scan function for scanning the memory space of a process to determine whether the process needs to use transparent big pages;

[0052] Specifically, the memory allocation function is replaced with the allocation function of the private memory pool, and the memory release function is replaced with the release function of the private memory pool; the information of the private process is added to the scan list of the scan function.

[0053] As an example, the kernel's THP function can include multiple functions, such as memory allocation functions, memory deallocation functions, and the khuged scanning function, etc. The kernel's THP function can be replaced or modified according to actual needs. For example, the memory allocation function in the kernel's THP can be replaced with the allocation function of the private memory pool in this embodiment; the memory deallocation function in the kernel's THP can be replaced with the deallocation function of the private memory pool in this embodiment. The replacement in this embodiment can refer to the replacement of function paths, that is, the original call to the kernel's THP function is changed to a call to the management function of the private memory pool in this embodiment. As an example, the above function replacement can be implemented through hot patching.

[0054] The `khuged` function is used to scan whether small memory pages can be merged into larger memory pages. This function scans the memory space of each process and determines if multiple memory pages can be merged into a larger page. If so, it triggers the kernel's THP allocation function `khugepaged_alloc_page`. The `khuged` function has a scan list to record processes that have been scanned and can be merged into larger pages. When a function replacement is performed, the `khuged` function may have already been scanned, and some records may already exist in the scan list. Therefore, this embodiment allows for hot patching by replacing the function path and simultaneously adding the private process information to the `khuged` function's scan list. This enables the `khuged` function to trigger the private process to use the THP function by scanning the records in the list. For example, the added process information can be the process name or the kernel's process identifier (PID).

[0055] Optionally, other processing can be performed during hot patching. For example, the scan function `khuged` can have scan rules, which need to be pre-set during kernel compilation to take effect; otherwise, they will not be effective. Therefore, during hot patching, the scan rules and other functions of the `khuged` function can be enabled as needed to ensure their effectiveness. Furthermore, the scan rules can record the process's scan priority, the scan priority of code segments and data segments in the process's memory space, etc.; the scan rules can also be modified as needed during hot patching. Specific modification rules can be configured as needed; for example, the private process in this embodiment can be set to have the highest scan priority, etc., but this embodiment does not limit this.

[0056] After replacing the operating system's transparent huge page function with a private memory pool management function, when a process in the operating system needs to use transparent huge pages, the private memory pool management function can be called, thus receiving the call request. If the management function determines that the current process needing to use transparent huge pages is a private process, it can provide transparent huge page functionality to the current process through the private memory pool.

[0057] To efficiently manage a private memory pool, several structures are required. The following structures and the information they record are for illustrative purposes only and can be modified flexibly according to actual needs.

[0058] (1) Existing structures in the kernel;

[0059] ① Kernel process structure task; The kernel configures a process structure for each process. In operating systems such as Linux, it is usually task_struct. In this example, it is called the kernel process structure task. This structure contains all the information of the process.

[0060] ② The page structure for a small page in memory; the kernel configures a page structure for each page to record page information.

[0061] (2) The structure created in this embodiment;

[0062] ① Metadata related to private processes;

[0063] As an example, each private process has a private process structure item; each item has an identifier (referred to as item identifier in this embodiment), and each item can record one or more of the following information: process name, current status of using the private memory pool (e.g., enabled, disabled, or paused), and the number of memory pages currently used. All private process structure items can be organized in a process metadata, and the data structure of the process metadata can be of type such as a linked list.

[0064] In this embodiment, considering that the page structure of the memory small page has free bits, such as the lower 3 bits, the item identifier of each item is recorded in the page structure of the memory small page.

[0065] ② Metadata related to the private memory pool;

[0066] As an example, a memory pool structure can be created for a private memory pool, which can record one or more of the following information: the actual number of memory pages (representing the actual size of the memory pool), the expected number of memory pages (representing the expected size of the memory pool), or the number of memory pages that have been used.

[0067] A bitmap can be created for a private memory pool, which represents the allocation status of each memory page in the private memory pool; for example, each bit in the bitmap corresponds to a memory page in the private memory pool, and the value stored in each bit represents the allocation status of the corresponding memory page.

[0068] ③ Metadata related to memory giant pages of the private memory pool;

[0069] As analyzed above, each memory big page is essentially composed of multiple consecutive memory small pages (from the kernel's perspective). In the kernel, the kernel creates a page structure for each memory small page to record the information of each memory small page.

[0070] As an example, please see Figure 2B The diagram illustrates memory large pages, memory small pages, and related metadata. For simplicity, the diagram uses three memory large pages as an example; in practical applications, the number of memory large pages in a private memory pool can be configured arbitrarily as needed. For simplicity, each memory large page is illustrated as containing three memory small pages; it can be understood that in a real-world scenario, if a memory small page is 4KB and a memory large page is 2MB, one memory large page can contain 512 memory small pages. Each memory small page has a corresponding page structure, for example... Figure 2B The page structure 11 corresponding to memory page 11 is shown in the diagram; the others are similar. Each page structure is stored in memory and has a storage address. The information stored in each page structure includes the memory address of the corresponding memory page.

[0071] In this embodiment, a page structure can also be created for each memory large page. Specifically, the page structure of the memory large page can contain the storage address of the page structure of the first memory small page that constitutes the memory large page.

[0072] In this embodiment, an array can be created, where each element corresponds to a memory page. Each element can record the Page structure of each memory page. Specifically, the Page structure of a memory page can refer to the storage address of the Page structure of the first memory page that constitutes the memory page.

[0073] For example, element 1 corresponds to a large memory page, which contains small memory pages 11, 12, and 13. The information recorded in element 1 can be the Page structure of the large memory page 1, and the Page structure of the large memory page 1 can be the information of the Page structures of each small memory page of the large page, such as the storage address of Page structure 11, Page structure 12, and Page structure 13. Optionally, since the small memory pages are contiguous, the Page structures are also stored contiguously. Therefore, the information recorded in element 1 can be the storage address of any one of these three Page structures. For example, element 1 records the storage address of the first Page structure, namely Page structure 11. Through this storage address, Page structure 11 can be accessed, and the memory address of small memory page 11 can be obtained from Page structure 11. Thus, the memory addresses of small memory pages 12 and 13 can be calculated.

[0074] Based on this, the aforementioned data allows for efficient management of the private memory pool. As an example, if the current process is determined to be a private process, providing transparent huge-page functionality to the current process through the private memory pool includes:

[0075] Create process metadata, which is used to store the private process structure of the private process; the private process structure records the process name of the private process;

[0076] After obtaining the kernel process structure of the current process in the operating system, the process name of the current process is obtained from the kernel process structure;

[0077] If the process metadata contains a private process structure that records the process name of the current process, the current process is determined to be the private process, and the transparent big page function is provided to the current process through the private memory pool;

[0078] The method may further include:

[0079] If the process metadata does not contain a private process structure that records the process name of the current process, determine whether to call the transparent big page function of the operating system, in order to determine whether to provide transparent big page functionality to the current process through the transparent big page function.

[0080] Since the private memory pool is used only by specific private processes, taking Linux as an example, the memory allocation function called by THP is usually the khuged function under THP. That is, the caller of the call request received by the management function in this embodiment can be the khuged function. The call request can include parameters, such as information about the current process. Therefore, it can be determined whether the current process is a private process. If so, transparent huge page functionality can be provided to the current process through the private memory pool. If it is not a private process, further processing can be performed according to actual needs. For example, it can return null, and the current process does not use transparent huge page functionality. Alternatively, it can be determined whether to call the kernel's transparent huge page function to determine whether to provide transparent huge page functionality to the current process through the transparent huge page function. The strategy for whether to call the kernel's transparent huge page function can be flexibly configured according to actual needs, and this embodiment does not limit it in this way.

[0081] As an example, this embodiment uses process names to distinguish whether a process is a private process. Normally, the kernel uses process PIDs to distinguish processes. This embodiment does not use process PIDs because processes may undergo upgrades or unexpected crashes, causing the PID to change. Based on this, the process structure `item` created in this embodiment records the process name. Then, by using parameters passed in the call request, the kernel process structure `task` of the current process is obtained, and the process name of the current process is retrieved from this kernel process structure `task`. If the process name of the current process is recorded in the process metadata, it can be determined that the current process is the private process, and transparent huge page functionality is provided to the current process through the private memory pool. If not, it can be determined whether to call the transparent huge page function of the guest operating system to determine whether to provide transparent huge page functionality to the current process through the transparent huge page function.

[0082] The "determining whether to invoke the operating system's transparent huge page function" can be understood as a switch function, which can be configured with various strategies to determine whether to invoke the transparent huge page function or not. Specific strategies can be configured according to actual needs, and this embodiment does not impose any limitations on them. Based on this, this embodiment can ensure that transparent huge page functionality based on a private memory pool is provided for private processes, while for non-private processes, a flexible strategy can be used to determine whether to use the kernel's existing transparent huge page functionality.

[0083] In some examples, providing transparent huge page functionality to the current process through the private memory pool includes:

[0084] If it is determined that there exists a target memory page in the private memory pool that can be allocated to the current process, the target memory page is returned to the caller that initiated the call request;

[0085] The method may further include:

[0086] If it is determined that there is no memory big page in the private memory pool that can be allocated to the current process, it is determined whether to call the transparent big page function of the operating system, so as to determine whether to provide transparent big page functionality to the current process through the transparent big page function.

[0087] As an example, each large memory page in the private memory pool can be obtained by merging multiple consecutive small memory pages managed by the operating system.

[0088] In this embodiment, the caller of the request can be the `khuged` function. If the current process is determined to be a private process, it can query the private memory pool for a free target memory page. If allocation is successful, the corresponding memory pages can be returned to the caller, allowing the current process to use the target memory page. If allocation fails, it can determine whether to call the operating system's transparent big page function to provide transparent big page functionality to the current process. Typically, one target memory page is used in a single call.

[0089] Based on this, this embodiment allows for prioritizing the allocation of memory big pages from the private memory pool according to the needs of the private process. If allocation fails, it dynamically determines whether to use the kernel's transparent big page, ensuring that the private process can utilize the transparent big page function as much as possible.

[0090] In some examples, the step of returning the target memory page to the caller who initiated the call request if it is determined that a target memory page exists in the private memory pool that can be allocated to the current process includes:

[0091] Create an array, where each element stores the storage address of the page structure of each memory giant page; for example, the information of the page structure of the memory giant page stored here may specifically be the storage address of the page structure of the first memory minor page corresponding to the memory giant page;

[0092] Create a bitmap that represents the allocation status of each memory maxpage in the private memory pool;

[0093] If an unallocated target memory page is found in the bitmap, the allocation status of the target memory page is set to allocated in the bitmap, and the information of the page structure of the target memory page is retrieved from the array. The retrieved information is then returned to the caller who initiated the call request. For example, after retrieving the storage address of the page structure of the target memory page, the retrieved storage address is returned to the caller who initiated the call request.

[0094] In this embodiment, the caller initiating the request belongs to an existing kernel function, such as the `khuged` function. If a large memory page can be successfully allocated, the `khuged` function can return information about the `page` structure of the target large memory page. Based on this, this embodiment uses a bitmap to represent the allocation status of each large memory page in the private memory pool, thereby quickly determining whether a target large memory page exists that can be allocated to the current process. Simultaneously, an array is created, with each element storing the storage address of the `page` structure of the corresponding small memory page. As mentioned above... Figure 2B As shown, if it is found that memory page 2 can be allocated to the current process, the allocation status of memory page 2 in the bitmap is set to allocated. Then, the storage address of the recorded page structure 21 can be retrieved from element 2 of the array, and the storage address of page structure 21 is returned to the caller. The caller accesses page structure 21 through the storage address of page structure 21, and can determine through calculation that memory pages 21 to 23 are memory pages allocated to the current process.

[0095] Based on this, this embodiment can quickly and accurately allocate memory pages to the current process through the above processing, and can accurately and efficiently manage the private memory pool.

[0096] In some examples, the private process structure is also used to record the number of memory pages used by the process; the private memory pool corresponds to a memory pool structure, which is used to record the number of memory pages used by the private memory pool; the page structure has free bits; the method further includes:

[0097] Increment the number of memory pages used by the process recorded in the process structure item of the current process by 1;

[0098] Increment the number of memory large pages used recorded in the memory pool structure by 1;

[0099] Record the identifier of the private process structure of the current process in the free bit of the page structure of the target memory page.

[0100] In this embodiment, to manage the private memory pool more efficiently, after allocating large memory pages from the private memory pool to the current process, the information recorded in other structures mentioned in the previous embodiments can be updated. By updating the number of large memory pages used by the process recorded in the process structure item, the number of large memory pages used by each private process can be accurately recorded. By updating the number of large memory pages used recorded in the memory pool structure, the usage of large memory pages in the private memory pool can be accurately recorded, and the private memory pool can be expanded or shrunk. By recording the item identifier of the current process's process structure item in the free bit of the page structure of the small memory page corresponding to the target large memory page, the free bit of the page structure can be reused, and the association between the small memory page and its private process can be established.

[0101] In some examples, when freeing large pages of memory allocated to a private process, the method may further include:

[0102] In response to receiving a request to release a large memory page to be released, the storage address of the page structure of the large memory page to be released is obtained from the release request;

[0103] Check if the array contains a target element that records the storage address of the page structure of the large page of memory to be released;

[0104] If so, clear the large page of memory to be released corresponding to the target element, and clear the target item identifier recorded in the free bit of the page structure of the large page of memory to be released;

[0105] Based on the target identifier, the corresponding target private process structure is found from the process metadata, and the number of memory pages used by the process recorded in the target private process structure item is reduced by 1;

[0106] Decrement the number of memory large pages used recorded in the memory pool structure by 1;

[0107] Set the allocation status of the large memory page to be released recorded in the bitmap to unallocated.

[0108] As an example, if the target element of the page structure that records the storage address of the memory giant page to be released is not found in the array, it means that there may be a problem with the release of the memory giant page of the private memory pool at this time, and information such as null or error can be returned to the initiator of the release request.

[0109] Similar to the process of allocating large memory pages to private processes, this embodiment also updates the information recorded in the relevant structures upon release, thereby enabling efficient and accurate management of the private memory pool.

[0110] In practice, more interfaces can be set up for the private memory pool as needed:

[0111] As an example, a size setting interface can be provided for setting the memory size of the private memory pool; through this interface, the private memory pool can be expanded or shrunk in the following ways: for example, in response to the current expected size of the private memory pool received through the size setting interface, the number of memory big pages contained in the private memory pool is adjusted based on the current actual size of the private memory pool and the current expected size.

[0112] As an example, the private process setting interface can be used to obtain which processes are private processes. This interface can be used to add or delete private processes, thereby enabling the addition or deletion of private process information recorded in the khuged function.

[0113] The private memory pool in this embodiment can be reclaimed in several ways, such as through the kernel as mentioned above. However, since the private memory pool is allocated by the kernel, it is always in use from the kernel's perspective. If the kernel wants to reclaim the private memory pool, it needs to use methods such as memory compression or disk reclamation, which is inefficient and wastes storage space. Therefore, this embodiment can also implement the reclamation of the private memory pool based on the virtualization layer.

[0114] For example, through the virtualization layer, the aforementioned operating system is switched to a guest operating system, with the virtualization layer taking over the management of the physical machine's hardware resources. Therefore, the private memory pool originally allocated by the operating system can be used by the guest operating system through virtual memory by the virtualization layer. This allows the virtualization layer to reclaim the actual physical pages of the private memory pool and allocate new physical pages to the guest operating system when needed, thus reducing memory waste.

[0115] The method may further include: in response to determining that idle large memory pages awaiting reclamation in the private memory pool need to be reclaimed, triggering the virtualization layer to perform a reclamation operation; the virtualization layer is used to switch the operating system from root mode to virtualization mode, so that after the operating system switches to guest operating system, it queries the private memory pool for idle large memory pages awaiting reclamation, and processes the page table entries corresponding to the large memory pages awaiting reclamation, so that the large memory pages awaiting reclamation are reclaimed by the virtualization layer; and if the virtualization layer receives a page fault exception triggered by the guest operating system using reclaimed large memory pages from the private memory pool, it allocates new physical pages and establishes a page table mapping with the reclaimed large memory pages, so that the guest operating system can use the new physical pages based on the page table mapping.

[0116] As an example, the IOMMU (Input-Output Memory Management Unit) page table manages device (such as PCI devices) access to memory, mapping virtual addresses generated by the device to physical addresses. Clearing the IOMMU page table means removing the device's access rights to that large page of memory, ensuring that the memory is no longer used by the device.

[0117] EPT stands for Extended Page Table, used in Intel Virtualization technology for Level 2 address translation to manage virtual machine (guest operating system) access to physical memory. High-order bits are marked to help the virtualization layer identify that the page originates from a private memory pool, allowing for special handling in future memory operations.

[0118] As an example, a management function could determine whether to reclaim idle large pages of memory in the private memory pool. Alternatively, a memory reclamation function could be configured within the virtualization layer to determine whether a memory page is eligible for reclamation based on its hot or cold state. The management function could determine that reclamation is necessary and then trigger the virtualization layer to perform the reclamation. Alternatively, other methods could be used to trigger the virtualization layer to switch the operating system from root mode to virtualization mode, after which the virtualization layer would determine that large pages of memory need to be reclaimed and then perform the reclamation operation.

[0119] If a large memory page is determined to need to be reclaimed, this embodiment refers to the large memory page to be reclaimed as the large memory page to be reclaimed. First, after determining that it belongs to the private memory pool, the large memory page to be reclaimed is found to be in an idle state through a bitmap query. A flag can be set to indicate that the virtualization layer is currently operating on the large memory page to be reclaimed, thus preventing changes in the state of the large memory page to be reclaimed during processing. In this way, if the guest operating system happens to be executing the allocation function of the private memory pool, it will see this flag and pause, waiting for the flag to disappear.

[0120] Afterwards, the virtualization layer can directly reclaim the large memory page, clear the IOMMU page table, clear the EPT page table, and mark the EPT page table entries, such as writing a mark in the free bit or high bit, to indicate that it comes from a private memory pool. At this time, the actual physical page of the large memory page to be reclaimed is reclaimed by the virtualization layer, and the virtualization layer does not need to perform data swapping operations.

[0121] Similarly, in the guest operating system, when a virtual memory big page that does not correspond to an actual physical page is allocated to a process and read / write operations occur, a page fault will be triggered. The virtualization layer can perform a swap-in operation. First, it reads the EPT page table entry that triggered the page fault and determines whether its high bits contain a flag indicating that it originates from a private memory pool. If it belongs to a private big page pool, a new physical memory big page is allocated directly, and an EPT mapping is established without needing to swap in additional memory data. At the same time, the corresponding IOMMU page table is then established, greatly simplifying the swap-in process.

[0122] Based on this, the above embodiments employ a virtualization layer, which can efficiently perform page reclamation and page swapping in of the private memory pool, while also avoiding the waste of storage resources.

[0123] The following example will illustrate the point.

[0124] First, in order to enable the kernel's THP big pages and private memory pool to be interconnected, while taking into account the existing operating environment, the interconnection can be achieved through hot patching (also known as hot patching).

[0125] The kernel THP allocation path can be routed to a private memory pool. The kernel's THP function includes multiple functions; the transparent huge page allocation function under the THP function can be replaced with the new private memory pool allocation function of this embodiment. Since any process in the kernel may need to use THP, the allocation function in this embodiment can determine whether the process needing huge page allocation is a private process allowed to use the private memory pool. That is, it filters the processes in the kernel that need to use THP; only allowed private processes in this embodiment can allocate huge pages from the private memory pool; otherwise, it can return null.

[0126] Optionally, this embodiment adds a switch option to determine whether to revert to the kernel's original transparent huge page function. For example, in the event of a private memory pool allocation failure, it determines whether to revert to the kernel's original transparent huge page function, allowing the kernel to continue attempting to allocate transparent huge pages for the process using its original transparent huge page function. As an example, some processes may need to limit their memory usage, such as processes related to DPDK (Data Plane Development Kit) or SPDK (Storage Performance Development Kit). Since the memory usage of these processes typically doubles during hot patching, using THP will increase memory usage for these processes. Therefore, the use of transparent huge pages can be restricted for these processes, and reverting to the kernel's transparent huge page function is not necessary. Of course, in real-world scenarios, whether a private process reverts to the kernel's transparent huge page function in the event of a private memory pool allocation failure can be flexibly configured as needed, and this embodiment does not impose any limitations on this.

[0127] Functions under the kernel's THP function can include the initial THP memory allocation function do_huge_pmd_anonymous_page, as well as the related khuged (page merging process) memory allocation function khugepaged_alloc_page, etc. These functions can be replaced with the management functions of the private memory pool in this embodiment, such as the allocation function of the private memory pool.

[0128] Where there is allocation, there will be release. The release function free_transhuge_page under the kernel THP function can also be called into the management function of the private memory pool in this embodiment, that is, the release function of the private memory pool.

[0129] Since private memory pools apply to private processes, in addition to the path replacement mentioned above, the khuged function under the kernel's THP feature is a scanning function that determines whether a scanning process needs to use THP. This function can also be controlled. By default, it can only allow page merging scans on private processes and ignore other processes. Of course, it can also be controlled to fall back to the scanning range generally allowed by the kernel through a switch.

[0130] In practical applications, when performing hot patching in this embodiment, the kernel may already contain a scan list, a list of scanned processes, which can modify the process scanning traversal function of khuged. For example, it can be modified to scan processes that meet the scan level rules based on the set scan level (usually only private processes are allowed to be scanned) or scan priority (e.g., private processes are scanned first).

[0131] Furthermore, during hot patching, a private process that needs to perform memory merging and use big pages may not yet be in the khuged scan queue. The kernel's original logic will only add it to the scan queue when a page fault occurs later. This interval is uncontrollable, and it may even take a long time before the process is added. Therefore, this embodiment also provides an interface for setting private processes. This interface can obtain private processes and add them to the scan list of the kernel's scan functions. As an example, processes can be added using keywords such as process name or process PID.

[0132] Khuged's scanning capabilities include scanning both code and data segments. However, these two functions may not be enabled automatically in the kernel; it's possible that a certain function wasn't selected during kernel compilation. Therefore, hot patching can enable these two functions. Alternatively, for example, when a page fault is triggered, hot patching can add process information to the code segment scanning queue.

[0133] In practical applications, the functions that the scanning function depends on may be incomplete due to reasons such as unconfigured compilation options. If the function depends on core functions, necessary dependent functions can be added through hot patching to configure all dependent core functions and thus complete the functionality. Conversely, some auxiliary functions may be missing, such as functions used for auxiliary purposes like data statistics. These do not affect the main functionality and can be skipped during hot patching. Core functions are those that must be executed when using transparent big page functionality, such as the `khuged` function or the transparent big page allocation function. Dependency functions are those that are called and used by other functions or modules. These functions provide support and necessary operations for core functions or other critical functions. Auxiliary functions, or non-critical functions, are those that provide additional support or extended functionality, usually used to implement secondary functions or enhance system functionality, but are not essential parts of system operation.

[0134] Next, an implementation example of managing a private memory pool will be described.

[0135] In this embodiment, the private memory pool is used by private processes. Therefore, it is necessary to filter out private processes. An interface for configuring private processes can be provided to the outside world, allowing processes to join or leave the filter. As an example, a process structure item can be created for each private process. Each item has its own unique ID (to reduce complexity, the ID is usually not 0 and can be stored in the lower 3 bits of the page structure). This item can record: process name (process pid is not selected because the process may be upgraded or crash unexpectedly, causing the pid to change), the current status of the item (whether it is enabled, disabled, or paused, etc.), and the number of large memory pages currently used. A linked list can be created to store all items.

[0136] A private memory pool requires a fixed number of memory pages to be pre-allocated, and an interface can be provided to set the memory size of the private memory pool. Through this interface, the expected size (which can be represented by the predicted number of memory pages) set for the private memory pool by the requester (the requester can be any entity, and can be configured as needed in practice) can be obtained, thereby triggering the allocation or release of memory in the private memory pool. For example:

[0137] a) It can record the current number of memory pages in the private memory pool (which represents the current actual size of the private memory pool) and the expected number of memory pages obtained through the interface (which represents the current expected size of the private memory pool); expansion and contraction can be decided by comparing these two values; in addition to recording the expected size and actual size of the private memory pool, it can also record the number of memory pages that have been allocated.

[0138] b) If the current expected size obtained through the interface is greater than the current actual size of the private memory pool, you can try to allocate memory big pages to expand the capacity; of course, it is also possible that the expected number cannot be allocated, in which case you will only try your best to allocate.

[0139] c) If the current expected size obtained through the interface is less than the current actual size of the private memory pool, you can try to release some large memory pages to shrink the pool; similarly, there may be situations where large memory pages are being used and cannot be released, in which case you should try to release them as much as possible.

[0140] To manage large pages in a private memory pool, an array can be created. Each element in the array corresponds to a large page and records the values ​​of the pages contained within it (considering that a large page is formed by merging multiple consecutive pages, the address of the page structure of the first page among these pages can be recorded). If the array stores the address of a page structure, it means that a large page has been allocated; if the array is empty, it means that there is no large page yet.

[0141] A bitmap can also be used to manage the allocation status of memory pages to private processes, with each memory page corresponding to one bit in the bitmap; a value of 1 indicates unallocated, and 0 indicates allocated. For allocated memory pages, the lower 3 bits (all lower 3 bits are 0) of the page structure of each page contained within the memory page can be used to record the process information (represented by the process's itemID).

[0142] The allocation function for the private memory pool, after the kernel calls this function via a hot patch:

[0143] a) First, the kernel process structure task of the current process can be obtained;

[0144] The allocation function for the private memory pool can be called by the khuged function. The khuged function can be passed a scan structure mm_slot, from which the kernel process structure task of the current process to be used THP can be obtained. Then, the process name is obtained from the comm field in the kernel process structure task. Based on the process name, it is determined whether the current process belongs to a private process.

[0145] b) If the aforementioned linked list contains a target item that records the process name obtained above, then you can try to request a large page of memory from the private memory pool; you can traverse the bitmap, for example, query the first position of the bitmap that is set to 1;

[0146] c) If the position to be set to 1 is successfully found, the request is successful, and a target memory page that can be allocated to the current process is obtained. The position in the bitmap can be set to 0.

[0147] d) Increment the number of memory pages used by the current process's item record by 1; Increment the total number of memory pages used by the private memory pool's structure by 1;

[0148] e) Store the ID of the private process structure item of the current process into the lower three bits of the page structure of the target memory page, update the array element that records the page structure, and return the storage address of the page structure to the kernel's THP function.

[0149] f) If allocation fails, a null value can be returned, and the aforementioned switch determines whether to fall back to the original allocation path in the kernel.

[0150] 6. The release function for the private memory pool: After the kernel enters the release interface via hot patching:

[0151] a) Since multiple functions under the kernel's THP call the function in this embodiment, the caller's situation is quite complex. It may be called by the current private process, the khuged process, or a cache-related cleanup process, etc. Therefore, accurately obtaining the kernel process structure task is quite troublesome. Moreover, even if it is obtained, it is still necessary to traverse the private memory pool based on the release address to determine whether the release address belongs to private memory. Therefore, when the release function in this embodiment is called, it is not necessary to obtain the kernel process structure task as the allocation function mentioned above.

[0152] b) The release request can carry the page information of the large memory page to be released. It can be determined whether the large memory page to be released belongs to the private memory pool by traversing all the large memory pages in the private memory pool; for example, from the aforementioned array, query whether there is a record of the storage address of the page structure of the large memory page to be released.

[0153] c) If there is one, it indicates that the memory page to be released belongs to a memory page in the private memory pool; clear the memory page corresponding to the page structure, and restore the contents of each field in the struct page structure corresponding to the page in the operating system to their initial values.

[0154] d) Parse the item identifier of the lowest three records from the page structure of the large page of memory to be released;

[0155] e) Using the item identifier, find the corresponding process structure item from the linked list, decrement the number of memory pages used by the process recorded in the item by 1, and decrement the number of memory pages used recorded in the private memory pool structure by 1.

[0156] f) Record the restored original page information into the array element corresponding to the memory big page, that is, the address information of the original page structure recorded in the array element;

[0157] g) Finally, set the bitmap position corresponding to the page's position in the large page array to 1.

[0158] The control interface for the private memory pool in this embodiment may include one or more of the following operation interfaces:

[0159] a) The scaling up and down of the private memory pool size can be seen in the above embodiments;

[0160] b) Adding and deleting private processes corresponding to the private memory pool can be seen in the above embodiments;

[0161] c) Pausing and enabling private processes: During use, you can manually control whether a private process is temporarily used or enabled. In addition, when deleting a private process, if the large memory pages used by the private process are not completely released, it will automatically enter a paused state.

[0162] d) Similar strategy settings to memory pools for private processes can be configured at three levels: data segment allocation and usage, khuged scan data segment usage, and khuged scan code segment usage.

[0163] e) Private memory pool memory type scanning settings, you can set the priority scan measurement of khuged, such as priority scan of code segment, priority scan of data segment, or code segment to data segment scan ratio of 3:1, etc.

[0164] f) The manual addition and query interface of the private memory pool memory scan list mm_slot allows you to set a specific process PID and add that specific process to the khuged scan queue, avoiding waiting triggered by page faults.

[0165] In this embodiment, a virtualization layer (details of which will be provided in subsequent embodiments) can also be introduced to perform operations such as recycling of the private memory pool. As an example, the aforementioned bitmap can also be stored within the virtualization layer, or the aforementioned bitmap can be directly reused, thereby enabling the virtualization layer to determine the state of each memory page in the private memory pool.

[0166] When the virtualization layer performs memory reclamation, it optimizes the reclamation operation by incorporating the above information:

[0167] a) First, determine whether it belongs to a private large page pool. If it does and the bitmap is in an idle state, a flag will be set.

[0168] b) This flag indicates that the virtualization layer is performing private big page memory operations to prevent state changes in the virtualization layer during big page processing;

[0169] c) If the client happens to enter the large page allocation and release logic during this process, it will pause and wait for the marker to disappear;

[0170] d) Then the virtualization layer will directly reclaim this large page and clear the IOMMU page table;

[0171] e) At the same time, the EPT page table will be cleared and the high bits of the EPT page table entries will be marked to indicate that they come from a private memory pool;

[0172] f) Furthermore, no additional data exchange operations are required;

[0173] 10. Similarly, when a client allocates a large page from the private memory pool and performs actual read / write operations, a page fault will be triggered in the virtualization layer, and the operation is similar:

[0174] a) First, the EPT page table representation of the page fault will be read to determine whether its high bits contain a tag from private memory.

[0175] b) If it belongs to a private huge page pool, a new physical huge page memory is allocated directly and an EPT mapping is established without the need for additional memory swapping in;

[0176] c) At the same time, the corresponding IOMMU page table can be created, which greatly simplifies the swapping process;

[0177] Next, combine Figure 2B To explain the virtualization layer. Figure 2B This specification also provides a schematic diagram of a physical machine in this embodiment. As an example, the host operating system is system software running on the physical machine, responsible for managing hardware resources and providing a platform so that applications can run on the operating system and access and utilize hardware resources to perform specific tasks. As an example, the host operating system could be Linux, etc., and this embodiment does not limit it to this.

[0178] As an example, the hardware resources of the physical machine include, but are not limited to, combinations of one or more processors such as: CPU, Graphics Processing Unit (GPU), Data Processing Unit (DPU), Tensor Processing Unit (TPU), Cloud Infrastructure Processing Unit (CIPU), and Application Specific Integrated Circuit (ASIC), etc. The hardware resources of the physical machine may also include any type of storage medium, as well as other components such as I / O devices, communication components, displays, power supply components, and audio components, etc., which are not limited in this embodiment.

[0179] KVM virtualization requires starting a virtual machine. Unlike KVM, this embodiment switches the running host operating system from root mode to virtualization mode, essentially replacing the existing running physical CPU with a virtualized processor. This is more lightweight than KVM virtualization because the virtualization layer can continue to schedule the virtual CPU to run on the physical CPU. Based on this, this embodiment creates one or more virtual processors in the virtualization mode.

[0180] like Figure 2A As shown, the physical machine architecture of this embodiment provides two operating modes for the host operating system in a running state: root mode and virtualization mode. A virtualization layer can be inserted between the hardware resources and the host operating system. The virtualization layer can be located between the hardware resources of the physical machine and the host operating system. The virtualization layer switches the running host operating system from root mode to virtualization mode. Various functions can be flexibly implemented for the running host operating system without reinstalling the operating system.

[0181] As an example, a host operating system has root mode and virtualization mode. Root mode is the operating mode where the host operating system has direct access to hardware resources. Virtualization mode is the operating mode where a virtualization layer virtualizes hardware resources and schedules and accesses these virtualized resources on behalf of the host operating system. In virtualization mode, the virtualization layer's access to hardware resources is restricted. Compared to root mode, virtualization mode can also be called non-root mode; correspondingly, the host operating system in virtualization mode can also be called a guest operating system.

[0182] In this embodiment, a lightweight, powerful, and efficient virtualization layer can be inserted between hardware resources and the host operating system. The virtualization layer can be pre-developed and inserted between the hardware resources and the host operating system. The method of inserting the virtualization layer is not limited. For example, the virtualization layer can be inserted after the host operating system is installed on the physical machine and the host operating system is running normally.

[0183] As an example, the virtualization layer can be a software module within the host operating system. When the host operating system is in root mode, this software module can switch the host operating system from root mode to virtualization mode. After the switch, the host operating system becomes the guest operating system, and the virtualization layer takes over the management of the physical machine's hardware resources. In other words, a virtualization layer is inserted between the hardware resources and the host operating system, allowing the host operating system to use hardware resources through the virtualization layer. The timing of the switch from root mode to virtualization mode can vary in practice, such as when the physical CPU resource utilization is low, when a pre-defined condition is triggered, or when a set instruction is received. This embodiment does not limit this.

[0184] The specific switching process can be as follows:

[0185] The physical machine may include hardware resources, which include at least one physical computing resource object and a physical address space. The physical address space has the host machine's physical addresses, and the host operating system runs on the physical computing resource object. Switching the running host operating system from root mode to virtualization mode includes: creating a memory page table to store the mapping relationship between the guest physical addresses in virtualization mode and the host physical addresses in root mode; creating an information carrier object required for mode switching, which is used to synchronize context information between root mode and virtualization mode; and switching the running host operating system from root mode to virtualization mode based on the information carrier object and the memory page table.

[0186] Optionally, information carrier objects required for mode switching can be created, including: for any physical computing resource object, a physical descriptor structure is created, which is used to save the context information of any physical computing resource in the root mode during mode switching; for any physical computing resource object, a virtualization descriptor structure is created and initialized, which is used to synchronize the context information in the physical descriptor structure during mode switching; for any physical computing resource object, a virtualization control structure is created and initialized to save the runtime information and runtime control information of any physical computing resource object in virtualization mode.

[0187] Optionally, the running host operating system can be switched from root mode to virtualization mode based on the information carrier object and memory page table. This includes: when switching the mode of the target physical computing resource object, saving the context information of the target physical computing resource object in root mode to the physical descriptor structure corresponding to the target physical computing resource object; synchronizing the values ​​of each register and the configuration information of the segment registers in the context information of the physical descriptor structure to the virtualization descriptor structure and virtualization control structure corresponding to the target physical computing resource object, respectively; and controlling the operation of the target physical computing resource object according to the virtualization descriptor structure, virtualization control structure, and memory page table to switch the running host operating system from root mode to virtualization mode.

[0188] Optionally, the context information of the target physical computing resource object in root mode is saved to the physical descriptor structure corresponding to the target physical computing resource object, including: saving the values ​​of each register in the context information and the stack top and stack bottom addresses of the second stack to the physical descriptor structure, wherein the second stack is the stack used by the target physical computing resource object in root mode; and switching the second stack used by the target physical computing resource object in root mode to the first stack corresponding to the target physical computing resource object in virtualization mode.

[0189] Optionally, the operation of the target physical computing resource object is controlled based on the virtualization descriptor structure, the virtualization control structure, and the memory page table, including: loading the values ​​of special-purpose registers in the virtualization control structure and the virtualization descriptor structure; injecting the runtime control information in the virtualization control structure into the target physical computing resource object and loading the values ​​of general-purpose registers in the virtualization descriptor structure; executing a mode switching instruction to control the target physical computing resource object to enter virtualization mode and start running from the first instruction, and performing memory management and access based on the memory page table during the running process.

[0190] After the host operating system switches from root mode to virtualization mode, taking the CPU as an example, the existing physical CPU can be switched to the corresponding virtual CPU. For the physical CPU of the target process bound in this embodiment, it is the virtual CPU where the target process resides. In this embodiment, new virtual CPUs will be further created in virtualization mode. There can be one or more newly created virtual CPUs, which can be flexibly configured according to actual needs. This embodiment does not limit this.

[0191] As an example, suppose the physical machine has four physical CPUs. After the host operating system switches from root mode to virtualization mode, these four physical CPUs can be switched to their corresponding virtual CPUs. In this embodiment, n new virtual CPUs can be created based on these four switched-to virtual CPUs. To distinguish them from the virtual CPUs switched from the physical CPUs, this embodiment refers to the newly created virtual CPUs as newly created virtual CPUs. Thus, the total number of virtual CPUs is four switched-to virtual CPUs plus n newly created virtual CPUs.

[0192] As an example, during the process of the host operating system switching from root mode to virtualization mode, the physical CPU is switched to the corresponding virtual CPU. The virtualization layer can create a corresponding physical description structure (PDS) for each physical CPU and a corresponding virtualization description structure (VDS) for each virtual CPU. The PDS is used to save the context information of the physical CPU running in root mode during mode switching, while the VDS is used to synchronize the context information in the PDS during mode switching. The virtualization layer manages the virtual CPUs switched from the physical CPUs through the VDS.

[0193] As an example, there are multiple ways to create a new virtual processor. For instance, the virtual processor switched from the physical processor mentioned above corresponds to a virtualization description structure. To create a new virtual processor, a new virtualization description structure can be created. Optionally, a series of registers can also be configured, etc., specifically implemented by the virtual processor creation function of the virtualization layer. This embodiment does not limit this. For example, the virtualization description structure of the new virtual processor here is similar to the virtualization description structure corresponding to the physical CPU mentioned above; for example, the fields are the same, but the specific field values ​​are different. Each newly created virtualization description structure represents a new virtual processor, and the corresponding new virtual processor can be managed through the virtualization description structure. The specific management method is not limited in this embodiment.

[0194] As an example, for the virtualization layer at the bottom of the physical machine in this embodiment, a virtual processor is a running task that can be scheduled to run on the physical CPU. On the newly created virtual processor, this virtual processor can be used to run arbitrary tasks, similar to a KVM virtual machine. However, the creation method of the virtual processor in this embodiment differs from KVM, and the virtual processor is managed by the virtualization layer. As an example, various user tasks, such as common user-mode processes, can run on the virtual processor in this embodiment. User processes can also be bound to the newly created virtual processor as needed, etc., and this embodiment does not limit this. Therefore, by scheduling the newly created virtual processor to run on the physical CPU, this embodiment can provide elastic computing power to the upper layer. How the underlying virtualization layer schedules the newly created virtual processor according to the busy / idle status of the physical CPU is transparent to the upper-layer tasks, maintaining transparency to the original running mode.

[0195] Corresponding to the embodiments of the aforementioned memory management methods, this specification also provides embodiments of a memory management device and the computer equipment to which it is applied.

[0196] The embodiments of the memory management device described in this specification can be applied to computer devices, such as servers or terminal devices. The device embodiments can be implemented in software, hardware, or a combination of both. Taking software implementation as an example, as a logical device, it is formed by the processor reading the corresponding computer program instructions from non-volatile memory into memory for execution. From a hardware perspective, such as... Figure 3 The diagram shown is a hardware structure diagram of a computer device containing the memory management device described in this manual. (Except for...) Figure 3 In addition to the processor 310, network interface 320, memory 330, and non-volatile memory 340 shown, the computer device in which the device is located in the embodiment may also include other hardware depending on the actual function of the computer device, which will not be described in detail here.

[0197] like Figure 4 As shown, Figure 4 This specification is a block diagram illustrating a memory management apparatus according to an exemplary embodiment. The apparatus is applied to a management function that manages a private memory pool, which is used by a private process. The management function is used to replace transparent page functions in the operating system during its execution. The apparatus includes:

[0198] The receiving module 41 is used to receive a call request indicating that the currently running process needs to use a transparent big page.

[0199] The determination module 42 is configured to: in response to the call request, if it is determined that the current process is the private process, provide the transparent big page function to the current process through the private memory pool.

[0200] like Figure 5 The diagram shown is a block diagram of another memory management apparatus according to an exemplary embodiment of this specification. The method is applied to an operating system that includes transparent page functions; the method includes:

[0201] Module 51 is used to: determine the management functions used to manage the private memory pool;

[0202] Replacement module 52 is used to: replace the transparent big page function with the management function during operation, so that when the current process running in the operating system needs to use transparent big pages, the management function executes the method of the aforementioned embodiment.

[0203] The specific implementation process of the functions and roles of each module in the above memory management device can be found in the implementation process of the corresponding steps in the above memory management method, and will not be repeated here.

[0204] Accordingly, embodiments of this specification also provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the aforementioned memory management method embodiments.

[0205] Accordingly, embodiments of this specification also provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method embodiments.

[0206] Accordingly, embodiments of this specification also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method embodiments.

[0207] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the solution in this specification according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0208] The above embodiments can be applied to one or more computer devices. The computer device is a device that can automatically perform numerical calculations and / or information processing according to pre-set or stored instructions. The hardware of the computer device includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0209] The computer device can be any electronic product that can interact with the user, such as a personal computer, tablet computer, smartphone, personal digital assistant (PDA), game console, interactive network television (IPTV), smart wearable device, etc.

[0210] The computer equipment may also include network equipment and / or user equipment. The network equipment includes, but is not limited to, a single network server, a server group consisting of multiple network servers, or a cloud based on cloud computing consisting of a large number of hosts or network servers.

[0211] The network in which the computer device is located includes, but is not limited to, the Internet, wide area network, metropolitan area network, local area network, and virtual private network (VPN).

[0212] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0213] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0214] While this specification contains numerous specific implementation details, these should not be construed as limiting the scope of any invention or the scope of the claims, but rather are primarily intended to describe features of specific embodiments of a particular invention. Certain features described in the various embodiments herein may also be implemented in combination in a single embodiment. Conversely, various features described in a single embodiment may also be implemented separately in various embodiments or in any suitable sub-combination. Furthermore, while features may function in certain combinations as described above and even initially claimed in this way, one or more features from a claimed combination may be removed from that combination in some cases, and a claimed combination may refer to a sub-combination or a variation thereof.

[0215] The terms "specific example" or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with the embodiments or examples, which are included in at least one embodiment or example of this specification. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0216] Other embodiments of this specification will readily occur to those skilled in the art upon consideration of the specification and practice of the invention claimed herein. This specification is intended to cover any variations, uses, or adaptations that follow the general principles of this specification and include common knowledge or customary techniques in the art not claimed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this specification are indicated by the following claims.

[0217] It should be understood that this specification is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this specification is limited only by the appended claims.

[0218] The above description is merely a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

Claims

1. A memory management method, the method being applied to a management function that manages a private memory pool, the private memory pool being used by a private process; the management function being used to replace the transparent page function in the operating system during the operation of the operating system; the method comprising: Receives a request from a currently running process that requires the use of a transparent big page; In response to the call request, if it is determined that the current process is the private process, the transparent big page function is provided to the current process through the private memory pool.

2. The method according to claim 1, wherein if it is determined that the current process is the private process, providing transparent huge page functionality to the current process through the private memory pool includes: Create process metadata, which is used to store the private process structure of the private process; the private process structure records the process name of the private process; After obtaining the kernel process structure of the current process in the operating system, the process name of the current process is obtained from the kernel process structure; If the process metadata contains a private process structure that records the process name of the current process, the current process is determined to be the private process, and the transparent big page function is provided to the current process through the private memory pool; The method further includes: If the process metadata does not contain a private process structure that records the process name of the current process, determine whether to call the transparent big page function of the operating system, in order to determine whether to provide transparent big page functionality to the current process through the transparent big page function.

3. The method according to claim 1, wherein providing transparent huge page functionality to the current process through the private memory pool includes: If it is determined that there exists a target memory page in the private memory pool that can be allocated to the current process, the target memory page is returned to the caller that initiated the call request; The method further includes: If it is determined that there is no memory big page in the private memory pool that can be allocated to the current process, it is determined whether to call the transparent big page function of the operating system, so as to determine whether to provide transparent big page functionality to the current process through the transparent big page function.

4. The method according to claim 3, wherein if it is determined that a target memory page exists in the private memory pool that can be allocated to the current process, returning the target memory page to the caller who initiated the call request includes: Create an array, where each element stores the storage address of the page structure for each memory maxpage; Create a bitmap that represents the allocation status of each memory maxpage in the private memory pool; If an unallocated target memory page is found in the bitmap, the allocation status of the target memory page is set to allocated in the bitmap, and the storage address of the page structure of the target memory page is retrieved from the array and returned to the caller who initiated the call request.

5. The method according to claim 4, wherein the private process structure is further used to record the number of memory pages used by the process; the private memory pool corresponds to a memory pool structure, the memory pool structure being used to record the number of memory pages used by the private memory pool; The page structure contains free bits; the method further includes: Increment the number of memory pages used by the process recorded in the process structure item of the current process by 1; Increment the number of memory large pages used recorded in the memory pool structure by 1; Record the identifier of the private process structure of the current process in the free bit of the page structure of the target memory page.

6. The method according to claim 5, further comprising: In response to receiving a request to release a large memory page to be released, the storage address of the page structure of the large memory page to be released is obtained from the release request; Check if the array contains a target element that records the storage address of the page structure of the large page of memory to be released; If so, clear the large page of memory to be released corresponding to the target element, and clear the target identifier recorded in the free bit of the page structure of the large page of memory to be released; Based on the target identifier, the corresponding target private process structure is found from the process metadata, and the number of memory pages used by the process recorded in the target private process structure is reduced by 1; Decrement the number of memory large pages used recorded in the memory pool structure by 1; Set the allocation status of the large memory page to be released recorded in the bitmap to unallocated.

7. The method according to claim 1, further comprising: Provides an interface for setting the memory size of the private memory pool; In response to the current expected size of the private memory pool received through the size setting interface, the number of memory big pages contained in the private memory pool is adjusted based on the current actual size of the private memory pool and the current expected size.

8. The method according to claim 1, wherein the management function includes an allocation function for a private memory pool and a release function for a private memory pool; the transparent big page function includes a memory allocation function, a memory release function, and a scan function for scanning the memory space of a process to determine whether the process needs to use transparent big pages; in, The memory allocation function is replaced with the allocation function of the private memory pool, and the memory release function is replaced with the release function of the private memory pool; the information of the private process is added to the scan list of the scan function.

9. The method according to claim 1, wherein the private memory pool is allocated from memory by the operating system within a preset time period after the physical machine is started, based on a set size.

10. The method according to claim 9, further comprising: In response to the determination that the idle large pages of memory to be reclaimed in the private memory pool need to be reclaimed, the virtualization layer is triggered to perform a reclamation operation; The virtualization layer is used to switch the operating system from root mode to virtualization mode. After the operating system switches to guest operating system, it queries the private memory pool for free large pages to be reclaimed and processes the page table entries corresponding to the large pages to be reclaimed so that the large pages to be reclaimed are reclaimed by the virtualization layer. Furthermore, if the virtualization layer receives a page fault exception triggered by the guest operating system using reclaimed large pages from the private memory pool, it allocates new physical pages and establishes a page table mapping with the reclaimed large pages, so that the guest operating system can use the new physical pages based on the page table mapping.

11. A memory management method, the method being applied to an operating system, the operating system including transparent page functions; the method comprising: Determine the management functions to be used to manage the private memory pool; During operation, the transparent big page function is replaced with the management function so that when the current process running in the operating system needs to use a transparent big page, the management function executes the method described in any one of claims 1 to 10.

12. An operating system in a physical machine, the operating system being used to perform the method of claim 11.

13. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 11.

14. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1 to 11.

15. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 11.

Images