Memory control method, computing device, storage medium, and program product

Abstract

Embodiments of the present application provide a memory control method, a computing device, a computer readable storage medium and a computer program product. The memory control method is applied to a first memory controller. The first memory controller obtains request context information of a memory allocation request. According to the request context information, a target resource control category matched by the memory allocation request is determined from a plurality of resource control categories. It is checked whether a memory block corresponding to the target resource control category exists. If yes, memory allocation is performed based on the memory block. If no, a corresponding memory block is applied for the target resource control category from a physical memory, and memory allocation is performed based on the memory block. The technical solution provided by the embodiments of the present application can inhibit the generation of memory fragmentation.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a memory control method, computing device, computer-readable storage medium, and computer program product. Background Technology

[0002] Memory allocation refers to the process of allocating a block of memory from physical memory for use based on a memory allocation request triggered by a user-mode process or the kernel.

[0003] In related technologies, memory blocks that meet the allocation criteria are usually randomly searched in physical memory based on the required memory size. However, this memory allocation method can lead to severe memory fragmentation in scenarios with frequent memory allocation and deallocation, affecting resource utilization.

[0004] Therefore, how to effectively suppress memory fragmentation has become an urgent technical problem to be solved. Summary of the Invention

[0005] This application provides a memory control method, a computing device, a computer-readable storage medium, and a computer program product to solve the technical problem of how to effectively suppress memory fragmentation.

[0006] In a first aspect, this application provides a memory control method applied to a first memory controller, the method comprising:

[0007] Obtain the request context information of the memory allocation request;

[0008] Based on the request context information, determine the target resource control category that matches the memory allocation request from multiple resource control categories;

[0009] Check if a memory block corresponding to the target resource control category exists;

[0010] If so, memory allocation is performed based on the aforementioned memory block;

[0011] If not, request a corresponding memory block for the target resource control category from physical memory, and perform memory allocation based on the memory block.

[0012] Secondly, this application provides a memory control method applied to a second memory controller, which is deployed in kernel space. The method includes:

[0013] Obtain the request context information of the memory allocation request;

[0014] Based on the request context information, the first memory controller is invoked, so that the first memory controller can determine the target resource control category matching the memory allocation request from a plurality of pre-set resource control categories according to the request context information, and if there is a memory block corresponding to the target resource control category, memory allocation is performed based on the memory block; otherwise, a corresponding memory block is requested from physical memory for the target resource control category, and memory allocation is performed based on the memory block.

[0015] Thirdly, this application provides a first memory controller, which includes:

[0016] The first acquisition module is used to acquire the request context information of the memory allocation request;

[0017] The first category determination module is used to determine the target resource control category that matches the memory allocation request from multiple resource control categories based on the request context information.

[0018] The first search module is used to search for whether a memory block corresponding to the target resource control category exists;

[0019] The first memory allocation module is used to allocate memory based on the memory block when a memory block corresponding to the target resource control category exists.

[0020] The second memory allocation module is used to request a corresponding memory block for the target resource control category from physical memory when there is no memory block corresponding to the target resource control category, and to perform memory allocation based on the memory block.

[0021] Fourthly, this application provides a second memory controller, which includes:

[0022] The second acquisition module is used to acquire the request context information of the memory allocation request;

[0023] The first invocation module is used to invoke the first memory controller based on the request context information, so that the first memory controller can determine the target resource control category matching the memory allocation request from a plurality of pre-set resource control categories according to the request context information, and perform memory allocation based on the memory block if a memory block corresponding to the target resource control category exists; otherwise, it can request a corresponding memory block for the target resource control category from physical memory and perform memory allocation based on the memory block.

[0024] Fifthly, this application provides a computing device, including a processing component and a storage component;

[0025] The storage component stores a computer program; the computer program is invoked and executed by the processing component to run a first memory controller and a second memory controller in the kernel space. The first memory controller is used to implement the memory control method provided in the embodiments of this application, and the second memory controller is used to implement the memory control method provided in the embodiments of this application.

[0026] Sixthly, this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processing component, implements the memory control method provided in this application.

[0027] In a seventh aspect, this application provides a computer program product, including a computer program or instructions, which, when executed by a processing component, implement the memory control method provided in this application.

[0028] In this embodiment, memory allocation is aggregated according to resource control categories, thereby allocating contiguous memory blocks from physical memory for each resource control category. Then, based on the request context information of the memory allocation request, the system first identifies the target resource control category matched by the memory allocation request, and then allocates memory based on the memory block corresponding to the target resource control category. This ensures that memory allocation requests of the same resource control category are aggregated into the same memory block for allocation. Through this two-layer physical memory management and memory allocation method that aggregates memory allocation requests of the same resource category, fine-grained control of memory allocation is achieved. Memory of different resource control categories is isolated from each other at the allocation source, avoiding interleaved allocation. This allows memory adapted to the same resource control category to be allocated and released centrally, effectively suppressing memory fragmentation and thus improving resource utilization.

[0029] These or other aspects of this application will become more apparent in the following description of the embodiments. Attached Figure Description

[0030] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0031] Figure 1 A flowchart illustrating a memory control method provided in one embodiment of this application;

[0032] Figure 2 A flowchart illustrating a memory control method provided in another embodiment of this application;

[0033] Figure 3 A schematic diagram of a memory control method provided in an embodiment of this application;

[0034] Figure 4 A block diagram of a first memory controller provided in one embodiment of this application;

[0035] Figure 5 A block diagram of a second memory controller provided for another embodiment of this application;

[0036] Figure 6 This is a block diagram of a computing device provided in one embodiment of this application. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0038] It should be noted that, in the cases involving user information in the embodiments of this application, 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, stored data, displayed data, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse. In addition, the various models involved in this application (including but not limited to language models or large models) comply with relevant laws and standards.

[0039] With the rapid development of technologies such as artificial intelligence (AI), deep learning, big data analytics, and cloud computing, various computationally intensive and high-concurrency workloads are placing increasingly higher demands on the memory management efficiency of computer systems. Memory management includes memory allocation operations. Memory allocation refers to the process of requesting a memory block of a certain size based on memory allocation requests from user-mode processes or the kernel, typically in 4KB (kilobyte) small page granularity or 2MB (megabyte) or larger large page granularity, and then allocating it from physical memory.

[0040] Currently, buddy allocators are commonly used to manage physical memory. A buddy allocator organizes physical memory into memory blocks (buddies) in powers of 2, and during memory allocation, it searches for memory blocks that meet the allocation requirements. In developing this application, the inventors discovered that memory allocation efficiency, especially for large-page granularity memory allocation, depends on the availability of contiguous physical memory. Frequent memory allocation and deallocation easily leads to memory fragmentation, hindering large-page allocation, forcing the system to revert to small-page mode, and weakening performance advantages. The memory fragmentation problem is particularly severe in long-running, high-concurrency AI applications.

