Memory management method, device, storage medium and program product

Abstract

Embodiments of the present disclosure provide a memory management method, a device, a storage medium and a program product. The embodiments of the present disclosure provide a memory management mechanism relatively independent of an operating system, especially applicable to data scenarios where memory swapping is not desirable, or scenarios where independent memory isolation domains are required. Memory pages in a first memory pool are managed by means of a first memory pool management structure, and it is allowed to apply for a memory space from the memory pages in the first memory pool, the applied memory space is segmented into memory blocks of smaller granularity to create a second memory pool, and the memory blocks in the second memory pool are managed by means of a second memory pool management structure, so that the memory space can be allocated at the granularity of the memory blocks. Centralized memory management can be achieved, frequent swap-out of the memory pages in the first memory pool is avoided, system performance fluctuations are reduced, memory fragmentation can be reduced, the memory utilization rate is increased, and the system performance is improved.

Description

[0001] Memory Management Method, Device, Storage Medium, and Program Product This disclosure claims priority to Chinese Patent Application No. 202410383764.7, filed with the China Patent Office on March 29, 2024, entitled "Memory Management Method, Device, Storage Medium, and Program Product," the entire contents of which are incorporated herein by reference. Technical Field This disclosure relates to the field of memory management technology, and more particularly to a memory management method, device, storage medium, and program product. Background: Traditional operating systems (OSs) provide memory management mechanisms, such as buddy systems. These memory management mechanisms can divide memory space into memory pages of different sizes and perform memory allocation and deallocation at the memory page granularity, enabling applications to request and obtain memory space of appropriate size on demand, thereby reducing memory fragmentation. Although some existing memory management mechanisms use memory paging technology for memory allocation and reclamation, which can reduce memory fragmentation, these memory management mechanisms still suffer from irrational memory allocation, which can easily lead to frequent memory swapping. Specifically, this means that a significant amount of time is required to swap data in and out of memory, resulting in system performance fluctuations. SUMMARY OF THE INVENTION Various aspects of the present disclosure provide a memory management method, device, storage medium, and program product for centralized management of memory resources through a first memory pool and a second memory pool, implementing a memory management approach that is relatively independent of the operating system, reducing system performance fluctuations, and improving system performance. An embodiment of the present disclosure provides a memory management method, comprising: managing a first memory pool using a first memory pool management structure, the first memory pool including at least one memory page requested from an operating system to provide allocatable memory space; managing a second memory pool using a second memory pool management structure, the second memory pool including memory blocks obtained by segmenting a target memory space, the target memory space being requested from the memory pages in the first memory pool; and allocating memory space based on the second memory pool management structure, using the memory blocks in the second memory pool as a granularity, so that data allocated to the memory space is distributed among the memory pages included in the first memory pool.An embodiment of the present disclosure provides a physical machine, the physical machine including hardware resources and a host operating system running on the hardware resources, a virtualization layer implemented between the hardware resources and the host operating system, the virtualization layer including a centralized memory management module; the centralized memory management module is configured to manage a first memory pool using a first memory pool management structure, the first memory pool including at least one memory page requested from the host operating system to provide allocatable memory space; manage a second memory pool using a second memory pool management structure, the second memory pool including memory blocks obtained by partitioning a target memory space, the target memory space requested from the memory pages in the first memory pool; and based on the second memory pool management structure, allocate memory space to other functional modules in the virtualization layer using the memory blocks in the second memory pool as a granularity, so that data allocated to the memory space is distributed among the memory pages included in the first memory pool. Embodiments of the present disclosure also provide a physical machine comprising hardware resources and a host operating system running on the hardware resources, the operating system comprising: a centralized memory management module and a traditional memory management module; the centralized memory management module being configured to manage a first memory pool using a first memory pool management structure, the first memory pool comprising at least one memory page requested from the traditional memory management module to provide allocatable memory space; and a second memory pool management structure being configured to manage a second memory pool comprising memory blocks obtained by partitioning a target memory space, the target memory space being requested from the memory pages in the first memory pool; and memory space being allocated based on the second memory pool management structure, using the memory blocks in the second memory pool as a granularity, such that data allocated to the memory space is distributed across the memory pages included in the first memory pool. Embodiments of the present disclosure also provide an electronic device comprising: a memory and a processor; the memory being configured to store a computer program; and the processor being coupled to the memory and configured to execute the computer program to implement the steps of the memory management method provided in the embodiments of the present disclosure. Embodiments of the present disclosure further provide a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the processor implements the steps of the memory management method provided in the embodiments of the present disclosure. Embodiments of the present disclosure further provide a computer program product, including a computer program / instructions. When the computer program / instructions is executed by a processor, the processor implements the steps of the memory management method provided in the embodiments of the present disclosure.Embodiments of the present disclosure provide a memory management method that manages memory pages in a first memory pool through a first memory pool management structure. The first memory pool provides relatively independent and allocable memory space, allowing memory space to be requested from memory pages in the first memory pool. The requested memory space is then divided into smaller memory blocks to create a second memory pool. The memory blocks in the second memory pool are managed through a second memory pool management structure, enabling memory space to be allocated based on the granularity of the memory blocks in the second memory pool. The first and second memory pools not only achieve centralized memory management, avoiding frequent swapping of memory pages in the first memory pool and reducing system performance fluctuations, but also allocate memory space primarily based on memory blocks, reducing memory fragmentation, improving memory utilization, and enhancing system performance. BRIEF DESCRIPTION OF THE DRAWINGS The drawings described herein are provided to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The illustrative embodiments of the present disclosure and their descriptions are provided to explain the present disclosure and are not intended to unduly limit the present disclosure. In the accompanying drawings: Figure 1 is a flowchart of a memory management method provided by an exemplary embodiment of the present disclosure; Figure 2 is a flowchart of creating a second memory management structure and a second memory pool provided by an exemplary embodiment of the present disclosure; Figure 3a is a flowchart of creating a dedicated management structure provided by an exemplary embodiment of the present disclosure; Figure 3b is a schematic diagram of the internal structure of a physical machine provided by an exemplary embodiment of the present disclosure; Figure 3c is a schematic diagram of the internal structure of another physical machine provided by an exemplary embodiment of the present disclosure; Figure 3d is a schematic diagram of the internal structure of another physical machine provided by an exemplary embodiment of the present disclosure; Figure 3e is a schematic diagram of the internal structure of another physical machine provided by an exemplary embodiment of the present disclosure; Figure 4 is a schematic diagram of the structure of a memory management device provided by an exemplary embodiment of the present disclosure; Figure 5 is a schematic diagram of the structure of an electronic device provided by an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION To further clarify the objectives, technical solutions, and advantages of the present disclosure, the technical solutions of the present disclosure will be described clearly and completely below in conjunction with the specific embodiments of the present disclosure and the corresponding drawings. Obviously, the described embodiments are only some of the embodiments of the present disclosure, and not all of them. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present disclosure without inventive effort are within the scope of protection of the present disclosure.It should be noted that 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, storage, and display) involved in this disclosure are all authorized by the user or fully authorized by all parties. The collection, use, and processing of the relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or reject. In addition, the various models involved in this disclosure (including but not limited to language models or large models) comply with relevant laws and standards. Currently, memory management mechanisms provided in operating systems include but are not limited to: Buddy System and SLABo. The Buddy System is an algorithm for managing physical memory used in the kernel of operating systems (such as Linux or Unix). The Buddy System divides physical memory into a series of blocks of equal granularity (also called buddy blocks), with each block size being a power of 2 (such as 4KB or 2MB). These blocks are organized according to granularity to form a buddy block linked list. The primary goal of the buddy system is to minimize memory fragmentation. When an application requests a block of memory of a specific size, the operating system kernel searches the buddy block list closest to the requested size and allocates a suitable buddy block from that list. If no block of an exact size matches, a larger buddy block is selected and split into two smaller buddy blocks. One of these blocks is allocated to the application, while the other is added to the smaller buddy block list. This method of splitting and merging buddy blocks efficiently utilizes memory and reduces memory fragmentation. When an application releases allocated memory, the operating system kernel attempts to merge it with adjacent buddy blocks into a larger buddy block for subsequent allocation. SLAB is a memory allocation mechanism used within the operating system kernel for small memory blocks (such as 32-byte, 64-byte, or 128-byte blocks). By pre-allocating and managing memory blocks, it provides efficient memory allocation and deallocation operations. SLAB reduces memory fragmentation, improves memory utilization, and provides a mechanism for object cache reuse, optimizing system performance. SLAB is an efficient memory allocator designed to provide fast memory allocation and deallocation operations and reduce memory fragmentation. The core concept of SLAB is to provide an efficient mechanism for allocating and deallocating kernel objects by pre-allocating and managing memory blocks. In SLAB, the kernel pre-allocates a certain number of memory blocks, which are organized into one or more linked lists to store kernel objects of a specific size.When an application needs to allocate a kernel object, the SLAB extracts a free memory block from the linked list of memory blocks of the corresponding granularity and allocates it to the application. When the application releases the allocated memory, the SLAB returns the memory block to the free list for subsequent allocation. Taking the two aforementioned memory management mechanisms as examples, existing memory management mechanisms use memory paging for memory allocation and deallocation, which can reduce memory fragmentation. However, these mechanisms still suffer from irrational memory allocation, which can easily lead to frequent memory swapping. This means that data is time-consuming to swap in and out of memory, causing system performance fluctuations. Using the two aforementioned memory management mechanisms as examples, we analyze the reasons why these mechanisms cause frequent memory swapping: Current memory management mechanisms primarily aim to reduce memory fragmentation. However, they fail to consider data types and data usage requirements when allocating memory. This can result in data being scattered throughout the memory space. This scattered data can negatively impact memory swapping, leading to frequent swapping and performance fluctuations. For example, in some application scenarios, metadata needs to be fixed in memory and is not suitable for memory swapping. However, if this metadata is stored in different physical pages, when counting the usage frequency of the physical page, the metadata may be used less frequently, resulting in a lower usage frequency of the entire physical page, which in turn causes the physical page to be selected as a candidate page. Furthermore, because these physical pages contain metadata unsuitable for memory swapping, this conflicts with the page swap logic, affecting the selection of candidate pages for memory swapping. If the candidate page is swapped out, it will be swapped in again due to the use of metadata, resulting in physical pages being constantly swapped out and in, causing system performance fluctuations. To this end, embodiments of the present disclosure provide a new memory management method. This memory management method is an independent memory management mechanism, different from the memory management mechanism provided by the OS. It is primarily used to implement centralized management of memory allocation and deallocation. It is applicable to various application scenarios requiring centralized management of memory allocation and deallocation, particularly scenarios involving data (such as metadata) unsuitable for memory swapping and scenarios requiring independent memory isolation domains. These application scenarios can be application scenarios in traditional OS or application scenarios in lightweight virtualization scenarios and modes.Specifically, for these application scenarios, a first memory pool management structure manages memory pages in the first memory pool. The first memory pool provides relatively independent and allocable memory space, allowing memory space to be requested from memory pages in the first memory pool. The requested memory space is then divided into smaller memory blocks to create a second memory pool. The second memory pool management structure manages the memory blocks in the second memory pool, enabling memory space allocation based on the granularity of memory blocks in the second memory pool. The first and second memory pools not only achieve centralized memory management, but also serve as the basis for requesting memory space from the second memory pool, preventing frequent swapping of memory pages within the first memory pool, which helps reduce system performance fluctuations. Furthermore, allocating memory space primarily based on memory blocks in the second memory pool reduces memory fragmentation, improves memory utilization, and enhances system performance. The following details the technical solutions provided by various embodiments of the present disclosure, in conjunction with the accompanying drawings. Figure 1 is a flow chart of a memory management method provided by an exemplary embodiment of the present disclosure. As shown in Figure 1, the method includes:

[0002] 101. Manage a first memory pool using a first memory pool management structure, where the first memory pool includes at least one memory page requested from an operating system to provide allocatable memory space.

[0003] 102. Manage a second memory pool using a second memory pool management structure, where the second memory pool includes memory blocks obtained by partitioning a target memory space, where the target memory space is allocated from memory pages in the first memory pool.

[0004] 103. Based on the second memory pool management structure, memory space is allocated using memory blocks in the second memory pool as the granularity, so that the data allocated to the memory space is distributed across the memory pages included in the first memory pool. In this embodiment, the memory management method is an important part of managing memory resources in a computer system. Memory pools are a commonly used optimization technique for improving the efficiency of memory allocation and access. A memory pool is a technique that pre-allocates a certain amount of memory space and manages and allocates it according to a specific policy. During initialization, a memory pool pre-allocates a certain amount of memory space to reduce the number of memory requests and releases from the operating system, reducing memory allocation and release overhead and improving program performance. In this embodiment, a first memory pool can be created. For ease of distinction and description, the memory pool that requests and releases memory resources from the operating system is referred to as the first memory pool. The first memory pool includes at least one memory page requested from the operating system to provide allocable and relatively independent memory space. Optionally, at least one memory page can be requested from a partner system or SLAB provided by the operating system to form the independently managed first memory pool in the disclosed embodiment. There is no limit on the number of memory pages included in the first memory pool; it can be one or more, depending on the application scenario. Furthermore, the size of the memory pages in the first memory pool (or page granularity) can be 4KB, 2MB, or 1GB, and is also unrestricted. A first memory pool management structure is created for the first memory pool and used to manage it. This management includes requesting, allocating, reclaiming, and releasing memory pages in the first memory pool. The first memory pool management structure is used to manage at least one memory page in the first memory pool. For example, the first memory pool management structure can record the address information of at least one memory page, which memory pages are idle and which are in use (i.e., allocated), or it can split memory pages and manage the resulting sub-pages. In this embodiment, a second memory pool can be created. For ease of distinction and description, the memory pool that requests and releases memory resources from the first memory pool is referred to as the second memory pool. The second memory pool applies for memory space from memory pages in the first memory pool. For ease of distinction and description, the memory space applied for by the second memory pool from memory pages in the first memory pool is called the target memory space. In the second memory pool, memory resources are managed at a relatively small granularity. Therefore, after the target memory space is applied for, it can be divided into memory blocks. The granularity of the memory block is smaller than that of the memory page.The target memory space may include one or more complete memory pages, or may include incomplete memory pages (i.e., a portion of a memory page is allocated to the second memory pool). Of course, the target memory space may include only complete memory pages, only incomplete memory pages, or a combination of complete and incomplete memory pages. For example, if the memory page size is 2MB and the target memory space size is 6MB, the target memory space may be provided by three complete memory pages, or alternatively, by two complete memory pages and two incomplete memory pages, each providing 1MB. In the disclosed embodiment, the granularity of the memory blocks partitioned from the target memory space and the number of memory block granularities are not limited. For example, the granularity of the memory blocks partitioned from the target memory space may include, but is not limited to, at least one of 32 bytes, 64 bytes, 128 bytes, 4KB, and 2MB. The granularity of the memory blocks in the second memory pool is smaller than or equal to the granularity of the memory pages in the first memory pool. For example, the granularity of memory pages in the first memory pool is 2MB, while the granularity of memory blocks in the second memory pool can be 32 bytes, 64 bytes, ..., 4KB, or 2MB. A second memory pool management structure is created for the second memory pool and used to manage the second memory pool. This management includes the application, allocation, recycling, and release of memory blocks in the second memory pool. The second memory pool management structure is used to manage the memory blocks in the second memory pool. For example, the second memory pool management structure can divide memory pages into memory blocks of different sizes and record which memory blocks are idle and which are in use (i.e., allocated). Furthermore, based on the second memory pool management structure, various management functions such as allocation, recycling, and release of memory space can be performed at the granularity of memory blocks in the second memory pool. When allocating memory space at the granularity of memory blocks in the second memory pool, data allocated to the memory space can be distributed within the memory pages within the first memory pool, rather than across memory pages outside the first memory pool. This allows for centralized data management. Furthermore, the first memory pool serves as the basis for allocating memory from the second memory pool, and memory pages within the first memory pool are not easily swapped out. This alleviates performance fluctuations caused by memory swapping. In the disclosed embodiments, the first and second memory pools provide memory request interfaces for memory request objects, allowing them to request memory space. A memory request object can be an application, driver, process, thread, or other object requiring memory request, using the memory management approach provided by the disclosed embodiments.These memory request objects either request memory space from the first memory pool or from the second memory pool. The first memory pool and the second memory pool each have their own memory request objects, which can be identical, partially identical, or different, without limitation. The memory request objects of the first memory pool include at least the second memory pool. The second memory pool can request target memory space from the first memory pool using a memory request interface provided by the first memory pool. Thus, when a memory request object requests memory space from the second memory pool, the second memory pool can allocate memory space for the memory request object. A memory request object can request the required memory space from either the first memory pool or the second memory pool using a memory request interface provided by the second memory pool. The specific memory pool to request memory from depends on the size of the required memory space. If the memory request object requires a large amount of memory space, it can request the required memory space from the first memory pool using the memory request interface provided by the first memory pool. If the memory request object requires a small amount of memory space, it can request the required memory space from the second memory pool using the memory request interface provided by the second memory pool. If a memory request object requires a smaller amount of memory, a memory request can be initiated to the second memory pool through a memory request interface provided by the second memory pool. The second memory pool can query the second memory pool management structure based on the memory size requested by the memory request object to determine a memory block that can be allocated to the memory request object. The determined memory block is allocated to the memory request object, and information related to the memory block in the second memory pool management structure is updated, for example, the status of the memory block is updated from idle to used. For example, in an operating system, there are some data objects (also known as kernel objects) that occupy relatively small amounts of memory and frequently request and release memory. These include task structure (task_struct) objects, structure page (struct page) objects, structure file (struct file) objects, and socket objects. These data objects occupy relatively small amounts of memory, and the memory blocks in the second memory pool are sufficient for these data objects. When an application requests memory from the second memory pool to use a data object, a memory block in the second memory pool that matches the size of the data object can be allocated to the application. The application can then store the data object in the allocated memory block and use the data object stored in the allocated memory block. When the application releases the data object, the memory block used to store the data object is returned to the second memory pool.As explained, the first and second memory pools also provide memory release interfaces for memory requesting objects, allowing them to release memory space. Memory requesting objects can call the memory release interfaces to release memory space; memory space is released to the same memory pool from which it was requested. In embodiments of the present disclosure, for scenarios requiring centralized memory allocation and deallocation, a first memory pool management structure manages memory pages in the first memory pool, allowing memory space to be requested from memory pages in the first memory pool. The requested memory space is then divided into smaller memory blocks to create a second memory pool. The second memory pool management structure manages the memory blocks in the second memory pool, enabling memory space allocation at the block level. The first memory pool provides relatively independent and allocatable memory space, serving as the basis for requesting memory space from the second memory pool. The memory pages contained in the first memory pool are less frequently swapped out, which helps reduce system performance fluctuations. Furthermore, managing memory space allocation, recycling, and release primarily based on memory blocks in the second memory pool can reduce memory fragmentation, improve memory utilization, and enhance system performance. Regarding the creation of the first and second memory pool management structures, it is noted that they can be created once in the initial stage and used directly upon subsequent memory requests. In the disclosed embodiments, the implementation and creation methods of the first and second memory pool management structures are not limited. The implementation and creation methods of the first and second memory pool management structures are described below. In this embodiment, the implementation of the first memory pool management structure is not limited. The first memory pool management structure includes a first data structure for recording at least one memory page and a second data structure for recording the usage of at least one memory page. The first data structure may include, but is not limited to, an array, a linked list, a tree, or a bitmap, and the second data structure may include, but is not limited to, an array, a linked list, a tree, or a bitmap. The first and second data structures may be the same or different. In an optional embodiment, the first memory pool management structure is implemented using a combination of an array and a bitmap, which simplifies the structure and saves memory space. The first memory pool management structure includes an array for recording at least one memory page and a bitmap for recording the usage of at least one memory page. The method for creating the first memory pool management structure (denoted by mpoo1) is not limited.Optionally, a method for creating a first memory pool management structure includes: obtaining a first initial management structure (denoted as mpoo l-t), the first initial management structure including a first data structure (e.g., an array) and a second data structure (e.g., a bitmap); requesting at least one memory page from an operating system based on the mpoo l-t, recording a first address of the at least one memory page in the first data structure (e.g., an array) of the mpoo l-t, and initializing the second data structure (e.g., a bitmap) in the mpoo l-t, specifically setting usage status record information corresponding to each data page in the second data structure to a first value to indicate that each memory page is in an unused state (i.e., a free page); then, selecting a target memory page from the at least one requested memory page, and copying the first initial management structure to the target memory page to obtain a first memory pool management structure, i.e., mpoo l. It is noted that when the target memory page is used to store the first memory pool management structure, to ensure that there are still allocatable memory pages in the first memory pool, the number of memory pages requested from the operating system is preferably two or more. The target memory page may be any memory page in the first memory pool that is in an idle state. Alternatively, another method for creating the first memory pool management structure includes: obtaining a first initial management structure (denoted as mpoo l-t), the first initial management structure including a first data structure (e.g., an array) and a second data structure (e.g., a bitmap); requesting at least one memory page from the operating system based on the mpoo l-t, recording the first address of the at least one memory page in the first data structure (e.g., an array) of the mpoo l-t, and initializing the second data structure (e.g., a bitmap) in the mpoo l-t. Specifically, the usage status record information corresponding to each data page in the second data structure is set to a first value to indicate that each memory page is in an unused state (i.e., an idle page); and then, after the second memory pool is created, allocating a memory block from the second memory pool, denoted as the first memory block, and copying the first initial management structure to the first memory block to obtain the first memory pool management structure. It should be noted that when allocating the first memory block, a memory block of a size compatible with the first initial management structure can be selected as the first memory block. For example, a memory block of the same size as or slightly larger than the first initial management structure can be selected as the first memory block. The first initial management structure is a temporary management structure corresponding to the first memory pool management structure and is a temporary local variable. After the contents of the first initial management structure are copied to the target memory page or first memory block (i.e., after the first memory pool management structure is obtained), the first initial management structure can be discarded.The first initial management structure can be predefined or temporarily created, and this is not limited to this. Accordingly, an embodiment of managing the first memory pool using the first memory pool management structure includes: when the second memory pool applies for a target memory space from the first memory pool, setting the usage status record information corresponding to the target memory space in a second data structure (e.g., a bitmap) to a second value, where the second value indicates that the memory page to which the target memory space belongs is in use. In the embodiments of the present disclosure, the implementation of the usage status record information is not limited and may depend on the implementation of the second data structure. For example, if the second data structure is implemented as an array, the usage status record information may be an element in the array, where the value of the element indicates whether the corresponding memory page is in an idle state or in use. For another example, if the second data structure is implemented as a bitmap, the usage status record information may be a bit in the bitmap, where the value of the bit indicates whether the corresponding memory page is in an idle state or in use. The first value and the second value are different. If the first value is 0, the second value may be 1; if the first value is 1, the second value may be 0. In an optional embodiment, a memory page has a first page granularity. To facilitate maintenance and management, the memory page can be divided into sub-pages of smaller granularity. For example, the memory page can be divided into sub-pages of a second page granularity. The first memory pool can allocate, reclaim, and release memory resources at the sub-page granularity. The second page granularity is smaller than the first page granularity. The sizes of the first and second page granularities are not limited. For example, the first page granularity can be 2 MB and the second page granularity can be 4 KB. For another example, the first page granularity can be 1 GB and the second page granularity can be 2 MB or 4 KB.When the second data structure is implemented as a bitmap, the usage status record information corresponding to each memory page in the second data structure can be implemented as a bit corresponding to each sub-page. That is, the second data structure includes bits corresponding to each sub-page, where sub-pages belonging to the same memory page correspond to consecutive bits, and the bits corresponding to different memory pages are also consecutive. For example, a first page granularity is 2 MB, a first memory pool includes multiple memory pages with a granularity of 2 MB, and each memory page with a granularity of 2 MB is divided into 512 sub-pages with a granularity of 4 KB. The bitmap includes bits corresponding to each sub-page with a granularity of 4 KB, as well as a sequence number of each sub-page with a granularity of 4 KB. In the bitmap, the sequence numbers corresponding to the 512 sub-pages with a granularity of 4 KB divided from the first memory page with a granularity of 2 MB are 0-511, the sequence numbers corresponding to the 512 sub-pages with a granularity of 4 KB divided from the second memory page with a granularity of 2 MB are 512 to 1023, and so on. In addition to including the first data structure (e.g., an array) and the second data structure (e.g., a bitmap), the first memory pool management structure may also include: locks for managing at least one memory page in the array, various counting information for memory page usage statistics, and the like. Furthermore, optionally, the implementation method for the second memory pool requesting a target memory space from the first memory pool is not limited; a specific implementation method is provided below. When the second memory pool requests a target memory space, the search method varies depending on the size of the target memory space. If the target memory space requires a memory page (for example, if the memory page size is 2MB and the target memory space is 2MB), the first memory pool is searched for a free memory page based on the usage of each memory page recorded in the bitmap. This free memory page is allocated as the target memory space to the second memory pool, and the bit position corresponding to the memory page in the bitmap is set to the second value. If the target memory space requires multiple memory pages (for example, a memory page size of 2MB and a target memory space of 6MB), then based on the usage of each memory page recorded in the bitmap, the first memory pool is searched for multiple free and contiguous memory pages. These free and contiguous memory pages are allocated as the target memory space to the second memory pool, and the bit positions corresponding to these multiple memory pages in the bitmap are set to the second value. If the target memory space requires at least one contiguous subpage within the same memory page (for example, a memory page size of 2MB and a target memory space of 1MB), then based on the usage of each memory page recorded in the bitmap, the first memory pool is searched for at least one free (i.e., unused) contiguous subpage that matches the size of the target memory space.Compatible with the target memory space size means that the size of at least one continuous subpage is the same as the target memory space size, or the difference between the size of at least one continuous subpage and the target memory space size is less than a set threshold. The set threshold is not limited and can be 4KB or 8KB, for example. The at least one continuous subpage is recorded in the second memory pool management structure to allocate the at least one continuous subpage as the target memory space to the second memory pool, and the bit position corresponding to the at least one continuous subpage in the bitmap is set to the second value. Furthermore, the target memory space may span memory pages, meaning that at least one continuous subpage belongs to different memory pages. In this case, a search can also be performed against the bitmap, which will not be described in detail here. Preferably, the target memory space includes at least one continuous subpage in the same memory page. The method of searching the first memory pool for at least one free continuous subpage that is compatible with the target memory space size based on the usage of each memory page recorded in the bitmap is not limited. The entire bitmap can be traversed to find at least one free continuous subpage that is compatible with the target memory space size. The following example uses searching for at least one continuous subpage within a 2MB memory page as an example. An exemplary search method includes the following steps: a) First, determine the start and end numbers of the search range. The start and end numbers are the starting and ending numbers of the 2MB memory page in the bitmap, respectively. For example, the start and end numbers can be 0 and 511, or 512 and 1023. The current offset (offset) of the search is initialized to the start value. That is, the offset increases from the start number to the end number. The number of continuous subpages (free) is initialized to 0, and the starting position (last) of the current continuous free subpage is initialized to the value of start. The minimum difference between the number of continuous subpages (free) and the target memory space size, min_diff, is initialized to 0. The starting address (min_idx) of the continuous free subpage corresponding to min_diff is initialized to 0. ob) Based on the current offset, query the bitmap for the next position dix with the first value (e.g., 0) (i.e., the sequence number of the next free subpage). c) Determine whether the sequence number idx is equal to end. If not, the search for the 2MB memory page has not yet concluded, and proceed to the next step; otherwise, jump to step i. d) Determine whether the position idx is equal to the current offset. If so, the search for a continuous free subpage has not yet concluded. Free is incremented, and offset is also incremented. Jump back to step b and continue determining whether the next subpage is free. e) If the position idx is different from the current offset, the current continuous free subpage has ended, and the next new free subpage has been found. Determine whether the size of the current continuous free subpage is equal to the target memory space size (num). If so, the current continuous free subpage is directly returned as the target memory space. f) If the size of the current continuous free subpage is larger than the target memory space and the size is not equal, to reduce continuous memory fragmentation, the minimum continuous memory that satisfies num is selected, and num subpages are selected from this. The difference (diff) between the current number of continuous free subpages (free) and num is calculated and compared with min_diff. g) If min_diff has not yet recorded data, or the difference (diff) is less than the previously recorded min_diff, the current continuous free subpage is selected as a candidate target memory space, and min_diff and min_dix are set to the current difference (diff) and the starting position (last) of the current continuous free subpage, respectively. oh) Reset the marker for the new free memory segment and reset the number of continuous free subpages (free) to 0. The starting position (last) of the current continuous free subpage is set to the position of the next new free subpage (i dxo i) At this point, the bitmap traversal of the entire 2MB memory page is complete. It's also possible that the last segment of contiguous free subpages isn't compared with the previous candidate target memory space. In this case, steps f and g can be re-executed. j) If the search is successful, the starting position min_idx of the most suitable candidate target memory space is returned. Otherwise, the search fails and an error is returned. k) In the above search within a 2MB memory page, if the target memory space is not found within that 2MB memory page, the remaining 2MB memory pages in the bitmap can be traversed sequentially.1) After confirming that the return value is a valid serial number, the return value serial number i dx in the bitmap and the bit position within the length num can be set to 1, indicating that the subpage has been allocated. In the disclosed embodiments, the method for creating the second memory management structure and the second memory pool is not limited. The following exemplifies a method for creating the second memory management structure and the second memory pool. As shown in Figure 2, the method includes:

[0005] 201. Obtain a second initial management structure, where the second initial management structure includes at least one local management structure corresponding to a memory block granularity, and copy at least one pre-created kernel management structure corresponding to a memory block granularity to the corresponding local management structure.

[0006] 202. Apply for a first memory space from a first memory pool based on the second initial management structure, and divide the first memory space into memory blocks according to at least one memory block granularity to obtain a second memory pool, wherein the first memory space belongs to a target memory space applied for by the second memory pool from the first memory pool.

[0007] 203. Copy the second initial management structure to the second memory block in the second memory pool to obtain a second memory pool management structure, and update the management object of the second memory pool from the second initial management structure to the second memory pool management structure. Regarding step 201, a kernel management structure is pre-created for each memory block granularity. The memory block granularity may include, but is not limited to, 32 bytes, 64 bytes, 128 bytes, and 4 KB, depending on the memory page size. Developers can pre-implement the kernel management structure in the operating system kernel through the interface provided by the operating system kernel. The kernel management structure is a structure located in the operating system kernel for managing memory pools. In contrast, the local management structure has the same function as the kernel management structure, differing in that the kernel management structure is located in the operating system kernel, while the local management structure is located in the local environment. The local environment, relative to the operating system kernel, is the application environment that uses the memory management method provided in the embodiments of the present disclosure for centralized memory management. For example, a local environment can be an application scenario requiring an independent kernel memory isolation domain under a traditional OS architecture. This involves isolating the memory of a component and excluding the operating system from participating in its memory allocation and management. This component can be a driver within the operating system, or an application or process running on the operating system. Alternatively, the local environment can be the operating environment of a lightweight virtualization scenario, referred to below as a virtualization mode. The lightweight virtualization scenario of this embodiment refers to an application scenario in which the virtualization layer can switch the host operating system between non-virtualized and virtualized modes. The virtualization layer, located between hardware resources and the host operating system, is responsible for switching the host operating system from non-virtualized to virtualized mode. The memory management method of this disclosed embodiment can be applied in a virtualization mode to allocate and reclaim memory for other functional modules running in the virtualization mode. In addition to pre-creating kernel management structures for each memory block granularity, a second initial management structure can also be obtained. This second initial management structure includes at least one local management structure corresponding to the memory block granularity. Similar to the first initial management structure, the second initial management structure is a temporary management structure corresponding to the second memory pool management structure. It is a temporary local variable. After the contents of the second initial management structure are copied to the second memory block (i.e., after the second memory pool management structure is obtained), the second initial management structure can be discarded. The second initial management structure can be predefined or temporarily created, without limitation.For example, if at least one memory block granularity includes 32 bytes, 64 bytes, and 128 bytes, the second initial management structure includes a local management structure corresponding to 32 bytes, a local management structure corresponding to 64 bytes, and a local management structure corresponding to 128 bytes. It should be noted that the local management structures corresponding to each memory block granularity included in the second initial management structure are empty, while the kernel management structures pre-created for each memory block granularity contain the content required to manage memory blocks. To manage memory block allocation, recycling, and release in the local environment, the kernel management structures pre-created for each memory block granularity can be copied to the corresponding local management structures. The local management structures are then capable of allocating memory blocks. In step 202, based on the second initial management structure, a request is made from the first memory pool for first memory space. Based on the at least one memory block granularity, the first memory space is divided into memory blocks of different sizes, with each memory block corresponding to a memory block granularity. The detailed implementation process of requesting the first memory space from the first memory pool based on the second initial management structure is identical or similar to the process of requesting the target memory space from the first memory pool in the above-mentioned embodiment, and therefore will not be further described. Regarding step 203, once the second memory pool is obtained, the second initial management structure is copied to the second memory block in the second memory pool to obtain a second memory pool management structure. Similar to the second initial management structure, the second memory pool management structure includes: local management structures corresponding to the granularity of each memory block. Optionally, before copying the second initial management structure to the second memory block in the second memory pool, a memory block with a memory block granularity compatible with the second initial management structure may be selected from the second memory pool as the second memory block based on the size of the second initial management structure. For example, based on the size of the second initial management structure, a memory block with the same memory block granularity as the second initial management structure is preferentially selected from the second memory pool as the second memory block. If no memory block with the same size as the second initial management structure exists, a candidate memory block with a memory block granularity greater than the size of the second initial management structure is selected from the second memory pool, and the smallest memory block among the candidate memory blocks is selected as the second memory block. The second memory pool is requested by the second initial management structure from the first memory pool, and the management object of the second memory pool defaults to the second initial management structure. Therefore, after copying the second initial management structure to the second memory block to obtain the second memory pool management structure, the management object of the second memory pool needs to be updated from the second initial management structure to the second memory pool management structure. This facilitates subsequent management of memory blocks in the second memory pool, such as allocation, recycling, or release, through the second memory pool management structure.In the disclosed embodiment, the implementation method for copying the pre-created kernel management structure corresponding to at least one memory block granularity into the corresponding local management structure in step 201 is not limited and may depend on the implementation structure of the local management structure. A specific implementation method is provided below. In this implementation method, the local management structure includes a local information (local) field, an associated information field, and a kernel information (back) field. Based on this, copying the pre-created kernel management structure corresponding to at least one memory block granularity into the corresponding local management structure includes: recording identification information of the kernel management structure corresponding to any memory block granularity into the kernel information field of the corresponding local management structure; copying the content of the kernel management structure corresponding to any memory block granularity into the local information field of the corresponding local management structure; and copying associated structure information of the kernel management structure corresponding to any memory block granularity into the associated information field of the corresponding local management structure. The associated structure information of the kernel management structure includes, but is not limited to, a next-level node (node) structure. This associated structure information plays a role when destroying the local management structure, simultaneously destroying the local management structure and the associated structure. Similarly, during the destruction process, in addition to clearing the local management structure, the kernel management structure can also be found and destroyed based on the kernel information field. In an optional embodiment, Direct Memory Access (DMA) allows certain hardware subsystems to directly access the system's main memory without transferring data through the CPU. In computer technology, DMA operations can be used to transfer data between memory and devices, particularly in peripheral devices such as hard drives, network interfaces, and graphics cards. In some cases, memory blocks can be allocated for DMA operations. Therefore, the second memory pool can include memory blocks corresponding to DMA operations, memory blocks accessed by the CPU, or both memory blocks corresponding to DMA operations and memory blocks accessed by the CPU. Based on the above, in step 201, the kernel management structure corresponding to each memory block granularity includes a kernel management structure corresponding to the memory block granularity with a set flag and / or a kernel management structure corresponding to the memory block granularity without a set flag; accordingly, the local management structure corresponding to each memory block granularity includes: a local management structure corresponding to the memory block granularity for direct memory access and a local management structure corresponding to the memory block granularity for indirect memory access.Based on this, the kernel management structures corresponding to at least one pre-created memory block granularity are copied to the corresponding local management structures. This includes: copying the kernel management structure corresponding to at least one memory block granularity with a set flag to the local management structure corresponding to at least one memory block granularity for direct memory access; and / or copying the kernel management structure corresponding to at least one memory block granularity without a set flag to the local management structure corresponding to at least one memory block granularity for non-direct memory access. The set flag may be a SLAB cache direct memory access (SLAB_CHACHE_DMA) flag. In an optional embodiment, each memory block granularity in FIG. 2 may be implemented as a universal memory block granularity. The local management structures corresponding to each memory block granularity in the second memory pool management structure include: a local universal management structure corresponding to each universal memory block granularity. The universal memory block granularity may be a memory block granularity of a predetermined size, typically a power of 2. For most memory blocks, the aforementioned general memory block size is sufficient. In practical applications, a general memory block closest to a power of 2 can be allocated to the application or process requesting the memory block. In practical applications, the general memory block allocated to an application or process may be larger than the actual memory space required. If this situation frequently occurs, it will result in a certain amount of memory waste. Therefore, in addition to general memory blocks corresponding to the aforementioned general memory block granularity, the second memory pool also includes dedicated memory blocks. Dedicated memory blocks are memory blocks with a non-general memory block granularity, i.e., a memory block granularity that is not a power of 2, but rather 30 bytes, 48 ​​bytes, or 60 bytes, for example. The size of dedicated memory blocks is determined based on application requirements. As shown in Figure 3a, the method provided in this embodiment of the present disclosure further includes:

[0008] 301. Apply for a third memory block adapted to the local management structure granularity from a second memory pool according to the local management structure granularity.

[0009] 302. Copy the kernel management structure corresponding to the pre-created dedicated memory block into the third memory block to obtain a local dedicated management structure;

[0010] 303. Apply for a second memory space from the first memory pool based on the local dedicated management structure, and divide the second memory space into dedicated memory blocks, where the second memory space belongs to the target memory space.

[0011] 304. Add the local dedicated management structure to the linked list of the second memory pool management structure for managing local dedicated management structures. A local management structure also needs to be established to manage dedicated memory blocks. In this embodiment, since the second memory pool has already been created, a third memory block compatible with the local management structure granularity can be directly requested from the second memory pool based on the local management structure granularity to store the local management structure for managing dedicated memory blocks. To distinguish it from the local management structure for managing general memory blocks (i.e., the local general management structure), in this embodiment, the local management structure for managing dedicated memory blocks is referred to as a local dedicated management structure. Furthermore, to save memory space and avoid waste, a general memory block with a granularity larger than and closest to the local management structure granularity can be selected as the third memory block. For example, assuming the local management structure granularity is 48 bytes, and general memory block granularities larger than 48 bytes include 64 bytes and 128 bytes, to save memory space, a 64-byte general memory block is selected as the third memory block. The kernel management structure corresponding to the pre-created dedicated memory block is copied into the third memory block to obtain a local dedicated management structure. The local dedicated management structure and the local general management structure have the same structure header, differing in that they manage different memory blocks. Creating the local dedicated management structure directly based on the local management structure granularity can simplify the process of creating the local dedicated management structure. In this embodiment, a kernel management structure is pre-created for each dedicated memory block, where each dedicated memory block can be a memory block of 30 bytes, 40 bytes, 60 bytes, or other sizes. The kernel management structure corresponding to a dedicated memory block contains the content required to manage the dedicated memory block. To manage the allocation, recycling, and release of the dedicated memory block in the local environment, the kernel management structure previously created for the dedicated memory block can be copied to the third memory block to obtain a local dedicated management structure. The local dedicated management structure is capable of managing the dedicated memory block. In this embodiment, if a dedicated memory block needs to be allocated based on the local dedicated management structure, the initial allocation can be performed by requesting free subpages or free memory pages from the first memory pool and partitioning them to obtain the dedicated memory block. For subsequent allocations, if a partitioned dedicated memory block exists, it is allocated directly; otherwise, the local dedicated management structure again requests free memory pages or free subpages from the first memory pool for partitioning.In the disclosed embodiment, the first memory pool management structure can be located in either the first memory pool or the second memory pool. To ensure the security of the first memory pool management structure and prevent it from being swapped out, the first memory pool management structure can be copied to the first memory block in the second memory pool. In this way, the management structures involved in both the first and second memory pools are located in the second memory pool. While ensuring that the first memory pool is not swapped out, frequent memory swapping is avoided, thereby improving system performance. In an optional embodiment, when initializing metadata for certain special functions, a large memory block can be allocated for this metadata. For example, the large memory block can be larger than 2MB. This large memory block can be allocated using the virtual memory allocation (vmalloc) function. After allocation, the large memory block can be added to the first memory pool to ensure that it will not be swapped out during subsequent memory swaps. Based on this, a specific memory page is pre-requested from the operating system. The page granularity of the specific memory page is larger than the page granularity of at least one memory page. For example, the specific memory page refers to a memory page with a larger page granularity, such as, but not limited to, 1 GB, or 2 GB or even larger. To facilitate relatively independent and centralized memory management, the specific memory page can also be added to the first memory pool and managed using the first memory pool management structure. In an optional embodiment, memory space is reclaimed based on the granularity of memory blocks in the second memory pool based on the second memory pool management structure. Alternatively, memory space is released based on the granularity of memory blocks in the second memory pool based on the second memory pool management structure. Reclaiming memory space based on the granularity of memory blocks in the second memory pool means reclaiming allocated memory blocks to the second memory pool; releasing memory space based on the granularity of memory blocks in the second memory pool means releasing subpages belonging to free memory blocks in the second memory pool to the first memory pool. For example, when an application releases a memory block, the released memory block can be provided to the second memory pool management structure for recycling. Specifically, the freed memory block can be provided to the local management structure corresponding to the memory block granularity for recycling. As the number of memory blocks reclaimed by the second memory pool management structure increases, a free subpage may become available. If the number of free subpages exceeds a set first threshold, these free subpages can be released back to the first memory pool. For example, the first threshold can be 3, 10, or 50. Optionally, after the free subpages are released back to the first memory pool, if the local dedicated management structure or the local general management structure is no longer used, the local dedicated management structure or the local general management structure can be destroyed.A method for releasing a memory page back to the first memory pool is provided below: a) calculating the first address (vaddr2) of the 2M-aligned memory page to which the released memory page belongs based on the first address (vaddr) and length (num) of the released memory page, where vaddr2 is the first address of the 2M memory page. b) determining the sequence number of the 2M memory page in the first bitmap based on vaddr2. c) calculating the sequence number of vaddr in the first bitmap (dixo) based on the difference between vaddr2 and vaddr, and the sequence number of vaddr2 in the first bitmap. d) clearing the released memory page to zero, i.e., setting the values ​​corresponding to the sequence numbers from idx to idx to num in the first bitmap to a first value (e.g., 0). In an optional embodiment, based on the first memory pool management structure, memory space is allocated, reclaimed, or released for objects other than the second memory pool at the granularity of memory pages in the first memory pool. Allocating memory space at the granularity of memory pages in the first memory pool refers to allocating memory pages to the memory request object that requested the memory pages. Reclaiming memory space at the granularity of memory pages in the first memory pool refers to reclaiming the memory pages allocated to the memory request object. Freeing memory space at the granularity of memory pages in the first memory pool refers to returning free pages in the first memory pool to the operating system. The following example describes how to create a second memory pool and a second memory management structure.