[0041] To address the memory fragmentation problem, the inventors, through a series of studies, discovered that memory objects corresponding to memory allocation requests, such as user-mode processes and containers with memory needs, or kernel memory such as dentry (directory entry) and page table, belong to the same memory cgroup (memcg) and have similar lifecycles. However, kernel memory is often non-movable and cannot be reclaimed, which is the main cause of a large amount of memory fragmentation. The inventors wondered if memory cgroups or kernel memory could be treated as resource control categories, and memory management could be carried out according to the resource control category dimension, so that memory objects of the same resource control category could be aggregated and allocated.

[0042] Based on this discovery, the inventors innovatively proposed the technical solution of this application: The basic idea is to aggregate allocation according to resource control categories, thereby allocating contiguous memory blocks from physical memory for each resource control category. Then, based on the request context information of the memory allocation request, the system first identifies the target resource control category matched by the memory allocation request, and then allocates memory based on the memory block corresponding to the target resource control category. This ensures that memory allocation requests of the same resource control category are aggregated into the same memory block for allocation. Through this two-layer physical memory management and memory allocation method that aggregates memory allocation requests of the same resource category, fine-grained control of memory allocation is achieved. Memory of different resource control categories is isolated from each other at the allocation source, avoiding interleaved allocation. This allows memory adapted to the same resource control category to be allocated and released centrally, effectively suppressing memory fragmentation and thus improving resource utilization.

[0043] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0044] The implementation details of the technical solutions in the embodiments of this application are described in detail below.

[0045] Figure 1 The flowchart illustrates a memory control method provided in one embodiment of this application. This method can be applied to a first memory controller, which can run in kernel space.

[0046] Figure 1 The memory control method shown may include the following steps:

[0047] 101: Obtain the request context information for the memory allocation request.

[0048] 102: Based on the request context information, determine the target resource control category that matches the memory allocation request from multiple resource control categories.

[0049] Memory allocation requests can be initiated by user-mode processes or the kernel. Memory allocation requests initiated by user-mode processes will also enter the kernel space for processing. In this embodiment, the first memory controller running in the kernel space can first obtain the request context information of the memory allocation request.

[0050] The request context information can refer to metadata captured before the memory allocation operation, which may include resource control category identifiers, such as memcg identifier, call stack information, or kernel memory type.

[0051] This application's embodiments can be tailored to actual needs, for example, by pre-setting multiple resource control categories based on resource ownership and / or usage ownership dimensions. These could include `memcg` (resource ownership dimension) and call stack or kernel memory type (use ownership dimension). When a memory allocation request is executed, its resource ownership or usage ownership dimension can be dynamically determined; that is, its corresponding resource control category identifier can be dynamically captured. Furthermore, based on the request context information, the target resource control type matching the memory allocation request can be determined.

[0052] As described above, each memory allocation request corresponds to a memory object, such as a user-mode process, container, or kernel object, which determines the target resource control type that the memory object matches.

[0053] In the embodiments of this application, the inventors discovered during the process of realizing the concept of this application that memory objects corresponding to memory allocation requests with different resource ownership dimensions and / or usage ownership dimensions often have significant differences in their lifecycles. For example, some memory objects have a short lifespan and are frequently allocated and released, while other memory objects have a long lifespan and remain occupied for a long time. When these two types of memory objects with different lifecycles are mixed and distributed in the same contiguous physical memory region, the release of short-lifecycle objects will form irregular gaps between long-lifecycle objects, breaking the originally contiguous physical memory blocks, thus leading to memory fragmentation. By mapping memory allocation requests with different resource ownership dimensions and usage ownership dimensions to corresponding resource control categories, each resource control category can correspond to a type of memory allocation request with a common resource ownership dimension and / or usage ownership dimension. Since the memory objects corresponding to memory allocation requests with the same resource ownership dimension and usage ownership dimension have similar lifecycle characteristics, the allocation and release of these memory objects are more likely to occur within the same physical block. Therefore, memory can be allocated or released in a piecemeal or grouped manner to form a continuous free area and avoid the formation of interspersed fragmented gaps in physical memory. This allows these memory allocation requests to be managed separately at the physical level, thereby reducing the random mixing and distribution of memory with different resource ownership and usage ownership dimensions, and avoiding the generation of physical memory fragmentation.

[0054] After determining the target resource control category corresponding to the memory allocation request, the first memory controller can check whether a memory block already exists in the target resource control category that can be used to carry the memory allocation request.

[0055] 103: Check if a memory block corresponding to the target resource control category exists.

[0056] 104: If so, memory allocation is performed based on memory blocks.

[0057] 105: If not, request the corresponding memory block for the target resource control category from physical memory, and perform memory allocation based on the memory block.

[0058] In this context, a memory block can be a segment of physical memory allocated for a certain resource control category. This segment of physical memory can be used only for memory allocation requests corresponding to that resource control category during subsequent memory allocation processes, so that memory allocation requests with the same resource ownership dimension and / or purpose ownership dimension remain relatively clustered in the physical space.

[0059] In embodiments of this application, the search for the existence of a memory block corresponding to a target resource control category can be achieved through a pre-maintained or dynamically maintained memory block mapping relationship. The first memory controller can index the memory block mapping relationship based on the identifier of the target resource control category and determine whether there is a physical memory region available for allocation. If the found memory block has been established and has available space for partitioning, the first memory controller can directly perform an allocation operation within the memory block. By further dividing the free area inside the memory block into sub-intervals that meet the allocation requirements, a physical address is generated and finally returned to the caller, ensuring that multiple memory allocation requests belonging to the same resource control category are always concentrated in the same physical region.

[0060] If, during the search, it is found that no corresponding memory block has been created for this resource control class in the current system, it indicates that this is the first time memory allocation has been initiated for this memory control class, or that all previous memory blocks have been used and there is no space available for allocation. In this case, the first memory controller can request a new contiguous physical region from the underlying physical memory of the system and use it as a dedicated memory block for this resource control class.

[0061] In the embodiments of this application, a two-layer management mechanism is adopted, which can request a block of memory with contiguous addresses from physical memory as the resource control category with a preset size as the granularity. This allows memory allocation operations corresponding to the same resource control category to be performed in their corresponding memory blocks, thereby ensuring that the memory of this category is not mixed with other categories.

[0062] After the newly allocated memory block is created, the first memory controller can update the mapping relationship between the resource control category and the memory block, and divide the memory block into a portion that satisfies the current allocation request, and return it as the final allocation result to the requester.

[0063] As a result, even if the resource control category did not previously have a corresponding memory space, an independent physical region can be dynamically created and used, so that subsequent allocations of the resource control category can continue to aggregate within this region, avoiding fragmentation in memory due to interleaving with other categories.