[0012] 1. First, define a second memory pool management structure (cpool_name) to manage the local management structures corresponding to each locally created memory block granularity. cpool_name includes a cache array and a direct memory access cache (dma_caches) array. Different cache arrays correspond to different general memory block granularities, and different dma_caches arrays also correspond to different general memory block granularities. The difference is that one is used to allocate ordinary memory blocks (memory blocks accessed by the CPU) and the other is used to allocate DMA-related memory blocks. Furthermore, cpool_name also contains a linked list for managing local dedicated management structures.

[0013] 2. The caches array is used to create local general management structures corresponding to general memory blocks with granularity ranging from 32 bytes to 2MB. The size of each general memory block is a power of 2, for example, 32 bytes, 64 bytes, 128 bytes, and so on. Each caches array creates a local general management structure at the granularity of a general memory block. Each caches array corresponds to a second memory pool management structure item (cpool_item). The cpool_item structure contains local information.

[0014] The l oca l field, the next-level node field, and the kernel information field are: (I oca l) field, the next-level node field, and the kernel information field. The l oca l field is a local memory cache (kmem_cache) structure, the node field is the memory cache node (kmem_cache_node) structure of the next-level node corresponding to the l oca l field, and the back field is a memory cache (kmem_cache) structure corresponding to the associated kernel.

[0015] 3. When creating the second memory pool, first create a local temporary memory pool management structure (cpoo l _t). The cpool _t is a static variable used to assist in the creation of the second memory pool and the second memory pool management structure. The cpool _t 11 can be called the second initial management structure, and the structure of cpool _t is the same as the cpool defined above.

[0016] 4. Obtain the local management structure t corresponding to the memory block of the universal memory block granularity from cpool_t, that is, the cpool_item structure mentioned above. For each universal memory block granularity, name it after the universal memory block granularity. The memory block granularity corresponds to a pre-created kernel management structure s. Record the address of the kernel management structure s in the back field of the local management structure t.

[0017] 5. The contents of kernel management structure s are copied to the loca1 field of local management structure t, and the next section structure node of kernel management structure s is copied to the node field of local management structure t. The linked lists and lock structures involved in loca1 and node are also initialized. The node field is used to store the next-level node structure information associated with kernel management structure s. The next-level node structure information is merely an example of other structure information associated with kernel management structure s and is not limited thereto.

[0018] 6. Similarly, the local memory management structure for the DMA of this dedicated memory block will also be marked similarly. The difference is that when creating the kernel management structure s, it can be marked with the SLAB_CHACHE_DMA flag. 7. After the cpool_item structure for each memory block granularity is established, cpool_t has the ability to allocate memory blocks. At this time, the temporary cpool_t can be replaced with the official second memory pool management structure (cpool_t). To do this, based on the size of cpool, a memory block with a cpool_item structure that is closest to and meets this size can be selected and allocated to the official cpool_t.

[0019] 8. During the first allocation, since cpool_t has not yet been associated with a formal memory page, a certain number of subpages (pages) can be allocated from the above mpoo l according to the size of cpool_t through the cache growth (cache_grow) path.

[0020] 9. After obtaining the allocated sub-page, the allocated sub-page can be split into multiple memory blocks according to the SLAB algorithm, for example, general memory blocks of various common sizes, and a memory block is selected from them to store the cpool O

[0021] 10. Copy the local management structure and other structures recorded in cpool_t to the memory block used to store cpool to obtain cpool: At the same time, initialize the lock variables involved in the cpool structure.