[0064] In this embodiment, memory allocation is aggregated according to resource control categories, thereby allocating contiguous memory blocks from physical memory for each resource control category. Then, based on the request context information of the memory allocation request, the system first identifies the target resource control category matched by the memory allocation request, and then allocates memory based on the memory block corresponding to the target resource control category. This ensures that memory allocation requests of the same resource control category are aggregated into the same memory block for allocation. Through this two-layer physical memory management and memory allocation method that aggregates memory allocation requests of the same resource category, fine-grained control of memory allocation is achieved. Memory of different resource control categories is isolated from each other at the allocation source, avoiding interleaved allocation. This allows memory adapted to the same resource control category to be allocated and released centrally, effectively suppressing memory fragmentation and thus improving resource utilization.

[0065] In the embodiments of this application, since different memory allocation requests may have different requirements in terms of size, alignment, or other resource attributes, even if a certain resource control category already has a corresponding memory block, there may be a situation where the remaining available space in that memory block is insufficient to complete the current allocation. Based on this, in some embodiments, checking whether there is a memory block corresponding to the target resource control category can specifically be implemented as: checking whether there is a memory block corresponding to the target resource control category that meets the allocation requirements.

[0066] In one optional implementation, checking whether there exists a memory block corresponding to the target resource control category and meeting the allocation requirements can be specifically implemented as: checking whether there exists a memory block corresponding to the target resource control category and whose free memory space is greater than the requested memory size.

[0067] After locating the memory block corresponding to the target resource control category, the first memory controller can further detect whether the memory block of the target resource control category has free memory space that matches the memory size required by the current memory allocation request. For example, it can detect whether there is a contiguous physical space that can be partitioned to allocate that memory size. If the detection result shows that the memory block not only exists but also meets the allocation requirements, the first memory controller can directly perform allocation within the memory block, allocating the free area that matches the requested memory size to the current request, so that allocation requests of the same resource control category continue to gather within the same physical area.

[0068] If, although a memory block corresponding to the target resource control category exists, the memory block is already partially used and no longer has contiguous free space to meet the current allocation requirements, or its remaining space cannot meet the structural requirements of the current memory allocation request, then a new memory block can be requested from physical memory as an extension memory block for the target resource control category. After obtaining the new memory block, the first memory controller then completes the current memory allocation operation based on the newly requested memory block.

[0069] By determining whether allocation requirements are met on demand, we can not only avoid forcing unsuitable memory blocks into allocation, which could lead to more serious fragmentation problems later, but also ensure that allocation behaviors corresponding to the same resource control category remain continuous in physical memory, thereby further consolidating the effect of physical isolation.

[0070] In traditional implementations, after a memory allocation request enters the kernel, the memory allocation operation is usually performed by calling a memory allocation function. Therefore, the technical solution of the embodiments of this application can be implemented in a lightweight intrusion manner. In some embodiments, a second memory controller can also be deployed and run in the kernel space.

[0071] The above-mentioned acquisition of the request context information corresponding to the memory allocation request can be specifically implemented as follows: based on the first call request of the second memory controller, the request context information corresponding to the memory allocation request is acquired; the first call request is generated by the second memory controller intercepting the call operation of the memory allocation function; the call operation of the memory allocation function is executed in response to the memory allocation request.

[0072] In the embodiments of this application, a separate architecture design is adopted, in which a second memory controller is lightweightly embedded in the traditional memory management path to capture or monitor the call operations of memory allocation functions, and generates a first call request after capturing the call behavior. This first call request carries the runtime information of the allocation trigger point, including the call behavior itself and context fragments that can be used to identify the source of the allocation behavior. The first call request is responded to by the first memory controller, enabling it to obtain the request context information that led to the current allocation trigger before actually executing the allocation logic.

[0073] When the second memory controller intercepts a call to a memory allocation function, it can extract metadata associated with that call from the current kernel runtime state. After collecting this metadata, the second memory controller can generate request context information.

[0074] In one possible implementation, the second memory controller can call an interface provided by the first memory controller to send the request context information to the first memory controller. Thus, before the kernel actually enters the memory allocation phase, the first memory controller has already obtained the request context information that identifies the source of the allocation, thereby providing basic data support for subsequent operations such as selecting resource control categories and searching for or requesting memory blocks based on the request context information.

[0075] In another possible implementation, obtaining the request context information corresponding to the memory allocation request based on the first call request of the second memory controller can be specifically implemented as follows: based on the first call request of the second memory controller, obtain the request context information corresponding to the memory allocation request from the kernel variables; the request context information is obtained from the runtime data and saved to the kernel variables when the second memory controller intercepts the call operation to the memory allocation function.

[0076] In the embodiments of this application, kernel variables can be implemented per-cpu, where per-cpu refers to variables provided for each CPU (Central Processing Unit).

[0077] After the second memory controller intercepts the memory allocation function call and obtains the request context information, it can write the request context information into a kernel variable shared by the first and second memory controllers. Once written, the second memory controller initiates the first call request through a callback interface pre-registered by the first memory controller, redirecting control flow to the first memory controller. Before entering the allocation logic, the first memory controller can read the corresponding request context information from this kernel variable. In this way, the first memory controller does not need to wait for an explicit call request from the second memory controller, nor does it need to establish additional synchronization or messaging mechanisms between the two. It can quickly obtain the request context information simply by accessing the shared kernel variable, resulting in lower latency and a simpler call path. It also avoids potential duplicate calls or blocking issues in high-concurrency scenarios, thus ensuring the efficiency and stability of the entire memory control process.

[0078] In some embodiments, after memory allocation is performed based on memory blocks, the method may further include: clearing request context information in kernel variables.

[0079] Once the first memory controller completes memory allocation based on the memory block of the target resource control category, it can clear or invalidate the request context information stored in kernel variables. By clearing the kernel variables, it prevents the context information of this allocation from leaking into subsequent unrelated allocation requests and causing incorrect classification. It also ensures that the current thread can restore its initial runtime state after leaving the intercepted memory allocation path.

[0080] In some embodiments, determining the target resource control category matching the memory allocation request from a plurality of pre-set resource control categories based on the request context information can be specifically implemented as follows: determining the corresponding target resource control category based on the memory control group identifier, kernel memory type, or call stack information in the request context information.

[0081] In some embodiments, determining the corresponding target resource control category based on the memory control group identifier, kernel memory type, or call stack information in the request context information can be specifically implemented as follows:

[0082] Determine if a memory control group identifier exists in the request context information;

[0083] If so, determine the resource control category corresponding to the memory control group identifier as the target resource control category;

[0084] If not, based on the kernel memory type or call stack information in the request context information, search for the target memory allocation rule that matches the kernel memory type or call stack information from at least one memory allocation rule, and determine the resource control category in the target memory allocation rule as the target resource control category.