[0022] 11. Update the association between the subpages (pages) allocated by the cache_grow path and the management objects (management structures). The SLAB cache (slab_cache) field in each subpage's page structure can record the management structure that manages it. Originally, it was temporarily managed through cpool_t, and its associated local management structure was also in cpool_t. After obtaining the official management structure cpool_t, the subpage's management structure can be updated to the local management structure in the official cpool_t. In the above embodiment, the various objects involved in the memory management method (e.g., the first memory pool, the first memory pool management structure, the second memory pool, the second memory pool management structure, etc.) and the implementation process of the entire method are described in detail, along with the application scenarios of the memory management method. To facilitate a clearer understanding of the memory management method of the disclosed embodiments, the following description is based on the deployment and implementation of this solution in a physical machine architecture. The deployment and implementation of this solution in a physical machine architecture will vary depending on the application scenario of this solution. In an optional embodiment, this solution is applied to application scenarios requiring independent kernel memory isolation domains under a traditional OS architecture. As shown in FIG3b , a physical machine under a traditional OS architecture comprises, from bottom to top, hardware resources, an operating system running on the hardware resources, and applications running on the operating system. Optionally, the hardware resources include a central processing unit (CPU), a graphics processing unit (GPU), a network card, and physical storage media, including memory and disks. In addition, the hardware resources on the physical machine may also include other components, not shown, such as I / O devices, communication components, displays, power components, and audio components. In the disclosed embodiments, neither the operating system nor the application programs are limited.Furthermore, as shown in FIG3b , this solution runs in the OS, specifically corresponding to the centralized memory management module in FIG3b . This centralized memory management module is responsible for executing the memory management method provided by the embodiments of the present disclosure. Unlike the traditional kernel management module in the OS, the centralized memory management module is responsible for providing relatively independent memory isolation domains for memory requesting objects such as applications, drivers, or processes in the operating system, in addition to the memory management provided by the traditional kernel management module. Specifically, memory can be allocated, reclaimed, and released for these applications, drivers, or processes in the first memory pool and / or the second memory pool without being affected by the traditional kernel management module. FIG3b illustrates an example of an application in the application layer requesting memory from the first memory pool and / or the second memory pool. The centralized memory management module may apply for at least one memory page from the traditional memory management module, and create a first memory pool and a first memory pool management structure based on the applied memory page, and manage the first memory pool using the first memory pool management structure; and create a second memory pool management structure and a second memory pool, and manage the second memory pool using the second memory pool management structure; and allocate memory space based on the second memory pool management structure using memory blocks in the second memory pool as a granularity; and / or allocate memory space based on the first memory pool management structure using memory pages in the first memory pool or sub-pages divided from the memory pages as a granularity. Specifically, if an application, driver, or process requires a relatively independent memory isolation domain, it can determine whether to request memory from the first or second memory pool based on the required memory size. The application can then initiate a memory request to the centralized memory management module using the memory request interface provided by the first or second memory pool for the memory request object. Upon receiving the memory request, the centralized management module allocates an idle memory page or block from the first or second memory pool based on the first or second memory pool management structure, and updates the status of the memory page or block in the first or second memory pool management structure to "in use." An application, driver, or process can request one or more memory blocks or one or more memory pages. Furthermore, when the application, driver, or process no longer needs memory resources, it can release the memory using the memory release interface provided by the first or second memory pool structure. For details on release, please refer to the previous embodiment and will not be repeated here. In another optional embodiment, this solution is applied in a lightweight virtualization scenario.The following describes the lightweight virtualization scenario in the embodiments of the present disclosure. Figure 3c is a first schematic diagram of the structure of another physical machine provided in an exemplary embodiment of the present disclosure. As shown in Figure 3c, the physical machine includes hardware resources 10 and a host operating system 20 running on the hardware resources. A virtualization layer 30 is implemented between the hardware resources 10 and the host operating system 20. Furthermore, an application layer 40 is provided above the host operating system 20. Application layer 40 includes various application programs. For an introduction to the hardware resources, please refer to the embodiment shown in Figure 3b. The implementation of the host operating system 20 and application programs is not limited. In this embodiment, the host operating system 20 has both a non-virtualized mode and a virtualized mode. In the non-virtualized mode, the host operating system 20 has direct access to the hardware resources 10. In the virtualized mode, the virtualization layer 30 virtualizes the hardware resources 10 and schedules and accesses the virtualized resources on behalf of the host operating system 20. In the virtualized mode, the virtualization layer 30 has limited access to the hardware resources 10. Accordingly, the host operating system 20 in virtualization mode can also be referred to as a guest operating system. In this embodiment, a lightweight, powerful, and efficient virtualization layer 30 is inserted between the hardware resources 10 and the host operating system 20. The virtualization layer 30 can be pre-developed and inserted between the hardware resources 10 and the host operating system 20. The method for inserting the virtualization layer 30 is not limited. For example, the virtualization layer 30 can be inserted after the host operating system 20 is installed on the physical machine and while the host operating system 20 is in normal operation. oThe virtualization layer 30 has the capability to provide virtual resources, at least corresponding to resources that the host operating system 20 cannot provide in non-virtualized mode due to disabled or missing system functions. In other words, for resources that the host operating system 20 cannot provide in non-virtualized mode due to disabled or missing system functions, the virtualization layer 30 can provide corresponding virtual resources to facilitate the running of corresponding applications. Specifically, the virtualization layer 30 can switch the running host operating system 20 from non-virtualized mode to virtualized mode, provide at least one virtual resource in the virtualized mode, and run at least one application on the at least one virtual resource. This flexible virtual resource provision function can be implemented for the running host operating system without reinstalling the operating system, resolving the issue of the host operating system 20 being unable to provide corresponding resources to run corresponding applications in non-virtualized mode due to disabled or missing system functions. This can support the running of more applications and help expand the capabilities of the host operating system. Furthermore, to maintain host operating system compatibility and reduce frequent mode switching in the host operating system, in virtualization mode, not only can corresponding virtual resources be provided for system functions that are disabled or missing in the host operating system 20 in non-virtualization mode, but corresponding virtual resources can also be provided for system functions that are enabled in the host operating system 20 in non-virtualization mode, thereby supporting more functions of the host operating system 20. For example, the at least one target function implemented in the virtualization layer 30 includes, but is not limited to, memory management, file management, virtualization, and scheduling optimization. The memory management, file management, and scheduling optimization functions mentioned here can be newly added functions not originally supported by the host operating system, or they can be functions originally supported by the host operating system but not enabled during the host operating system installation process. Whether newly expanded or not yet enabled, memory management functions specifically include, but are not limited to, memory page fault management, memory swap management, and memory mapping management; file management functions specifically include, but are not limited to, directory management, permission management, file backup, creation, query, deletion, and modification; virtualization functions specifically include, but are not limited to, virtualization of various elastic resources (such as CPU, GPU, memory, and network); and scheduling and tuning functions specifically include, but are not limited to, scheduling of physical computing resource objects and scheduling of various virtualized resources. Furthermore, Figure 3c shows a schematic diagram of the overall architecture of a physical machine, while Figures 3d and 3e illustrate the internal architecture of a physical machine operating in non-virtualized and virtualized modes.Before the mode switch, the host operating system operates in non-virtualized mode. In this non-virtualized mode, as shown in FIG3d , the internal architecture of the running physical machine, from bottom to top, consists of hardware resources 10, host operating system 20, and application layer 40. After the mode switch, the host operating system operates in virtualized mode. In this virtualized mode, as shown in FIG3e , the architecture of the running physical machine, from bottom to top, consists of hardware resources 10, virtualization layer 30, guest operating system, and application layer 40. The term "guest operating system" refers to the host operating system 20 running in virtualized mode. In an embodiment of the present disclosure, two operating modes are provided for a running host operating system: a non-virtualized mode and a virtualized mode. A virtualization layer is inserted between hardware resources and the host operating system. The virtualization layer implements at least the virtualization resource provision function. The virtualization layer switches the running host operating system from the non-virtualized mode to the virtualized mode, providing virtual resources in the virtualized mode and running at least applications that the host operating system cannot run in the non-virtualized mode due to insufficient resources. Without reinstalling the host operating system, the virtual resource provision function can be flexibly implemented for the running host operating system, supporting the operation of more applications and expanding the capabilities of the host operating system. It should be noted that, from the perspective of program code, the implementation code for "providing virtual resources" and "switching from non-virtualized mode to virtualized mode" in the embodiments of the present disclosure belongs to the virtualization layer 30, and this code resides under the host operating system. However, from the perspective of the runtime state, before the mode switch is actually completed, at least a portion of the program code in the virtualization layer 30 is executed during the operation of the host operating system. In other words, at least a portion of the program code in the virtualization layer 30 is executed in the non-virtualized mode. The program code executed in the virtualization layer 30 in the non-virtualized mode includes at least program code for switching from non-virtualized mode to virtualized mode, such as the upper half of the switching function described in the following embodiments. Accordingly, after the mode switch is actually completed, a portion of the program code is executed in the virtualized mode, such as the lower half of the switching function described in the following embodiments. In addition, the program code responsible for providing virtual resources in the virtualization layer 30 also runs in the non-virtualization mode, but this part of the code is executed after the switching is completed; the virtualization layer 30 also provides some interface codes to the outside world, some of which will run in the virtualization mode, and some will need to be switched to the non-virtualization mode to run, depending on the function of the interface code.When this solution is applied to a lightweight virtualization scenario, as shown in FIG3d , the virtualization layer 30 includes a centralized memory management module responsible for executing the memory management method of this embodiment, as well as other functional modules required by the virtualization layer 30. The centralized memory management module is used to provide centralized memory allocation, recycling, or release management for other functional modules in the virtualization layer in virtualization mode. Specifically, in a non-virtualized mode, various kernel management structures involved in the above-mentioned embodiments can be implemented in the host operating system kernel by calling a kernel interface provided by the host operating system. Then, when the system switches to a virtualized mode, the integrated memory management module is run to: apply for at least one memory page from a traditional memory management module in the client operating system, create a first memory pool and a first memory pool management structure based on the applied memory page, and manage the first memory pool using the first memory pool management structure; and create a second memory pool management structure and a second memory pool, and manage the second memory pool using the second memory pool management structure; further, based on the second memory pool management structure, allocate memory space using memory blocks in the second memory pool as a granularity; and / or, based on the first memory pool management structure, allocate memory space using memory pages in the first memory pool or sub-pages divided from the memory pages as a granularity. Specifically, other functional modules in the virtualization layer can determine whether to request memory from the first memory pool or the second memory pool based on the required memory size. They can then initiate a memory request to the centralized memory management module via the memory request interface provided by the first memory pool or the second memory pool for the memory request object. Upon receiving the memory request, the centralized management module allocates an idle memory page or block from the first memory pool or the second memory pool based on the first memory pool management structure or the second memory pool management structure, and updates the status of the memory page or block in the first memory pool management structure or the second memory pool management structure to "in use." Other functional modules in the virtualization layer can request one or more memory blocks or one or more memory pages. Furthermore, when an application, driver, or process no longer needs memory resources, it can release the memory resources via the memory release interface provided by the first memory pool structure or the second memory pool structure. For details on release, please refer to the previous embodiment and will not be repeated here. The detailed implementation and beneficial effects of each step in the method of this embodiment have been described in detail in the previous embodiment and will not be elaborated on here.It should be noted that some of the processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be understood that these operations may be executed in a different order than the order in which they appear herein or in parallel. Operation sequence numbers, such as 301 and 302, are merely used to distinguish between different operations and do not represent any specific execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that terms such as "first" and "second" are used herein to distinguish between different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types. FIG4 is a schematic structural diagram of a memory management device provided in an exemplary embodiment of the present disclosure. As shown in FIG4 , the device includes a creation module 41, a management module 42, and an allocation module 43. A management module 42 is configured to manage a first memory pool using a first memory pool management structure, the first memory pool including at least one memory page requested from the operating system to provide allocatable memory space; and to manage a second memory pool using a second memory pool management structure, the second memory pool including memory blocks obtained by partitioning a target memory space, the target memory space requested from the memory pages in the first memory pool. An allocation module 43 is configured to allocate memory space based on the second memory pool management structure, using memory blocks in the second memory pool as the granularity, so that data allocated to the memory space is distributed across the memory pages included in the first memory pool. In an optional embodiment, as shown in FIG4 , the apparatus further includes a creation module 41, configured to create a first memory pool management structure, and also configured to create a second memory pool management structure and a second memory pool. In an optional embodiment, when creating the first memory pool management structure, the creation module 41 is specifically configured to: obtain a first initial management structure, where the first initial management structure includes a first data structure and a second data structure; request at least one memory page from the operating system to form the first memory pool; record the first address of the at least one memory page in the first data structure, and initialize usage status record information corresponding to each memory page in the second data structure to a first value to indicate that each memory page is in an idle state; and copy the first initial management structure to a target memory page or a first memory block to obtain the first memory pool management structure; wherein the target memory page is a memory page in the first memory pool, and the first memory block is a memory block in the second memory pool.Accordingly, when the management module manages the first memory pool using the first memory pool management structure, the management module includes: when the second memory pool applies for the target memory space from the first memory pool, setting the usage status record information corresponding to the target memory space in the second data structure to a second value to indicate that the memory page belonging to the target memory space is in use. Optionally, the memory page has a first page granularity and is divided into sub-pages of a second page granularity, where the second page granularity is smaller than the first page granularity; the usage status record information corresponding to each memory page in the second data structure includes bits corresponding to each sub-page, and sub-pages belonging to the same memory page correspond to consecutive bits; for any bit, if the value is the first value, the corresponding sub-page is in an idle state; if the value is the second value, the corresponding sub-page is in use. Further optionally, the device also includes: a search module and a recording module; the search module is used to search in the first memory pool for at least one continuous sub-page that is adapted to the size of the target memory space and is in an idle state according to the usage of each memory page recorded in the second data structure when the second memory pool applies for the target memory space; the recording module is used to record the at least one continuous sub-page in the second memory pool management structure to allocate the at least one continuous sub-page as the target memory space to the second memory pool, and set the bit position corresponding to the at least one continuous sub-page in the second data structure to the second value. In an optional embodiment, when creating the second memory pool management structure and the second memory pool, the creation module is specifically used to: obtain a second initial management structure, where the second initial management structure includes at least one local management structure corresponding to a memory block granularity, and copy the pre-created kernel management structure corresponding to the at least one memory block granularity into the corresponding local management structure; based on the second initial management structure, apply for a first memory space from the first memory pool, and divide the first memory space into memory blocks according to the at least one memory block granularity to obtain the second memory pool, where the first memory space belongs to the target memory space; copy the second initial management structure into a second memory block in the second memory pool to obtain the second memory pool management structure, and update the management object of the second memory pool from the second initial management structure to the second memory pool management structure.Further optionally, the local management structure includes: a local information field, an associated information field and a kernel information field; when the creation module copies the kernel management structure corresponding to the at least one pre-created memory block granularity into the corresponding local management structure, it includes: recording the identification information of the kernel management structure corresponding to any memory block granularity into the kernel information field in the corresponding local management structure; copying the content in the kernel management structure corresponding to any memory block granularity into the local information field in the corresponding local management structure; copying the associated structure information of the kernel management structure corresponding to any memory block granularity into the associated information field in the corresponding local management structure. In an optional embodiment, when the creation module copies the pre-created kernel management structure corresponding to the at least one memory block granularity into the corresponding local management structure, the creation module includes: copying the kernel management structure corresponding to the at least one memory block granularity with a set flag into the local management structure corresponding to the at least one memory block granularity for direct memory access; and / or copying the kernel management structure corresponding to the at least one memory block granularity without a set flag into the local management structure corresponding to the at least one memory block granularity for non-direct memory access. In an optional embodiment, the at least one memory block granularity includes at least one universal memory block granularity, and the local management structure corresponding to the at least one memory block granularity includes the local universal management structure corresponding to the at least one universal memory block granularity. The device also includes: a determination module, an application module, a segmentation module, and an addition module. A determination module is configured to apply for a third memory block from the second memory pool that matches the granularity of the local management structure based on the granularity of the local management structure. A creation module is further configured to copy the kernel management structure corresponding to the pre-created dedicated memory block into the third memory block to obtain a local dedicated management structure. An application module is configured to apply for a second memory space from the first memory pool based on the local dedicated management structure. A partitioning module is configured to partition the second memory space to obtain dedicated memory blocks, wherein the second memory space belongs to the target memory space. An addition module is configured to add the local dedicated management structure to a linked list in the second memory pool management structure used to manage local dedicated management structures. In an optional embodiment, the application module is further configured to pre-apply for a specific memory page from the operating system, wherein the page granularity of the specific memory page is greater than the page granularity of at least one memory page. The addition module is further configured to add the specific memory page to the first memory pool and manage the specific memory page using the first memory pool management structure. In an optional embodiment, the apparatus further includes a processing module.The processing module is configured to reclaim and / or release memory space based on the second memory pool management structure, using memory blocks in the second memory pool as the granularity. Reclaiming memory space based on the memory blocks in the second memory pool means reclaiming allocated memory blocks back to the second memory pool; releasing memory space based on the memory blocks in the second memory pool means releasing subpages belonging to free memory blocks in the second memory pool to the first memory pool. The processing module is further configured to allocate, reclaim, or release memory space for objects other than the second memory pool, using the memory pages in the first memory pool as the granularity, based on the first memory pool management structure. The effects and detailed implementation of the above-mentioned apparatus embodiment can be found in the aforementioned embodiments and will not be further elaborated here. Figure 5 is a schematic diagram of the structure of an electronic device provided by an exemplary embodiment of the present disclosure. As shown in Figure 5, the device includes a memory 54 and a processor 55. Memory 54 is configured to store computer programs and can be configured to store various other data to support operations on the electronic device. Examples of such data include instructions for any application or method operating on the electronic device. The memory 54 may be implemented by any type of volatile or non-volatile memory device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk. A processor 55 is coupled to the memory 54 and is configured to execute a computer program in the memory 54 to: manage a first memory pool using a first memory pool management structure, where the first memory pool includes at least one memory page requested from an operating system to provide allocatable memory space; manage a second memory pool using a second memory pool management structure, where the second memory pool includes memory blocks obtained by partitioning a target memory space, where the target memory space is requested from the memory pages in the first memory pool; and allocate memory space based on the second memory pool management structure, using the memory blocks in the second memory pool as a granularity, so that data allocated to the memory space is distributed among the memory pages included in the first memory pool.In an optional embodiment, the processor 55 is further configured to: obtain a first initial management structure, the first initial management structure including a first data structure and a second data structure; request at least one memory page from the operating system to form the first memory pool; record the first address of the at least one memory page in the first data structure, and initialize usage status record information corresponding to each memory page in the second data structure to a first value to indicate that each memory page is in an idle state; and copy the first initial management structure to a target memory page or a first memory block to obtain the first memory pool management structure; wherein the target memory page is a memory page in the first memory pool, and the first memory block is a memory block in the second memory pool. Optionally, when the processor uses the first memory pool management structure to manage the first memory pool, the processor may: if the second memory pool requests the target memory space from the first memory pool, set the usage status record information corresponding to the target memory space in the second data structure to a second value to indicate that the memory page belonging to the target memory space is in use. Further optionally, the memory page has a first page granularity and is divided into sub-pages of a second page granularity, the second page granularity being smaller than the first page granularity; the usage status record information corresponding to each memory page in the second data structure includes bits corresponding to each sub-page, and sub-pages belonging to the same memory page correspond to consecutive bits; for any bit, if the value is the first value, it indicates that the corresponding sub-page is in an idle state; if the value is the second value, it indicates that the corresponding sub-page is in an used state. Further optionally, the processor 55 is further configured to: when the second memory pool requests target memory space, search the first memory pool for at least one consecutive sub-page that is compatible with the target memory space and in a free state based on the usage of each memory page recorded in the second data structure; record the at least one consecutive sub-page in the second memory pool management structure, so that the at least one consecutive sub-page is allocated as the target memory space to the second memory pool, and set the bit position corresponding to the at least one consecutive sub-page in the second data structure to the second value. In an optional embodiment, the processor 55 is further configured to create a second memory management structure and a second memory pool.When creating the second memory management structure and the second memory pool, the processor 55 is specifically used to: obtain a second initial management structure, where the second initial management structure includes a local management structure corresponding to at least one memory block granularity, and copy the pre-created kernel management structure corresponding to the at least one memory block granularity to the corresponding local management structure; based on the second initial management structure, apply for a first memory space from the first memory pool, and divide the first memory space into memory blocks according to the at least one memory block granularity to obtain the second memory pool, where the first memory space belongs to the target memory space; copy the second initial management structure to the second memory block in the second memory pool to obtain the second memory pool management structure, and update the management object of the second memory pool from the second initial management structure to the second memory pool management structure. Optionally, the local management structure includes: a local information field, an associated information field, and a kernel information field; when the processor 55 copies the pre-created kernel management structure corresponding to the at least one memory block granularity into the corresponding local management structure, it is specifically used to: record the identification information of the kernel management structure corresponding to any memory block granularity into the kernel information field in the corresponding local management structure; copy the content in the kernel management structure corresponding to any memory block granularity into the local information field in the corresponding local management structure; copy the associated structure information of the kernel management structure corresponding to any memory block granularity into the associated information field in the corresponding local management structure. In an optional embodiment, when the processor 55 copies the pre-created kernel management structure corresponding to the at least one memory block granularity into the corresponding local management structure, the processor 55 is specifically configured to: copy the kernel management structure corresponding to the at least one memory block granularity with a set flag to the local management structure corresponding to the at least one memory block granularity for direct memory access; and / or copy the kernel management structure corresponding to the at least one memory block granularity without a set flag to the local management structure corresponding to the at least one memory block granularity for non-direct memory access. In an optional embodiment, the at least one memory block granularity includes at least one universal memory block granularity, and the local management structure corresponding to the at least one memory block granularity includes the local universal management structure corresponding to the at least one universal memory block granularity.The processor 55 is further configured to: request a third memory block from the second memory pool that matches the local management structure granularity based on the local management structure granularity; copy a kernel management structure corresponding to a pre-created dedicated memory block into the third memory block to obtain a local dedicated management structure; request a second memory space from the first memory pool based on the local dedicated management structure, and divide the second memory space into dedicated memory blocks, where the second memory space belongs to the target memory space; and add the local dedicated management structure to a linked list in the second memory pool management structure for managing local dedicated management structures. In an optional embodiment, the processor 55 is further configured to: request a specific memory page from the operating system in advance, where the page granularity of the specific memory page is greater than the page granularity of at least one memory page; add the specific memory page to the first memory pool, and manage the specific memory page using the first memory pool management structure. In an optional embodiment, the processor 55 is further configured to: reclaim and / or release memory space based on the second memory pool management structure, using memory blocks in the second memory pool as the granularity; where reclaiming refers to reclaiming allocated memory blocks back to the second memory pool; and releasing refers to releasing subpages belonging to free memory blocks in the second memory pool to the first memory pool. The processor 55 is further configured to: allocate, reclaim, or release memory space for objects other than the second memory pool, using the memory pages in the first memory pool as the granularity, based on the first memory pool management structure. A detailed description and effect of the electronic device can be found in the aforementioned embodiments and will not be repeated here. Furthermore, as shown in FIG5 , the electronic device also includes other components, such as a communication component 56, a display 57, a power supply component 58, and an audio component 59. FIG5 only schematically illustrates some components and does not imply that the electronic device includes only the components shown in FIG5 . Furthermore, the components within the dashed boxes in FIG5 are optional, not mandatory, and their specific requirements depend on the product form of the electronic device. The electronic device of this embodiment can be implemented as a terminal device such as a desktop computer, laptop computer, smartphone, or IOT device, or as a server-side device such as a conventional server, cloud server, or server array. If the electronic device of this embodiment is implemented as a terminal device such as a desktop computer, laptop computer, or smartphone, it may include the components within the dashed box in Figure 5. If the electronic device of this embodiment is implemented as a server-side device such as a conventional server, cloud server, or server array, it may not include the components within the dashed box in Figure 5. Accordingly, embodiments of the present disclosure also provide a computer-readable storage medium storing a computer program. When executed, the computer program can implement the steps executable by the processor in the above-described method embodiments.Accordingly, embodiments of the present disclosure further provide a computer program product, including a computer program / instructions. When the computer program / instructions are executed by a processor, the processor is caused to implement the steps that can be performed by the processor in the above-mentioned method embodiments. The above-mentioned memory can be implemented by any type of volatile or non-volatile storage device, or a combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk. The communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access a wireless network based on a communication standard, such as Wi-Fi, 2G, 3G, 4G / LTE, 5G, or other mobile communication networks, or a combination thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IRDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, or other technologies. The above-mentioned display includes a screen, and the screen may include a liquid crystal display (LCD) and a touch panel (TP).If the screen includes a touch panel, the screen can be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, slides, and gestures on the touch panel. The touch sensors can not only sense the boundaries of a touch or slide action, but also detect the duration and pressure associated with the touch or slide action. The power supply assembly described above provides power to various components of the device in which the power supply assembly is located. The power supply assembly may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply assembly is located. The audio assembly described above can be configured to output and / or input audio signals. For example, the audio assembly includes a microphone (MIC) that is configured to receive external audio signals when the device in which the audio assembly is located is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals may be further stored in a memory or transmitted via a communication component. In some embodiments, the audio assembly also includes a speaker for outputting audio signals. Those skilled in the art will appreciate that the embodiments of the present disclosure may be provided as methods, systems, or computer program products. Therefore, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present disclosure may take the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to disk storage, Compact Disc Read-Only Memory (CD-ROM), optical storage, etc.) containing computer-usable program code. The present disclosure is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present disclosure. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, such that the instructions, executed by the processor of the computer or other programmable data processing device, produce means for implementing the functions specified in one or more processes in the flowcharts and / or one or more blocks in the block diagrams.These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement the functions specified in one or more flow charts and / or one or more blocks in a block diagram. These computer program instructions may also be loaded onto a computer or other programmable data processing device, such that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more flow charts and / or one or more blocks in a block diagram. In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-permanent memory in a computer-readable medium, random access memory (RAM), and / or non-volatile memory, such as read-only memory (ROM) or flash memory. Memory is an example of a computer-readable medium. Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented using any method or technology for information storage. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.It should also be noted that the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, product, or apparatus comprising a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, product, or apparatus. Without further limitation, an element defined by the phrase "comprising a..." does not preclude the presence of additional identical elements in the process, method, product, or apparatus comprising the element. The foregoing are merely examples of the present disclosure and are not intended to limit the present disclosure. Those skilled in the art will readily appreciate that various modifications and variations of the present disclosure are possible. Any modifications, equivalent substitutions, improvements, and the like made within the spirit and principles of the present disclosure are intended to be encompassed by the claims of the present disclosure.