[0085] In one embodiment of this application, when the request context information includes a memory control group identifier, the memory control group identifier corresponds to a memcg. The memory allocation request is used to request memory allocation for a user-mode process or container. The user-mode process or container belongs to a certain memcg. The first memory controller can determine the resource control category corresponding to the memory control group identifier as the target resource control category. That is, in this embodiment of the application, memcg can be used as a resource control category.

[0086] In this way, a unique resource control category can be pre-assigned to each memcg, thereby ensuring that all memory allocation behaviors of the same user-space process or container are completed within the same memory block, thus avoiding memory interleaving between different workloads.

[0087] In another embodiment of this application, when the request context information does not contain a valid memory control group identifier (i.e., the allocation request originates from the kernel mode itself), the first memory controller can determine the resource control category based on the kernel memory type or call stack information carried in the request context information.

[0088] In the embodiments of this application, finding at least one memory allocation rule based on the kernel memory type or call stack information in the request context information can be implemented as follows: finding at least one memory allocation rule based on a pre-configured mapping table.

[0089] The mapping table can be configured with mapping relationships between kernel memory types or call stack information and memory allocation rules. The first memory controller can match the kernel memory type or call stack information in the request context information with the mapping relationships recorded in the mapping table. If the kernel memory type or call stack information in the request context information matches any mapping relationship, the memory allocation rule recorded in that mapping relationship can be determined as the target memory allocation rule. Further, the target resource control category specified in the target memory allocation rule can be determined.

[0090] In some embodiments, the method may further include:

[0091] In response to rule configuration instructions, determine and save any configured memory allocation rule; rule configuration instructions are generated based on configuration operations for the target kernel interface;

[0092] In response to a rule update command, update any of the specified memory allocation rules.

[0093] In the embodiments of this application, the first memory controller supports dynamic configuration and updating of memory allocation rules during operation, thereby enabling the adjustment of the classification strategy of non-movable memory objects in the kernel without system restart, in order to adapt to the ever-changing workload characteristics or fragmentation management needs.

[0094] In one embodiment of this application, a writable target kernel interface can be exposed in the kernel. This target kernel interface can be used to receive rule configuration instructions from user space. When a new memory allocation rule needs to be added, a configuration line in the format "<symbol name> + <offset>: <target resource control class name>" can be written to the target kernel interface, for example, by executing:

[0095] Adding a rule can be done by echoing "__d_alloc+29:dentry" > / sys / kernel / mm / frontbuddy / rule_table.

[0096] The symbol name can represent the name of a function in the kernel; in the example above, it is the core function __d_alloc allocated by dentry.

[0097] The offset can be represented inside the __d_alloc function, at a position 29 bytes from the function entry point. This offset can be determined through disassembly.

[0098] The target resource control class name can be represented as the target resource control class determined by all physical memory allocation requests originating from that precise instruction location. In the example above, the target resource control class is determined to be "dentry". As a result, the physical pages of all dentry objects will remain concentrated in the same contiguous region throughout their entire lifecycle, and will not be interleaved with other types of objects during deallocation, thus completely eliminating memory fragmentation caused by this type of memory object.

[0099] In actual configuration operations, the above echo command can be executed in user space, and kallsyms_lookup_name() can be used to resolve "__d_alloc" into a kernel virtual address; 29 bytes are added to this address to obtain the precise instruction address; a new mapping is added to the internal rule chain: when the precise return address appears in the call stack, the current allocation request is determined to be the target resource control category "dentry".

[0100] After configuring the memory allocation rules described above, all memory allocation requests that pass through the __d_alloc function at an offset of 29 bytes (i.e., all physical page allocations of dentry objects) will be allocated to the memory block corresponding to the resource control class "dentry" without requiring any modification to the kernel source code or recompilation.

[0101] This "symbol + offset" notation is both precise (precise to a single instruction) and flexible enough. By finding the actual allocation call point through disassembly, the physical memory allocation path of any kernel object can be incorporated into fine-grained fragmentation management, thus achieving runtime hot configuration capability.

[0102] When it is necessary to modify or delete an existing rule, the user can write a rule update command with an update flag or a delete flag to the same interface. After receiving the update command, the first memory controller can accurately locate the original entry in the rule table and replace the target resource control category it points to in real time, or directly remove it from the list.

[0103] Since the addition, deletion, and modification of rules can be completed at runtime without relying on kernel recompilation or module reloading, new kernel memory allocation paths can be configured as memory allocation rules in a production environment based on the actual observed memory fragmentation situation, or paths that no longer generate fragmentation can be released from the special category, thereby achieving continuous optimization of the fragmentation management strategy.

[0104] In some embodiments, the method may further include:

[0105] If the kernel memory type or call stack information does not match any target memory allocation rule, determine that the memory allocation request matches a predefined allocation rule; and determine that the predefined resource control category specified in the predefined allocation rule is the target resource control category.

[0106] In the embodiments of this application, during the process of the first memory controller matching the target resource control category based on the kernel memory type or call stack information in the request context information, if after traversing all configured memory allocation rules, no memory allocation rule matching the current call stack return address or kernel memory type is found, it indicates that the kernel object type to which this memory allocation request belongs has not yet been included in the scope of memory control. To avoid such non-movable kernel memory objects not covered by memory allocation rules continuing to use the global buddy allocator and thus generating fragmentation, the first memory controller can adopt a conservative and safe fallback strategy, that is, uniformly classify such memory allocation requests into a pre-created special predetermined resource control category.

[0107] In some embodiments, requesting a corresponding memory block for the target resource control category from physical memory can be specifically implemented as follows: based on the memory size in the request context information, requesting a memory block of an integer multiple of the first size from the physical memory managed by the buddy allocator for the target resource control category.

[0108] When requesting additional memory, the first memory controller can request it in a fixed granularity (i.e., a first size), which can be, for example, 2MB, 1GB (Gigabyte), or other values.

[0109] In one example, suppose the first size is set to 2MB, and the current memory allocation request requests 3MB of memory. In this case, since requesting a 3MB memory block might result in fragmentation, the first memory controller can request a memory block that is an integer multiple of the first size instead of directly requesting an exact 3MB block. For example, the first memory controller can calculate the minimum integer multiple of the first size required based on the requested 3MB size: since 3MB is greater than 1×2MB (2MB) but less than 2×2MB (4MB), it can round up to the nearest integer multiple, i.e., request a memory block twice the first size, which is a contiguous 4MB physical memory block.

[0110] In this way, even if the memory allocation request does not request a memory block that is an exact multiple of the first size, it can be guaranteed that the supplementary memory block is always large-granular and contiguous, thereby maintaining the physical continuity within the class and reducing overall fragmentation.

[0111] In some embodiments, the second memory controller is used to set hooks for memory allocation functions to intercept calls to memory allocation functions; the method may further include: requesting registration of the first memory controller in the hook in response to a load instruction; the second memory controller is used to intercept calls to memory allocation functions using the hooks and initiate a first call request based on the registration information in the hooks; the load instruction is generated after the first memory controller is installed in the kernel space.