Claims

Claims 1. A memory management method, wherein: include: Managing a first memory pool using a first memory pool management structure, wherein the first memory pool includes at least one memory page requested from an operating system to provide allocatable memory space; A second memory pool is managed using a second memory pool management structure, where the second memory pool includes memory blocks obtained by dividing a target memory space, where the target memory space is requested from the memory pages in the first memory pool; and memory space is allocated based on the second memory pool management structure using the memory blocks in the second memory pool as a granularity, so that data allocated to the memory space is distributed in the memory pages included in the first memory pool.

2. The method according to claim 1, wherein: Also includes: Obtain a first initial management structure, where the first initial management structure includes a first data structure and a second data structure; apply for at least one memory page from the operating system to form the first memory pool; record the first address of the at least one memory page in the first data structure, and initialize usage status record information corresponding to each memory page in the second data structure to a first value to indicate that each memory page is in an idle state; copy the first initial management structure to a target memory page in the first memory pool or to a first memory block in the second memory pool to obtain the first memory pool management structure.

3. The method according to claim 2, wherein: Managing the first memory pool using the first memory pool management structure includes: when the second memory pool applies for the target memory space from the first memory pool, setting the usage status record information corresponding to the target memory space in the second data structure to a second value to indicate that the memory page belonging to the target memory space is in use.