[0112] In the embodiments of this application, the second memory controller can be compiled independently as a loadable kernel module, serving as a lightweight front-end. After system startup, the user can install and load the second memory controller as needed. After loading, the second memory controller can set hooks on key functions of the memory allocation path (such as rmqueue, __alloc_pages_slowpath, etc.) using methods such as kprobe (a dynamic debugging tool) or ftrace (a dynamic tracing tool). This application does not limit this.

[0113] Once the first memory controller is installed into kernel space, the system generates a load instruction to instruct the second memory controller to register the first memory controller with the hook. Registration information may include, for example, the entry address or calling interface of the first memory controller. This allows the hook to intercept a memory allocation function call, determine the appropriate memory call request to be sent to the first memory controller based on the registration information, and pass the intercepted call information to the first memory controller for parsing and use.

[0114] In one embodiment of this application, after the second memory controller sets a hook for the memory allocation function, when the memory allocation function is called, it can first check whether the first memory controller is registered. If the first memory controller is registered, the second memory controller can perform an interception operation; otherwise, if the first memory controller is not registered, it can directly call the memory allocation function to handle the memory allocation request, perform the memory allocation operation, and return to the kernel native path.

[0115] By checking whether the first memory controller is registered and determining the memory allocation path based on the check result, hot-swapping of memory aggregation can be achieved on the one hand, and compatibility between the memory control method provided in this application embodiment and the original memory allocation path can also be achieved on the other hand.

[0116] In some embodiments, the method may further include: requesting the unregistering of a first memory controller in a hook in response to an unload instruction; the unload instruction is generated in response to an unload operation on the first memory controller.

[0117] When an unload operation is triggered against the first memory controller, it can be determined that the second memory controller needs to be unloaded. Further, an unload instruction can be triggered. In response to the unload instruction, the second memory controller can find the registration information of the first memory controller in the hook and remove this registration information from the hook, so that the hook handler will no longer send memory call requests to the first memory controller in subsequent memory allocation function calls.

[0118] In the embodiments of this application, a dynamic registration and deregistration mechanism can be adopted between the first memory controller and the second memory controller to enable hot-swapping of the first memory controller during runtime. This ensures that the fragmentation suppression function can be enabled or disabled at any time without restarting the kernel or interrupting any running workloads. Furthermore, when it is necessary to disable memory aggregation, the original memory allocation path can be returned by unloading the first memory controller. This improves the flexibility of memory allocation: when the first memory controller is not registered or is deregistered, the memory allocation path can fall back to the native buddy allocator, avoiding any compatibility issues; and when memory aggregation is needed, the first memory controller is registered to suppress memory fragmentation.

[0119] The memory control method provided in this application is not only applicable to memory allocation scenarios, but also to memory processing scenarios such as memory release, reclamation, page migration / flattening, and statistics. In some embodiments, the method may further include: obtaining processing context information of a memory processing request; determining the target resource control category corresponding to the memory processing request from a plurality of pre-set resource control categories based on the processing context information; finding the memory block corresponding to the target resource control category, and performing memory processing on the memory block according to processing information.

[0120] In some embodiments, obtaining the processing context information of a memory processing request can be specifically implemented as follows:

[0121] Based on the second call request from the second memory controller, the processing context information is determined; the second call request is generated by the second memory controller intercepting the call operation of the memory processing function; the call operation of the memory processing function is executed in response to the memory processing request.

[0122] When memory processing operations such as memory release, reclamation, page migration / flattening, and statistics need to be performed, similar to the memory allocation scenario, the second memory controller can set hooks at the functions used to handle the corresponding memory processing operations. If these functions are triggered, the second memory controller can collect the current processing context information in a manner similar to memory allocation, write this information into kernel variables, and then redirect the control flow to the first memory controller through a second call request.

[0123] After receiving the second call request, the first memory controller can, similarly, first read the processing context information from the kernel variables and determine the target resource control category for this memory processing operation according to a mechanism similar to that of the allocation phase.

[0124] Once the target resource control category is determined, the first memory controller can perform the corresponding memory processing operations in the memory block corresponding to that target resource control category.

[0125] For the release operation, memory can be returned to the corresponding memory block to satisfy subsequent allocation requests of the same type;

[0126] For recycling operations, scanning and recycling can be performed only on the memory blocks corresponding to that category to avoid cross-category interference;

[0127] For migration / flattening operations, both the source and target memory blocks are limited to memory blocks of the same category.

[0128] For statistical operations, the statistical scope is also limited to the memory blocks corresponding to the specified categories, enabling administrators to accurately grasp the availability and fragmentation level of contiguous memory for each category.

[0129] Figure 2 The flowchart illustrates a memory control method provided in another embodiment of this application. This method can be applied to a second memory controller, which is deployed in the kernel space.

[0130] Figure 2 The memory control method shown may include the following steps:

[0131] 201: Get the request context information for the memory allocation request;

[0132] 202: Based on the request context information, the first memory controller is invoked so that the first memory controller can determine the target resource control category that matches the memory allocation request from a plurality of pre-set resource control categories according to the request context information, and if there is a memory block corresponding to the target resource control category, memory allocation is performed based on the memory block; otherwise, the corresponding memory block for the target resource control category is requested from physical memory, and memory allocation is performed based on the memory block.

[0133] In this embodiment, memory allocation is aggregated according to resource control categories, thereby allocating contiguous memory blocks from physical memory for each resource control category. Then, based on the request context information of the memory allocation request, the system first identifies the target resource control category matched by the memory allocation request, and then allocates memory based on the memory block corresponding to the target resource control category. This ensures that memory allocation requests of the same resource control category are aggregated into the same memory block for allocation. Through this two-layer physical memory management and memory allocation method that aggregates memory allocation requests of the same resource category, fine-grained control of memory allocation is achieved. Memory of different resource control categories is isolated from each other at the allocation source, avoiding interleaved allocation. This allows memory adapted to the same resource control category to be allocated and released centrally, effectively suppressing memory fragmentation and thus improving resource utilization.

[0134] In some embodiments, obtaining the request context information corresponding to the memory allocation request can be specifically implemented as follows:

[0135] The system intercepts calls to memory allocation functions, obtains the request context information corresponding to the memory allocation request, and saves it to kernel variables; the first memory controller is used to obtain the request context information from the kernel variables.

[0136] In some embodiments, the method may further include:

[0137] Obtain the processing context information for the memory processing request;

[0138] Based on the processing context information, the first memory controller is invoked, so that the first memory controller can determine the target resource control category corresponding to the memory processing request from a number of pre-set resource control categories according to the processing context information; find the memory block corresponding to the target resource control category, and perform memory processing on the memory block according to the processing information.

[0139] In some embodiments, intercepting calls to memory allocation functions can be specifically implemented as follows:

[0140] Set hooks for memory allocation functions to intercept their calls.

[0141] In some embodiments, the above-mentioned acquisition of the request context information corresponding to the memory allocation request may include:

[0142] The hook is used to intercept calls to the memory allocation function;

[0143] Check if the first memory controller is registered;

[0144] If so, obtain the request context information corresponding to the memory allocation request;

[0145] If not, the memory allocation function is invoked to process the memory allocation request.

[0146] Specifically, the first memory controller can be invoked based on the registration information in the hook. If the first memory controller is not registered, the original allocation method can continue to be used for allocation operations, thus achieving compatibility with the original allocation method.

[0147] The detailed implementation methods and beneficial effects of each step in this embodiment have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0148] For ease of understanding, Figure 3 This is a schematic diagram of a memory control process in a practical application of this application.

[0149] The memory control method provided in this application runs in the operating system kernel space. It achieves classified management and physical isolation of multi-source memory allocation through a lightweight intrusion of the first memory controller and the hot-swappable deployment of the second memory controller. The second memory controller, acting as a front-end interception module, is loaded into the kernel and sets hooks in memory allocation functions to capture function calls and obtain request context information related to the current memory allocation, thus achieving lightweight intrusive instrumentation of memory allocation operations. After intercepting an allocation operation, the second memory controller can write the request context information to a shared kernel region with the first memory controller, passing the request context information to the first memory controller via shared memory. This layered architecture design, with instrumentation at the front end (second memory controller) and modularity at the back end (first memory controller), ensures that the front end only handles request interception and context passing, while the back end independently maintains the two-layer memory allocation structure.

[0150] The first memory controller can be used to parse request context information and map memory allocation requests to pre-defined resource control categories. In embodiments of this application, resource control categories can be divided into management units of different dimensions based on factors such as memory control groups, kernel memory usage, and call stacks. For example, it may include memcg categories corresponding to multiple user spaces or containers, such as... Figure 3 The memcg[0...N] in the table can also include dentry categories for classifying immovable objects (such as...). Figure 3 vmemcg[dentry]) or pgtable categories (such as Figure 3 (vmemcg[pgtable]). After parsing the request context information, the first memory controller can match it with the above resource control categories to determine the target resource control category to which the allocation should be assigned.

[0151] After determining the target resource control category, the first memory controller can search whether a dedicated memory block for that category already exists in the system. In embodiments of this application, the first memory controller can employ a two-tier memory allocation structure to organize physical memory, where the upper tier corresponds to multiple independent memory blocks, for example... Figure 3 The first memory controller uses buddy[0..N], buddy[dentry], and buddy[pgtable] in its core, while the lower layers uniformly request contiguous physical regions from physical memory in large-page granularity (e.g., 2MB) through Linux's native Buddy Allocator. When a memory block corresponding to a certain category already exists and has enough allocable space to satisfy the current request, the first memory controller directly performs the allocation operation within that memory block, allocating physical memory to the request and ensuring that the allocation behavior of that resource control category is always clustered within its corresponding physical range.

[0152] If the target resource control category has not yet established a corresponding memory block, or the established memory block can no longer meet the current request's needs, the first memory controller sends an expansion request to the Buddy Allocator. The first memory controller can call the Linux Buddy Allocator to request a contiguous physical region of the corresponding size from physical memory to be used as a new memory block. In this embodiment, for example, buddy[0..N] can be a memory block corresponding to multiple user-space or container-memcg categories - memcg[0...N], buddy[dentry] can be a memory block corresponding to the dentry category of non-movable objects, and buddy[pgtable] can be a memory block corresponding to the pgtable category (such as...). Figure 3 The memory blocks corresponding to vmemcg[pgtable] in the table are classified and aggregated in this way. The physical memory requested by each category is isolated, and memory objects from different sources are not mixed up. This avoids the destruction of contiguous physical page space caused by the cross-release of objects with different lifecycles, and avoids the generation of memory fragmentation.

[0153] In the embodiments of this application, by aggregating based on both resource ownership and usage ownership dimensions, memory objects with different resource ownership and usage ownership are physically isolated during the allocation phase, effectively suppressing memory fragmentation problems caused by cross-allocation and release.

[0154] Furthermore, the embodiments of this application are also compatible with the kernel's native memory allocation and reclamation mechanisms: the second memory controller performs lightweight intrusion based on hooks set in functions such as memory allocation functions, and writes request context information into memory pool variables when memory allocation is needed and clears the request context information recorded in kernel variables after memory allocation is completed. The first memory controller achieves runtime hot-plugging by registering and unloading from the second memory controller as needed. In addition, the smooth upgrade of memory aggregation strategies is achieved through the configuration and updating of memory allocation rules.

[0155] Figure 4 This is a block diagram of a first memory controller provided in one embodiment of this application. Figure 4 As shown, the first memory controller may include:

[0156] The first acquisition module 401 is used to acquire the request context information of the memory allocation request;

[0157] The first category determination module 402 is used to determine the target resource control category that matches the memory allocation request from multiple resource control categories based on the request context information;

[0158] The first search module 403 is used to search for whether there is a memory block corresponding to the target resource control category;

[0159] The first memory allocation module 404 is used to allocate memory based on the memory block when there is a memory block corresponding to the target resource control category;

[0160] The second memory allocation module 405 is used to request a corresponding memory block for the target resource control category from physical memory when there is no memory block corresponding to the target resource control category, and to perform memory allocation based on the memory block.

[0161] In some embodiments, the first search module 403 is specifically used to: search for whether there exists a memory block corresponding to the target resource control category and whose remaining memory space is greater than the requested memory size.

[0162] In some embodiments, the first memory controller may run in kernel space, and the kernel space may also run a second memory controller; the first acquisition module 401 is specifically used to: acquire request context information corresponding to the memory allocation request according to the first call request of the second memory controller; the first call request is generated by the second memory controller intercepting the call operation of the memory allocation function; the call operation of the memory allocation function is executed in response to the memory allocation request.

[0163] In some embodiments, the first category determination module 402 is specifically used to: determine the corresponding target resource control category based on the memory control group identifier, kernel memory type, or call stack information in the request context information.

[0164] In some embodiments, the first category determination module 402 is specifically used to: determine whether a memory control group identifier exists in the request context information;

[0165] If so, determine the resource control category corresponding to the memory control group identifier as the target resource control category;

[0166] If not, based on the kernel memory type or call stack information in the request context information, search for the target memory allocation rule that matches the kernel memory type or call stack information from at least one memory allocation rule, and determine the resource control category in the target memory allocation rule as the target resource control category.

[0167] In some embodiments, the first memory controller may further include:

[0168] The rule determination module is used to determine and save any configured memory allocation rule in response to rule configuration instructions; the rule configuration instructions are generated based on configuration operations for the target kernel interface.

[0169] The rule update module is used to update any specified memory allocation rule in response to a rule update command.

[0170] In some embodiments, the first memory controller may further include:

[0171] The second category determination module is used to determine that a memory allocation request is a special category when there is no target rule in at least one memory allocation rule that matches the kernel memory type or call stack information;

[0172] The first lookup module 403 is specifically used to: find memory blocks corresponding to special categories.

[0173] In some embodiments, the first acquisition module 401 is specifically used to: obtain the request context information corresponding to the memory allocation request from the kernel variables according to the first call request of the second memory controller; the request context information is obtained from the running data and saved to the kernel variables when the second memory controller intercepts the call operation to the memory allocation function.

[0174] In some embodiments, after memory allocation is performed based on memory blocks, the first memory controller may further include:

[0175] The cleanup module is used to clear request context information from kernel variables.

[0176] In some embodiments, the second memory allocation module 405 is specifically used to: request a memory block of an integer multiple of the first size from the physical memory managed by the partner allocator for the target resource control category, based on the memory size in the request context information.

[0177] In some embodiments, the second memory controller is used to set hooks for memory allocation functions to intercept calls to the memory allocation functions.

[0178] In some embodiments, the first memory controller may further include:

[0179] The registration module is used to request the registration of the first memory controller in response to the load instruction; the second memory controller is used to intercept the call operation of the memory allocation function using the hook and initiate the first call request based on the registration information in the hook; the load instruction is generated after the first memory controller is installed in the kernel space.

[0180] In some embodiments, the first memory controller may further include:

[0181] The unregistration module is used to request the unregistration of the first memory controller in response to an unload command; the unload command is generated in response to an unload operation on the first memory controller.

[0182] In some embodiments, the first memory controller may further include:

[0183] The third acquisition module is used to acquire the processing context information of memory processing requests;

[0184] The second category determination module is used to determine the target resource control category corresponding to the memory processing request from a number of pre-set resource control categories based on the processing context information.

[0185] The second lookup module is used to locate the memory block corresponding to the target resource control category and perform memory processing on the memory block based on the processing information.

[0186] In some embodiments, the second acquisition module is specifically used to: determine processing context information based on the second call request of the second memory controller; the second call request is generated by the second memory controller intercepting the call operation of the memory processing function; the call operation of the memory processing function is executed in response to the memory processing request.

[0187] Figure 4 The first memory controller can execute Figure 1 The implementation principle and technical effects of the memory control method described in the illustrated embodiment will not be repeated here. The specific methods by which each module and unit of the first memory controller in the above embodiments perform operations have been described in detail in the embodiments related to this method, and will not be elaborated upon here.

[0188] Figure 5 This is a block diagram of a second memory controller provided for another embodiment of this application, which is deployed in kernel space. Figure 5 As shown, the second memory controller may include:

[0189] The second acquisition module 501 is used to acquire the request context information of the memory allocation request;

[0190] The first calling module 502 is used to call the first memory controller based on the request context information, so that the first memory controller can determine the target resource control category that matches the memory allocation request from a plurality of pre-set resource control categories according to the request context information, and perform memory allocation based on the memory block if there is a memory block corresponding to the target resource control category; otherwise, it requests a corresponding memory block for the target resource control category from physical memory and performs memory allocation based on the memory block.

[0191] In some embodiments, the second acquisition module 501 is specifically used to: intercept the call operation to the memory allocation function, acquire the request context information corresponding to the memory allocation request, and save it to the kernel variable; the first memory controller is used to acquire the request context information from the kernel variable.

[0192] In some embodiments, the second memory controller further includes:

[0193] The fourth acquisition module is used to acquire the processing context information of memory processing requests;

[0194] The second calling module is used to call the first memory controller based on the processing context information, so that the first memory controller can determine the target resource control category corresponding to the memory processing request from a number of pre-set resource control categories according to the processing context information; find the memory block corresponding to the target resource control category; and perform memory processing on the memory block according to the processing information.

[0195] In some embodiments, the second acquisition module 501 is specifically used to: set a hook for the memory allocation function to intercept the call operation of the memory allocation function.

[0196] Figure 5 The second memory controller can perform Figure 2 The implementation principle and technical effects of the memory control method described in the illustrated embodiment will not be repeated here. The specific methods by which each module and unit of the second memory controller in the above embodiments perform operations have been described in detail in the embodiments related to this method, and will not be elaborated upon here.

[0197] It should be noted that some processes described in the above embodiments and accompanying drawings include multiple operations appearing in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear in this document, or they may be executed in parallel. The operation numbers, such as 101, 102, etc., are merely used to distinguish different operations and do not represent any execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should also be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0198] Figure 6 This is a schematic diagram of the structure of one embodiment of a computing device provided in this application. Figure 6 As shown, in practice, the computing device may include a storage component 601 and a processing component 602.

[0199] Storage component 601 is used to store computer programs and can be configured to store various other data to support operation on a computing device. Examples of this data include instructions for any application or method used to operate on the computing device, data structures, contact data, phone book data, messages, pictures, videos, etc.

[0200] Processing component 602, coupled to storage component 601, is used to execute computer programs in storage component 601 for implementing, etc. Figure 1 and or Figure 2 The memory control method shown.

[0201] Furthermore, such as Figure 6 As shown, the computing device may also include other components such as a communication component 603, a display component 604, a power supply component 605, and an audio component 606. Figure 6 The diagram only shows some components and does not mean that the device includes only these components. Figure 6 The components shown. Additionally... Figure 6 The components within the dashed box are optional, not mandatory, and their specific requirements depend on the product form of the computing device. The computing device in this embodiment can be a terminal device such as a desktop computer, laptop computer, smartphone, or IoT (Internet of Things) device, or a server-side device such as a conventional server, cloud server, or server array. If the computing device in this embodiment is implemented as a terminal device such as a desktop computer, laptop computer, or smartphone, it may include... Figure 6 The components within the dashed box; if the computing device in this embodiment is implemented as a conventional server, cloud server, or server array, etc., it may be omitted. Figure 6 The component within the dashed box.

[0202] The processing component described above includes one or more processors to execute computer instructions to complete all or part of the steps in the method described above. Alternatively, the processing component may be implemented as one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the method described above.

[0203] The aforementioned storage components 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 storage, flash memory, magnetic disk, or optical disk.

[0204] The aforementioned communication component is configured to facilitate wired or wireless communication between the device housing the communication component and other devices. The device housing the communication component can access wireless networks based on communication standards, such as mobile communication networks, or combinations 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.

[0205] The aforementioned display components may include a screen, which 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, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0206] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0207] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0208] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above-described method embodiments. The computer-readable storage medium includes volatile or non-volatile components, or a combination thereof, and can be removable or non-removable. Examples of computer-readable 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), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium.