4. The method according to claim 3, wherein: The memory page has a first page granularity, and the memory page is divided into sub-pages of a second page granularity, and the second page granularity is smaller than the first page granularity; the usage status record information corresponding to each memory page in the second data structure includes bits corresponding to each sub-page, and the sub-pages belonging to the same memory page correspond to continuous bits; for any bit, if the value is the first value, it indicates that the corresponding sub-page is in an idle state, and if the value is the second value, it indicates that the corresponding sub-page is in use.

5. The method according to claim 3 or 4, wherein: Also includes: When the second memory pool applies for target memory space, based on the usage of each memory page recorded in the second data structure, search the first memory pool for at least one continuous sub-page that is adapted to the size of the target memory space and is in an idle state; record the at least one continuous sub-page in the second memory pool management structure to allocate the at least one continuous sub-page as the target memory space to the second memory pool, and set the bit position corresponding to the at least one continuous sub-page in the second data structure to the second value.

6. The method according to any one of claims 1 to 5, wherein: Also includes: Acquire a second initial management structure, the second initial management structure including at least one local management structure corresponding to a memory block granularity, and copy the pre-created kernel management structure corresponding to the at least one memory block granularity into the corresponding local management structure; Based on the second initial management structure, applying for a first memory space from the first memory pool, and dividing the first memory space into memory blocks according to the at least one memory block granularity to obtain the second memory pool, The first memory space belongs to the target memory space; The second initial management structure is copied to the second memory block in the second memory pool to obtain the second memory pool management structure, and the management object of the second memory pool is updated from the second initial management structure to the second memory pool management structure.

7. The method according to claim 6, wherein: The local management structure includes: a local information field, an associated information field and a kernel information field; the kernel management structure corresponding to the at least one pre-created memory block granularity is copied to the corresponding local management structure respectively, including: recording the identification information of the kernel management structure corresponding to any memory block granularity into the kernel information field in the corresponding local management structure; copying the content in the kernel management structure corresponding to any memory block granularity into the local information field in the corresponding local management structure; copying the associated structure information of the kernel management structure corresponding to any memory block granularity into the associated information field in the corresponding local management structure.

8. The method according to claim 6 or 7, wherein: Copying the pre-created kernel management structure corresponding to the at least one memory block granularity to the corresponding local management structure respectively includes: copying the kernel management structure with a set mark corresponding to the at least one memory block granularity to the local management structure for direct memory access corresponding to the at least one memory block granularity; and / or copying the kernel management structure without a set mark corresponding to the at least one memory block granularity to the local management structure for non-direct memory access corresponding to the at least one memory block granularity.

9. The method according to any one of claims 6 to 8, wherein: The at least one memory block granularity includes at least one universal memory block granularity, and the local management structure corresponding to the at least one memory block granularity includes a local universal management structure corresponding to the at least one universal memory block granularity. The method also includes: applying for a third memory block adapted to the local management structure granularity from the second memory pool according to the local management structure granularity; copying the kernel management structure corresponding to the pre-created dedicated memory block to the third memory block to obtain a local dedicated management structure; based on the local dedicated management structure, applying for a second memory space from the first memory pool, and dividing the second memory space to obtain dedicated memory blocks, and the second memory space belongs to the target memory space; adding the local dedicated management structure to a linked list in the second memory pool management structure for managing local dedicated management structures.

10. The method according to any one of claims 1 to 9, wherein: Also includes: Requesting a specific memory page from the operating system in advance, where the page granularity of the specific memory page is greater than the page granularity of the at least one memory page; adding the specific memory page to the first memory pool, and managing the specific memory page using the first memory pool management structure.

11. The method according to any one of claims 1 to 10, wherein: It also includes at least one of the following operations: based on the second memory pool management structure, reclaiming or releasing memory space with the memory blocks in the second memory pool as the granularity; based on the first memory pool management structure, allocating, reclaiming or releasing memory space for other objects except the second memory pool with the memory pages in the first memory pool as the granularity.

12. A physical machine, wherein: The physical machine includes hardware resources and a host running on the hardware resources. A host operating system implements a virtualization layer between the hardware resources and the host operating system, the virtualization layer including a centralized memory management module; the centralized memory management module is configured to manage a first memory pool using a first memory pool management structure, the first memory pool including at least one memory page requested from the host operating system to provide allocatable memory space; A second memory pool is managed using a second memory pool management structure, where the second memory pool includes memory blocks obtained by dividing a target memory space, where the target memory space is requested from the memory pages in the first memory pool. Based on the second memory pool management structure, memory space is allocated to other functional modules in the virtualization layer at a granularity of the memory blocks in the second memory pool, so that data allocated to the memory space is distributed in the memory pages included in the first memory pool.

13. The physical machine according to claim 12, wherein: The centralized memory management module is further configured to: obtain a second initial management structure, the second initial management structure including at least one local management structure corresponding to a memory block granularity, and copy the pre-created kernel management structure corresponding to the at least one memory block granularity to the corresponding local management structure; Applying for a first memory space from the first memory pool based on the second initial management structure, and dividing the first memory space into memory blocks according to the at least one memory block granularity to obtain the second memory pool, wherein the first memory space belongs to the target memory space; The second initial management structure is copied to the second memory block in the second memory pool to obtain the second memory pool management structure, and the management object of the second memory pool is updated from the second initial management structure to the second memory pool management structure.

14. A physical machine, wherein: The physical machine includes hardware resources and a host operating system running on the hardware resources, and the operating system includes: a centralized memory management module and a traditional memory management module; the centralized memory management module is used to manage a first memory pool using a first memory pool management structure, the first memory pool including at least one memory page requested from the traditional memory management module to provide allocatable memory space; a second memory pool is managed using a second memory pool management structure, the second memory pool including memory blocks obtained by segmenting a target memory space, the target memory space being requested from the memory pages in the first memory pool; based on the second memory pool management structure, memory space is allocated with the memory blocks in the second memory pool as a granularity, so that data allocated to the memory space is distributed in the memory pages included in the first memory pool.

15. An electronic device, wherein: include: memory and processor; The memory is used to store computer programs; The processor, coupled to the memory, is configured to execute the computer program to implement the steps in any one of the methods of claims 1 to 1.

16. A computer-readable storage medium storing a computer program, wherein: When the computer program is executed by a processor, the processor is caused to implement the steps of the method according to any one of claims 1 to 1.

17. A computer program product comprising a computer program / instructions, wherein: When the computer program / instructions are executed by a processor, the processor is caused to implement the steps of any one of the methods of claim 1 to 1.

Images