[0209] Accordingly, this application also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, cause the processor to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by the computer program or instructions. Furthermore, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, enabling the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to function as an apparatus for implementing the corresponding functions in the above method embodiments.

[0210] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0211] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0212] Finally, it should be noted that the above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A memory control method, characterized in that, Applied to a first memory controller, the method includes: Obtain the request context information of the memory allocation request; Based on the request context information, determine the target resource control category that matches the memory allocation request from multiple resource control categories; Check if a memory block corresponding to the target resource control category exists; If so, memory allocation is performed based on the aforementioned memory block; If not, request a corresponding memory block for the target resource control category from physical memory, and allocate memory based on the memory block; The request context information includes a memory control group identifier, kernel memory type, or call stack information. The step of determining the target resource control category matching the memory allocation request from multiple resource control categories based on the request context information includes: Based on the memory control group identifier in the request context information, the resource control category corresponding to the memory control group identifier is determined as the target resource control category; or, Based on the kernel memory type or call stack information in the request context information, search for the target memory allocation rule that matches the kernel memory type or the call stack information from at least one memory allocation rule, and determine the resource control category in the target memory allocation rule as the target resource control category.

2. The method according to claim 1, characterized in that, The process of checking whether a memory block corresponding to the target resource control category exists includes: Check if there exists a memory block corresponding to the target resource control category and with remaining memory space greater than the requested memory size.

3. The method according to claim 1 or 2, characterized in that, The first memory controller runs in kernel space, and the kernel space also runs a second memory controller; The request context information corresponding to the memory allocation request includes: Based on the first call request of the second memory controller, obtain the request context information corresponding to the memory allocation request; The first call request is generated by the second memory controller intercepting the call operation of the memory allocation function; the call operation is executed in response to the memory allocation request.

4. The method according to claim 1, characterized in that, The step of determining the resource control category corresponding to the memory control group identifier as the target resource control category based on the memory control group identifier in the request context information; or, based on the kernel memory type or call stack information in the request context information, searching for the target memory allocation rule that matches the kernel memory type or the call stack information from at least one memory allocation rule, and determining the resource control category in the target memory allocation rule as the target resource control category includes: Determine whether the memory control group identifier exists in the request context information; If so, determine the resource control category corresponding to the memory control group identifier as the target resource control category; If not, based on the kernel memory type or call stack information in the request context information, search for the target memory allocation rule that matches the kernel memory type or call stack information from at least one memory allocation rule, and determine the resource control category in the target memory allocation rule as the target resource control category.

5. The method according to claim 1, characterized in that, The method further includes: In response to a rule configuration instruction, determine and save any configured memory allocation rule; the rule configuration instruction is generated based on configuration operations for the target kernel interface. In response to a rule update command, update any of the specified memory allocation rules.

6. The method according to claim 1, characterized in that, The method further includes: If the kernel memory type or call stack information does not match any target memory allocation rule. The predetermined resource control category specified in the predetermined allocation rule is determined as the target resource control category.

7. The method according to claim 3, characterized in that, The step of obtaining the request context information corresponding to the memory allocation request based on the first call request of the second memory controller includes: According to the first call request of the second memory controller, the request context information corresponding to the memory allocation request is obtained from the kernel variable; the request context information is obtained from the runtime data and saved to the kernel variable when the second memory controller intercepts the call operation to the memory allocation function. After allocating memory based on the memory block, the method further includes: Clear the request context information from the kernel variables.

8. The method according to claim 1 or 2, characterized in that, The step of requesting a corresponding memory block from physical memory for the target resource control category includes: Based on the memory size in the request context information, request a memory block of an integer multiple of the first size from the physical memory managed by the partner allocator for the target resource control category.

9. The method according to claim 3, characterized in that, The second memory controller is used to set hooks for memory allocation functions to intercept the call operations of the memory allocation functions. The method further includes: In response to a load instruction, the first memory controller is requested to be registered in the hook; the second memory controller is used to intercept the call operation of the memory allocation function using the hook, and initiate the first call request based on the registration information in the hook; the load instruction is generated after the first memory controller is installed in the kernel space.

10. The method according to claim 9, characterized in that, The method further includes: In response to an uninstallation command, a request is made in the hook to unregister the first memory controller; the uninstallation command is generated in response to an uninstallation operation on the first memory controller.

11. The method according to claim 1 or 2, characterized in that, The method further includes: Obtain the processing context information for the memory processing request; Based on the processing context information, the target resource control category corresponding to the memory processing request is determined from a plurality of pre-set resource control categories; Locate the memory block corresponding to the target resource control category, and perform memory processing on the memory block according to the processing context information.

12. The method according to claim 9, characterized in that, The processing context information for obtaining the memory processing request includes: Based on the second call request from the second memory controller, processing context information is determined; the second call request is generated by the second memory controller intercepting the call operation of the memory processing function; the call operation of the memory processing function is executed in response to the memory processing request.

13. A memory control method, characterized in that, Applied to a second memory controller, which is deployed in kernel space, the method includes: Obtain the request context information of the memory allocation request; Based on the request context information, the first memory controller is invoked, so that the first memory controller can determine the target resource control category matching the memory allocation request from a plurality of pre-set resource control categories according to the request context information, and if there is a memory block corresponding to the target resource control category, memory allocation is performed based on the memory block; otherwise, a corresponding memory block is requested from physical memory for the target resource control category, and memory allocation is performed based on the memory block. The request context information includes a memory control group identifier, kernel memory type, or call stack information. The step of determining the target resource control category matching the memory allocation request from a set of pre-defined resource control categories based on the request context information includes: Based on the memory control group identifier in the request context information, the resource control category corresponding to the memory control group identifier is determined as the target resource control category; or, Based on the kernel memory type or call stack information in the request context information, search for the target memory allocation rule that matches the kernel memory type or the call stack information from at least one memory allocation rule, and determine the resource control category in the target memory allocation rule as the target resource control category.

14. The method according to claim 13, characterized in that, Also includes: Set hooks for memory allocation functions; The request context information corresponding to the memory allocation request includes: The hook is used to intercept calls to the memory allocation function; Check if the first memory controller is registered; If so, obtain the request context information corresponding to the memory allocation request; If not, the memory allocation function is invoked to process the memory allocation request.

15. A computing device, characterized in that, This includes processing components and storage components; The storage component stores a computer program; the computer program is invoked and executed by the processing component to run a first memory controller and a second memory controller in kernel space, the first memory controller being used to implement the memory control method as described in any one of claims 1 to 12, and the second memory controller being used to implement the memory control method as described in any one of claims 13 to 14.

16. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processing component, implements the memory control method as described in any one of claims 1 to 12, or implements the memory control method as described in any one of claims 13 to 14.

17. A computer program product, characterized in that, It includes a computer program or instructions that, when executed by a processing component, implement the memory control method as described in any one of claims 1 to 12, or implement the memory control method as described in any one of claims 13 to 14.

Images