A hierarchical memory pool management method under a multi-core NUMA architecture

Abstract

This application discloses a hierarchical memory pool management method under a multi-core NUMA architecture, relating to the field of computer memory management technology. The method includes: creating a three-level memory pool architecture consisting of a Per-Core private pool module, a node shared pool module, and a global memory pool module, and generating metadata for memory blocks. When releasing a small block of memory, the metadata is read. If the current core and the core identifier in the metadata are inconsistent, direct writing to the Per-Core private pool module corresponding to the core identifier is prohibited, and the memory block to be released is transferred to the corresponding node shared pool module according to the node identifier. The node shared pool module assigns it to the small free resource block of the node shared pool module corresponding to the node identifier, and when a request for replenishing a small resource block of the same size is received, it prioritizes allocation from the small free resource block. This application improves the concurrency performance, access locality, and resource reuse efficiency of memory pool management under a multi-core NUMA architecture.

Description

Technical Field

[0001] This application relates to the field of computer memory management technology, and in particular to a hierarchical memory pool management method under a multi-core NUMA architecture. Background Technology

[0002] With the widespread adoption of multi-core processors and Non-Uniform Memory Access (NUMA) architectures, memory pooling technology is typically used to reduce the overhead of frequently requesting and releasing memory from the operating system, and to reduce contention for shared memory structures under multi-threaded concurrency. Related systems often employ a two-tiered modular architecture of "per-core or per-thread local cache pool + global shared pool," ensuring that most memory allocation and deallocation operations are performed locally, thereby reducing the frequency of system calls.

[0003] Currently, the main trends in related technological development include the following directions: Localized allocation: Reduce shared lock contention through modules such as core local pool and thread local cache.

[0004] Centralized backup: The global pool module uniformly requests and returns memory to the system, reducing the overhead of system memory management.

[0005] Batch migration: Migrate resources in batches between the local pool module and the global pool module to reduce the cost of a single operation.

[0006] Threshold control: The number of available resources in the local pool module and the global pool module is controlled by upper and lower thresholds to maintain resource balance.

[0007] However, under the NUMA architecture, relying solely on the two-level structure of "core local pool module + global pool module" still has the following shortcomings: 1) In cross-core release scenarios, it is difficult to aggregate and reuse small blocks of resources within the owning node first. The resource path is likely to degenerate directly to the global layer for processing, resulting in high latency for remote access across NUMA nodes and the inability to effectively reuse resources within the node.

[0008] 2) In small-scale scenarios where one core requests and another core releases, there is a lack of unified release transfer rules and a lack of unified routing basis for release. This can easily lead to problems where non-core components directly affect the management boundaries of the private pool module, causing concurrent competition and pseudo-sharing.

[0009] Therefore, it is necessary to propose a memory pool management method suitable for multi-core NUMA architectures to solve the above problems. Summary of the Invention

[0010] The purpose of this application is to provide a hierarchical memory pool management method under a multi-core NUMA architecture, which solves the problems of concurrency contention and false sharing caused by direct writing of cross-core releases to the private pool, high latency of remote access across NUMA nodes, and inability to aggregate and reuse memory resources within a node, thereby improving the concurrency performance, access locality, and resource reuse efficiency of memory pool management under a multi-core NUMA architecture.

[0011] To achieve the above objectives, this application provides the following solution: This application provides a hierarchical memory pool management method under a multi-core NUMA architecture, the method comprising: A Per-Core private pool module is created for each CPU core, a node shared pool module is created for each NUMA node, and a global memory pool module is created for the entire system. The global memory pool module, the node shared pool module, and the Per-Core private pool module form a three-level memory pool architecture with upstream and downstream linkage. The upstream of the Per-Core private pool module is the node shared pool module of its NUMA node, and the upstream of the node shared pool module is the global memory pool module. Metadata is generated for each allocated memory block; the metadata includes at least the core identifier and node identifier of the corresponding memory block. When a small memory block release request is received, the metadata of the memory block to be released is read, and it is determined whether the ownership core identifier in the metadata of the memory block to be released is consistent with that of the current release execution core. The small block is a memory block whose size is greater than or equal to the first preset threshold and less than or equal to the second preset threshold. The first preset threshold is less than the second preset threshold. If they are inconsistent, the memory block to be released is prohibited from being directly written to the Per-Core private pool module corresponding to the core identifier. Instead, the memory block to be released is transferred to the node shared pool module corresponding to the corresponding core identifier based on the node identifier in the metadata of the memory block to be released. After receiving the memory block to be released from the relay, the node sharing pool module will include the memory block to be released into the small free resource of the node sharing pool module corresponding to the home node identifier, as a shared resource within the home node. When any Per-Core private pool module within the home node initiates a request to supplement small blocks of resources of the same size, the node's shared pool module will preferentially allocate memory blocks from the free resources of those small blocks.

[0012] In one embodiment, the method further includes: Memory blocks with a size greater than the second preset threshold and less than the third preset threshold are classified as medium blocks, and memory blocks with a size greater than or equal to the third preset threshold are classified as large blocks; the second preset threshold is less than the third preset threshold. Small memory allocation requests are preferentially handled by the Per-Core private pool module, medium memory allocation requests are preferentially handled by the node shared pool module, and large memory allocation requests are preferentially handled by the global memory pool module.

[0013] In one embodiment, when scheduling resources, a hierarchical scheduling rule based on the same size level is followed, specifically including: The Per-Core private pool module only initiates resource replenishment requests of the same size level to the node shared pool module of its NUMA node, and only returns idle resources of the same size level to the node shared pool module. The node shared pool module only initiates resource replenishment requests of the same size level to the global memory pool module, and only returns idle resources of the same size level to the global memory pool module. The memory blocks to be released transferred in the node shared pool module are only included in the idle resources of the same size level as themselves for scheduling.

[0014] In one embodiment, the method further includes: Set a first low watermark threshold and a first high watermark threshold for the free list of each size level in each Per-Core private pool module; When the amount of free resources in the free list of the Per-Core private pool module is lower than the first low watermark threshold, a request is made to the shared pool module of the node to which it belongs for replenishment. When the amount of free resources in the free list of the Per-Core private pool module is higher than the first high water level threshold, the free resources are returned to the shared pool module of the node to which they belong. Set a second low watermark threshold and a second high watermark threshold for the free list of each size level in the shared pool module for each node; When the amount of free resources in the free linked list in the node shared pool module is lower than the second low watermark threshold, a request is made to the global memory pool module to replenish them. When the amount of free resources in the free list of the node shared pool module is higher than the second highest water level threshold, the free resources are returned to the global memory pool module. A third low watermark threshold and a third high watermark threshold are set for each node partition at each size level in the global memory pool module; the node partitions are divided according to NUMA nodes; When the amount of free resources in the node partition of the corresponding size level in the global memory pool module is lower than the third low watermark threshold, it requests memory from the underlying system in batches. When the amount of free resources in the node partition of the corresponding size level in the global memory pool module is higher than the third highest watermark threshold, the resources are returned to the underlying system memory in batches.

[0015] In one embodiment, the metadata also includes memory block size categories; When a memory block is released, it is reclassified into the free resource of the corresponding size level according to the size category of the memory block in the metadata.

[0016] In one embodiment, the method further includes: When the small free resources of the Per-Core private pool module are insufficient, a request for supplementary small resources of the same size is sent to the node shared pool module of the NUMA node to which it belongs. When the node shared pool module is short of idle medium blocks, it sends a request to the global memory pool module to replenish medium blocks of the same size. When the global memory pool module is insufficient to provide large blocks of free resources, it requests large blocks of resources of the same size from the underlying system memory in batches.

[0017] In one embodiment, the method further includes: Set local execution context access constraints for each Per-Core private pool module; the local execution context access constraints include: only the CPU core to which the module belongs is allowed to perform read and write operations on the Per-Core private pool module in the local execution context, and non-cores are prohibited from directly accessing or modifying the idle resource structure of the Per-Core private pool module.

[0018] In one embodiment, the method further includes: When the global memory pool module receives a memory allocation request, it prioritizes allocating memory from the resource partition of the node to which the CPU core that initiated the allocation request belongs; When the resource partition of the node to which the CPU core that initiated the allocation request belongs has insufficient idle resources, cross-node fallback scheduling is performed from the resource partitions of other nodes.

[0019] In one embodiment, the method further includes: When a medium block memory allocation request is received, it is first processed by the node shared pool module of the NUMA node to which the CPU core that initiated the medium block memory allocation request belongs; When a memory release request is received, the metadata of the memory block to be released is read, and the memory block to be released is released to the node shared pool module corresponding to the corresponding node identifier according to the ownership node identifier in the metadata of the memory block to be released.

[0020] In one embodiment, the method further includes: When a large memory allocation request is received, it is handled first by the global memory pool module; When a large memory block release request is received, the metadata of the large memory block to be released is read, and the large memory block to be released is released to the resource partition corresponding to the ownership node identifier in the global memory pool module according to the ownership node identifier in the metadata of the large memory block to be released.

[0021] According to the specific embodiments provided in this application, this application has the following technical effects: This application discloses a hierarchical memory pool management method under a multi-core NUMA architecture. It constructs a three-tiered linked architecture of "Per-Core private pool—node shared pool—global memory pool," recording the owning core and node for each memory block. When releasing a small memory block, the metadata is first read to determine if the current release execution core and the owning core are consistent. If they are inconsistent, direct writing to the owning core's private pool is prohibited. Instead, the memory block is forcibly sent to the node shared pool corresponding to the owning node for relocation, thus completely avoiding direct write operations from non-owning cores to the private pool and eliminating cross-core concurrency contention and false sharing issues. The relocated memory block is included in the current node's small free resource as a shared resource within the owning node. When any Per-Core private pool within the node initiates a request to replenish a small block of the same size, it is preferentially allocated from these shared resources within the nodes. This allows the released small blocks to be aggregated and reused within the owning node without needing to access the global pool across NUMA nodes, significantly reducing cross-node remote access latency and achieving effective aggregation and reuse of memory resources within the node. Attached Figure Description

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

[0023] Figure 1 This is a schematic diagram of a hierarchical memory pool management method under a multi-core NUMA architecture provided in an embodiment of this application; Figure 2 This is a schematic diagram of the overall architecture of a three-level memory pool module with a multi-core NUMA architecture provided in an embodiment of this application; Figure 3 A schematic diagram of a hierarchical scheduling rule of the same size level provided in an embodiment of this application; Figure 4 A schematic diagram of the core process for cross-core block transfer and release based on metadata provided in an embodiment of this application; Figure 5 This is a schematic diagram of the overall process provided for an embodiment of this application; Figure 6This is a detailed flowchart illustrating the small block memory allocation process provided in one embodiment of this application. Detailed Implementation

[0024] Terminology Explanation: NUMA: Non-uniform memory access architecture, where different central processing unit (CPU) cores have different latencies when accessing local node memory and remote node memory.

[0025] Per-Core Private Pool Module: A local memory pool module associated with a single CPU core, used to manage small blocks of memory; associated means that the module logically corresponds to a local allocation path of a core, and does not require threads to be permanently fixed to that core.

[0026] Node Shared Pool Module: A shared memory pool functional module corresponding to a single NUMA physical node, serving all CPU cores within that node. It is used for both medium-sized memory management and as a node-level relay, cache, and scheduling module for cross-core small-block release.

[0027] Global Memory Pool Module: A top-level memory pool module for the entire system, used to manage large blocks of memory and to handle cross-node backup and interaction with the underlying system memory.

[0028] Core of Origin: The CPU core to which the Per-Core private pool module belongs when the memory block is initially allocated.

[0029] Owner node: The NUMA node corresponding to the initial allocation of the memory block.

[0030] Home node pool module: A node shared pool module determined by the home node identifier recorded in the memory block metadata.

[0031] Fixed-size hierarchical: The memory is divided into small, medium and large blocks according to a preset size range, and memory allocation requests of different sizes are given priority by the fixed-level memory pool module. Resource replenishment, backflow and transfer between levels follow the scheduling rules of the corresponding size level.

[0032] Memory block metadata: Management information recorded in the memory block header or associated control structure, including at least size category, ownership core identifier, ownership node identifier and source pool type, used to determine the return target pool module and subsequent scheduling path when releasing memory, and is the core routing basis for memory release.

[0033] Intermediate release: When the execution context for releasing a small block of memory does not belong to its own core, it is not directly written to the Per-Core private pool module corresponding to the own core, but is first written to the own node pool module and participates in subsequent supplementation or backflow scheduling.

[0034] Same-size-level scheduling: Free memory blocks of the same size level are only supplemented, returned, and requested upstream on the corresponding size-level link, and are not mixed with other size-level scheduling resource flow rules.

[0035] Low water level / high water level: The threshold for the amount of available resources corresponding to the size level; when the amount of available resources is lower than the low water level, a resource request to the upstream pool module is triggered to replenish the resources; when the amount of available resources is higher than the high water level, a resource return to the upstream pool module is triggered.

[0036] 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.

[0037] This application provides a hierarchical memory pool management method under a multi-core NUMA architecture. The core is to build a three-level interconnected memory pool module system, and to achieve fine-grained management of resources through fixed-size hierarchical rules, metadata routing rules, and same-size level scheduling rules.

[0038] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0039] In one exemplary embodiment, such as Figure 1 As shown, a hierarchical memory pool management method under a multi-core NUMA architecture is provided. This method is executed by a computer device, specifically by a terminal or server alone, or by both a terminal and a server. In this embodiment, the method is described using a server as an example, and includes the following steps: Step S1: Create a Per-Core private pool module for each CPU core, a node shared pool module for each NUMA node, and a global memory pool module for the entire system; among which, such as Figure 2 As shown, the global memory pool module, the node shared pool module, and the Per-Core private pool module form a three-level memory pool architecture with upstream and downstream linkage; the upstream of the Per-Core private pool module is the node shared pool module of the NUMA node to which it belongs, and the upstream of the node shared pool module is the global memory pool module.

[0040] The modules are interconnected, with each module requesting resources from the upstream module when it is insufficient, and returning resources to the upstream module when it has excess resources. All interactions follow the same size-level scheduling rules.

[0041] Step S2: Generate metadata for each allocated memory block; the metadata includes at least the core identifier and node identifier of the corresponding memory block.

[0042] Step S3: When a small memory block release request is received, read the metadata of the memory block to be released and determine whether the ownership core identifier in the metadata of the current release execution core is consistent with that in the metadata of the memory block to be released; the small block is a memory block whose memory size is greater than or equal to the first preset threshold and less than or equal to the second preset threshold; the first preset threshold is less than the second preset threshold.

[0043] In step S4, if there is a discrepancy, it is prohibited to directly write the memory block to be released to the Per-Core private pool module corresponding to the core identifier. Instead, based on the node identifier in the metadata of the memory block to be released, the memory block to be released is transferred to the node shared pool module corresponding to the node identifier for transfer.

[0044] In step S5, after receiving the memory block to be released, the node shared pool module assigns the memory block to be released to the small free resource of the node shared pool module corresponding to the home node identifier, as a shared resource within the home node.

[0045] Step S6: When any Per-Core private pool module within the home node initiates a request to supplement small blocks of resources of the same size, the node shared pool module shall preferentially allocate memory blocks from the free resources of the small blocks.

[0046] As an optional implementation, the method further includes: Memory blocks with a size greater than the second preset threshold and less than the third preset threshold are classified as medium blocks, and memory blocks with a size greater than or equal to the third preset threshold are classified as large blocks; the second preset threshold is less than the third preset threshold.

[0047] Small memory allocation requests are preferentially handled by the Per-Core private pool module, medium memory allocation requests are preferentially handled by the node shared pool module, and large memory allocation requests are preferentially handled by the global memory pool module.

[0048] As an optional implementation, when scheduling resources, a hierarchical scheduling rule based on the same size level is followed, specifically including: The Per-Core private pool module only initiates resource replenishment requests of the same size level to the node shared pool module of its NUMA node, and only returns idle resources of the same size level to the node shared pool module.

[0049] The node shared pool module only initiates resource replenishment requests of the same size level to the global memory pool module, and only returns idle resources of the same size level to the global memory pool module.

[0050] The memory blocks to be released transferred in the node shared pool module are only included in the idle resources of the same size level as themselves for scheduling.

[0051] As an optional implementation, the method further includes: Set a first low watermark threshold and a first high watermark threshold for the free list of each size level in each Per-Core private pool module.

[0052] When the amount of free resources in the free list of the Per-Core private pool module falls below the first low watermark threshold, a request for replenishment is made to the shared pool module of the node to which it belongs.

[0053] When the amount of free resources in the free list of the Per-Core private pool module is higher than the first high water level threshold, the free resources are returned to the shared pool module of the node to which they belong.

[0054] Set a second low watermark threshold and a second high watermark threshold for the free list of each size level in the shared pool module for each node.

[0055] When the amount of free resources in the free list of the node shared pool module falls below the second low watermark threshold, a request is made to the global memory pool module for replenishment.

[0056] When the amount of free resources in the free list of the node shared pool module is higher than the second highest water level threshold, the free resources are returned to the global memory pool module.

[0057] A third low watermark threshold and a third high watermark threshold are set for each node partition at each size level in the global memory pool module; the node partitions are divided according to NUMA nodes.

[0058] When the amount of free resources in the node partition of the corresponding size level in the global memory pool module is lower than the third low watermark threshold, it requests memory from the underlying system in batches.

[0059] When the amount of free resources in the node partition of the corresponding size level in the global memory pool module is higher than the third highest watermark threshold, the resources are returned to the underlying system memory in batches.

[0060] As an optional implementation, the metadata also includes memory block size categories.

[0061] When a memory block is released, it is reclassified into the free resource of the corresponding size level according to the size category of the memory block in the metadata.

[0062] As an optional implementation, the method further includes: When the small free resources of the Per-Core private pool module are insufficient, a request for supplementary small resources of the same size is sent to the node shared pool module of the NUMA node to which it belongs.

[0063] When the node shared pool module has insufficient idle medium blocks, it sends a request to the global memory pool module to replenish medium blocks of the same size.

[0064] When the global memory pool module is insufficient to provide large blocks of free resources, it requests large blocks of resources of the same size from the underlying system memory in batches.

[0065] As an optional implementation, the method further includes: Set local execution context access constraints for each Per-Core private pool module; the local execution context access constraints include: only the CPU core to which the module belongs is allowed to perform read and write operations on the Per-Core private pool module in the local execution context, and non-cores are prohibited from directly accessing or modifying the idle resource structure of the Per-Core private pool module.

[0066] As an optional implementation, the method further includes: When the global memory pool module receives a memory allocation request, it prioritizes allocating memory from the resource partition of the node to which the CPU core that initiated the allocation request belongs.

[0067] When the resource partition of the node to which the CPU core that initiated the allocation request belongs has insufficient idle resources, cross-node fallback scheduling is performed from the resource partitions of other nodes.

[0068] As an optional implementation, the method further includes: When a medium block memory allocation request is received, it is preferentially handled by the node shared pool module of the NUMA node to which the CPU core that initiated the medium block memory allocation request belongs.

[0069] When a memory release request is received, the metadata of the memory block to be released is read, and the memory block to be released is released to the node shared pool module corresponding to the corresponding node identifier according to the ownership node identifier in the metadata of the memory block to be released.

[0070] As an optional implementation, the method further includes: When a large memory allocation request is received, it is handled first by the global memory pool module.

[0071] When a large memory block release request is received, the metadata of the large memory block to be released is read, and the large memory block to be released is released to the resource partition corresponding to the ownership node identifier in the global memory pool module according to the ownership node identifier in the metadata of the large memory block to be released.

[0072] Furthermore, the principle of this application will be further elaborated below.

[0073] I. Implementation Environment and System Configuration The technical solution of this embodiment can be applied to a typical dual-NUMA node, 64-core x86_64 architecture server, and the specific hardware configuration is as follows: NUMA Node 0: It contains CPU cores 0 to 31, corresponding to 1 node shared pool module (Node 0 shared pool module) and 32 Per-Core private pool modules (cores 0 to 31 private pool modules).

[0074] NUMA Node 1: It contains CPU cores 32 to 63, corresponding to 1 node shared pool module (Node 1 shared pool module) and 32 Per-Core private pool modules (cores 32 to 63 private pool modules).

[0075] Full System: It is configured with 1 global memory pool module. The global memory pool module is divided into 2 resource partitions according to Node 0 and Node 1, namely Node 0 partition and Node 1 partition.

[0076] The correspondence between the hardware and modules in the implementation environment is Figure 2 completely consistent, and the implementation environment is Figure 2 the actual implementation scenario of

[0077] Furthermore, the system is configured as follows: Fixed-size Hierarchical Configuration: Preset memory size hierarchical thresholds. Memory blocks with a size greater than or equal to 8 bytes and less than or equal to 1 KB (1 KB = 1024 bytes) are divided into small blocks; memory blocks with a size greater than 1 KB and less than 64 KB are divided into medium blocks; memory blocks with a size greater than or equal to 64 KB are divided into large blocks, that is, small blocks (8B ≤ size ≤ 1KB), medium blocks (1KB < size < 64KB), large blocks (size ≥ 64KB); Therefore, in this embodiment, the first preset threshold is 8 bytes, the second preset threshold is 1 KB, and the third preset threshold is 64 KB.

[0078] High and Low Water Threshold Configuration: Set the first low water threshold and the first high water threshold for the free list of each size level in each Per-Core private pool module. For example, the first low water threshold for all size levels can be set to 8 (that is, replenishment is triggered when the number of free objects is less than 8), and the first high water threshold can be set to 64.

[0079] Set the second low water threshold and the second high water threshold for the free list of each size level in each node shared pool module. For example, the second low water threshold can be set to 32, and the second high water threshold can be set to 256.

[0080] Set a third low watermark threshold and a third high watermark threshold for each node partition at each size level in the global memory pool module. For example, the third low watermark threshold can be set to 30% of the total partition capacity, and the third high watermark threshold can be set to 70%.

[0081] Metadata configuration: Write metadata to the header of each allocated memory block. The metadata must contain at least the following fields: size category (1 byte, used to identify small, medium or large block), home core identifier (4 bytes), home node identifier (1 byte), and source pool type (1 byte, indicating which level of pool module allocated the block).

[0082] Scheduling rule configuration: The system globally follows a hierarchical scheduling rule within the same size level and a cross-core block transfer and release rule. The hierarchical scheduling rule within the same size level requires that all resource replenishment and repatriation must occur within the same size level (see reference). Figure 3 Cross-size replenishment / reflow is prohibited; cross-core block release must be relayed through the node shared pool module of the owning node (see reference). Figure 4 Direct access to the private pool module belonging to the core is prohibited.

[0083] II. Core Rules The technical solution of this application consists of the following four mutually coupled core rules, and any implementation method must follow these rules simultaneously.

[0084] 1. Construction rules for a three-level memory pool module architecture The execution entity is the system-wide memory pool management module, and the execution process is as follows: System initialization scan: During system initialization, the number of nodes in the current NUMA architecture and the number of CPU cores in each node are scanned.

[0085] Per-Core Private Pool Module Creation: Based on the number of cores, create an independent Per-Core private pool module for each CPU core, and bind the identifier of the core and node to which each Per-Core private pool module belongs.

[0086] Node shared pool module creation: Based on the number of nodes, create an independent node shared pool module for each NUMA node, and bind the node identifier to each node shared pool module, associating all Per-Core private pool modules within that node as downstream modules.

[0087] Global pool module creation: Create a global memory pool module, divide the global pool module into resource partitions according to NUMA nodes, and associate the shared pool module of all nodes as downstream modules.

[0088] Linkage relationship configuration: Complete the upstream and downstream linkage relationship configuration of the three-level modules, and determine the unique path of resource interaction for each module: Per-Core private pool module → shared pool module of the node to which it belongs → global memory pool module. Form as Figure 2 The three-level linkage architecture of "Per-Core private pool module (core level) - node shared pool module (node level) - global memory pool module (system level)" as shown, with each module having independent functions and a unique path.

[0089] By introducing an intermediate layer module (i.e., the node shared pool module), this rule enables small pieces of resources released across cores to be preferentially aggregated and reused within the home node, avoiding direct degradation to the global layer for processing, reducing cross-node access latency, and solving the cross-node access problem of the existing two-level architecture.

[0090] 2. Memory management rule with fixed-size stratification The execution entity is the three-level memory pool module (each module performs its own size management responsibilities), and the fixed-size stratification rule has been marked in Figure 2 and the execution process is as follows: Preset size thresholds: The system presets the following thresholds: small pieces (8B ≤ size ≤ 1KB), medium pieces (1KB < size < 64KB), large pieces (size ≥ 64KB).

[0091] Allocate the corresponding size of the main allocation responsibility to the three-level memory pool module: ① The Per-Core private pool module preferentially processes small-piece allocation requests; ② The node shared pool module preferentially processes medium-piece allocation requests; ③ The global memory pool module preferentially processes large-piece allocation requests; at the same time, the upstream module can undertake the replenishment, return, and system memory interaction of the corresponding size resources of the downstream module.

[0092] Allocation request routing: When a business thread发起 a memory allocation request, the system first analyzes the requested memory size, matches the corresponding main allocation module, and directly routes the request to this module; when the resources of this module are insufficient, only the replenishment of the same-size resources is allowed to be executed according to the preset upstream and downstream relationship, and it is not allowed for business requests to flow disorderly between non-corresponding main allocation modules.

[0093] By preferentially processing memory allocation requests of different sizes by fixed-level modules, the main routing path of memory allocation requests is unique, and the replenishment, return, and transfer of resources between levels follow the preset upstream and downstream relationship, without disorderly mixing management phenomena. Furthermore, it avoids the mixed flow of different-size resources between levels from the root cause, reduces management complexity, takes into account the lock-free and fast allocation of small pieces locally at the core (Per-Core private pool module) and the fragmentation governance of medium and large pieces (idle block merging is performed by the node / global pool module), and solves the problems of high fragmentation rate and low allocation efficiency caused by size mixing management in the existing technology.

[0094] 3. Metadata-based cross-core block transfer and release rules Execution entities: Per-Core private pool module and node shared pool module (cooperative execution). Memory block metadata serves as the core routing basis. The core process is as follows: Figure 4 As shown: Metadata writing: When small blocks of memory are allocated by the Per-Core private pool module of the core to which they belong, the module generates and writes metadata for the memory blocks. The metadata includes at least: size category (small block), core to which it belongs, node to which it belongs, and source pool type (Per-Core private pool module). Metadata reading and parsing: When a business thread initiates a small block release request, the release execution module first reads the metadata of the memory block and parses out the ownership core identifier and ownership node identifier.

[0095] Core Release Judgment: The release execution module determines whether the current release execution core and the ownership core in the metadata are the same core. If so, it executes the local release execution step; otherwise, it executes the cross-core transfer release step. Specifically, the local release execution step involves the current core's Per-Core private pool module directly returning the memory block to the corresponding size of the free list; the cross-core transfer release step prohibits the release execution module from directly writing to the ownership core's Per-Core private pool module. Instead, this module sends the small memory block with metadata to the node shared pool module corresponding to the ownership node identifier in the metadata.

[0096] Intermediate small block reception: After receiving a small memory block released across cores, the shared pool module of the owning node reads the metadata to match the corresponding size level and adds it to the small block free list of this module as a shared small block resource within the node.

[0097] Intra-node resource reuse: When other Per-Core private pool modules within the same node initiate a request to supplement small blocks of the same size, the shared pool module of the same node will prioritize allocating and supplementing the small blocks of resources that are being transferred, thereby achieving intra-node resource reuse.

[0098] This rule redirects small memory blocks released across cores through the shared pool module of the home node, avoiding direct access to the private pool module of the home core. The local access boundary of the per-core private pool module is strictly protected, thereby preventing direct write operations to the private pool module by non-home cores. This avoids cross-core concurrent contention and false sharing issues, realizes core-local lock-free allocation of small memory blocks, and solves the problem of uncontrolled cross-core release paths in existing technologies.

[0099] 4. Hierarchical scheduling rules for the same size level Execution Entity: Three-tier memory pool module (each module executes upstream and downstream resource interactions according to rules), core rules are as follows: Figure 3As shown, the execution process is as follows: Size isolation configuration: The system sets up independent free lists and high and low water level thresholds for each size level of the three-level modules, and resources of different size levels are isolated from each other.

[0100] Same-size replenishment request: When a downstream module initiates a resource replenishment request to an upstream module, it must specify the size level of the request. The upstream module can only allocate resources of the same size level for replenishment and cross-size replenishment is prohibited.

[0101] Same-size resource return: When a downstream module returns resources to an upstream module, it can only return idle resources of the same size level. The upstream module can only add them to the idle list of the corresponding size level, and cross-size return is prohibited.

[0102] Intermediate small block size scheduling: Small memory blocks released across cores, after being transferred through the node shared pool module, can only be included in the free list of the same size level and participate in the resource replenishment of that size level. Cross-size scheduling is prohibited.

[0103] This rule ensures that the replenishment, return, and transfer of resources of all sizes between the three-level modules are all of the same size, and there is no mixed scheduling of resources of different sizes. This improves the controllability and stability of resource scheduling between levels, avoids scheduling chaos caused by the mixed flow of resources of different sizes, strengthens the effect of hierarchical management, and solves the problem of lack of size consistency in scheduling between levels in the existing technology.

[0104] III. Core Business Processes like Figure 5 As shown, the core business processes of this application are memory allocation and memory release and reflow processes. All processes strictly follow the above four core rules. The corresponding processes are described in small, medium and large blocks below.

[0105] 1. Memory allocation process The memory allocation process of this application will be described in detail below, taking into account the above implementation environment and configuration.

[0106] (1) Small block memory allocation process The execution entities are the Per-Core private pool module, the node shared pool module, and the global memory pool module. (See reference...) Figure 6 When a business thread initiates a small memory allocation request (including the requested size and the core identifier of the request), the following steps are executed: Step 100, Allocation Request Route Resolution: The request routing module resolves the allocation request's application size, determines it to be a small block, and routes the request to the Per-Core private pool module corresponding to that core based on the core identifier that initiated the request.

[0107] Step 102, Private Pool Idle Resource Statistics: The Per-Core private pool module receives the request, matches the idle linked list with the requested size, and counts the amount of idle resources in the linked list.

[0108] Step 103, Private Pool Resource Satisfaction Judgment: The Per-Core private pool module determines whether the amount of idle resources satisfies the allocation request. If it does, the private pool small block allocation and metadata writing steps are executed; if it does not, the private pool low water level judgment step is executed.

[0109] Step 104, Private Pool Small Block Allocation and Metadata Writing: The Per-Core private pool module allocates small blocks of memory from the corresponding free list, generates and writes metadata (size category, core identifier, node identifier, source pool type) for the memory blocks, and returns the small memory blocks with metadata to the business thread, thus ending the process.

[0110] Step 105, Low water level judgment of private pool: The Per-Core private pool module determines whether the current amount of idle resources is lower than the low water level threshold of this size level. If it is not lower, it returns allocation failure and the process ends; if it is lower, it executes the step of private pool requesting replenishment from node pool.

[0111] Step 106, Private pool requests replenishment from node pool: Send a small block resource replenishment request (including requested size and the identifier of the owning node) of the same size level to the node shared pool module of the upstream node as input for the next step.

[0112] Step 107, Node Pool Idle Resource Statistics: The node shared pool module of the node receives a replenishment request, matches a small block of idle linked list with the same size as the request, and counts the amount of idle resources in the linked list.

[0113] Step 108, Node pool resource satisfaction judgment: The node shared pool module judges whether the amount of idle resources is sufficient to meet the replenishment request. If it is sufficient, the node pool replenishes the private pool, and then the private pool small block allocation and metadata writing steps are executed. If it is not sufficient, the node pool low water level judgment step is executed.

[0114] Step 109, Node pool replenishes private pool: Allocate small blocks of resources of the same size in batches from the corresponding free list and send them to the Per-Core private pool module.

[0115] Step 1010, Node pool low water level judgment: The node shared pool module judges whether the current amount of idle resources is lower than the low water level threshold of this size level. If it is lower, the node pool will execute the step of requesting replenishment from the global pool; if it is not lower, the replenishment failure will be returned to the Per-Core private pool module and the process will end.

[0116] Step 1011, Node pool requests replenishment from global pool: Send a small block resource replenishment request (including requested size and owner node identifier) ​​of the same size level to the upstream global memory pool module as input for the next step.

[0117] Step 1012, Global Pool Resource Scheduling: The global memory pool module receives a supplement request and first requests a small block of resources of the same size from the resource partition of the node to which the request belongs. If the partition resources are insufficient, cross-node fallback scheduling is performed to schedule resources of the same size from other node partitions.

[0118] Step 1013, Global pool replenishes node pool: The global memory pool module sends small blocks of resources of the same size level in batches to the node shared pool module. The node shared pool module then performs the step of replenishing the private pool from the node pool, followed by the steps of allocating small blocks and writing metadata to the private pool.

[0119] (2) Medium block memory allocation process When the execution entities are the node shared pool module and the global memory pool module, and a business thread initiates a medium-block memory allocation request (including the requested size and the core identifier of the request), the following steps are executed: Step 201, Medium Block Request Route Resolution: The request routing module resolves the allocation request's application size, determines it to be a medium block, and routes the request to the node shared pool module of the node to which the core belongs, based on the core identifier that initiated the request.

[0120] Step 202, Statistics on idle resources of blocks in the node pool: The shared pool module of the node receives the request, matches the idle linked list of blocks with the same size as the requested block, and counts the amount of idle resources in the linked list.

[0121] Step 203, Block resource satisfaction judgment in the node pool: The node shared pool module judges whether the amount of idle resources satisfies the allocation request. If it does, the block allocation and metadata writing steps in the node pool are executed; if it does not, the low water level judgment step in the node pool is executed.

[0122] Step 204, Block allocation and metadata writing in the node pool: The node shared pool module allocates medium block memory from the corresponding free list, generates and writes metadata (size category, owning node identifier, source pool type) for the memory block, and returns the medium block memory with metadata to the business thread, and the process ends.

[0123] Step 205, Low water level judgment of blocks in the node pool: The shared pool module of the node determines whether the current amount of idle resources is lower than the low water level threshold of the size level. If it is not lower, the allocation failure is returned and the process ends; if it is lower, the node pool will execute the step of requesting blocks to replenish the global pool.

[0124] Step 206: The node pool requests a block replenishment from the global pool: It sends a medium block resource replenishment request (including the requested size and the identifier of the owning node) of the same size level to the upstream global memory pool module as input for the next step. Step 207, Global pool block resource scheduling: The global memory pool module receives a supplement request and applies for blocks of the same size in batches from the resource partition of the node to which the request belongs. If the partition resources are insufficient, cross-node fallback scheduling is performed.

[0125] Step 208, Global pool replenishes blocks in node pool: Global memory pool module sends medium block resources of the same size level in batches to node shared pool module, and node shared pool module then performs block allocation and metadata writing steps in node pool.

[0126] (3) Large memory allocation process When the execution entity is the global memory pool module, and a business thread initiates a large memory allocation request (including the requested size and the core identifier of the request), the following steps are executed: Step 301, Large Request Route Resolution: The request routing module resolves the allocation request size, determines it to be a large request, and directly routes the request to the global memory pool module. Step 302, Global Pool Large Idle Resource Statistics: The global memory pool module receives the request, locates the resource partition of the node to which the core belongs based on the core identifier that initiated the request, matches the large idle linked list within the partition that matches the requested size, and counts the amount of idle resources in the linked list.

[0127] Step 303, Global Pool Local Partition Resource Satisfaction Judgment: The global memory pool module determines whether the amount of free resources in the partition satisfies the allocation request. If it does, the global pool block allocation and metadata writing steps are executed; if it does not, the global pool cross-node fallback scheduling steps are executed.

[0128] Step 304, Global Pool Large Block Allocation and Metadata Writing: The global memory pool module allocates a large block of memory from the corresponding free list of the partition, generates and writes metadata (size category, owner node identifier, source pool type) for the memory block, and returns the large block of memory with metadata to the business thread, and the process ends.

[0129] Step 305, Global Pool Cross-Node Backup Scheduling: The global memory pool module schedules large blocks of resources of the same size from the idle resource partitions of other nodes. If there are not enough idle resources in the entire system, the global pool will request large blocks from the system memory.

[0130] Step 306, Global Pool requests large blocks of resources from system memory: Batch requests large blocks of resources of the same size from the underlying system memory, followed by global pool large block allocation and metadata writing steps.

[0131] 2. Memory release and reflow process (1) Small block memory release and reflow process When the execution entity is a Per-Core private pool module, a node shared pool module, or a global memory pool module, and a business thread initiates a small memory release request (including a small memory block to be released, with metadata attached to the memory block), the following steps are executed: Step 401, read the release request metadata: The release execution module receives the release request, reads the metadata of the memory block to be released, and parses out the size category, the core identifier, and the node identifier, which are used as the basis for the next step.

[0132] Step 401, release core consistency judgment: The release execution module judges whether the current release execution core and the ownership core identifier in the metadata are the same core. If yes, the private pool local release step is executed; if no, the cross-core transfer release to node pool step is executed.

[0133] Step 402, Local Release of Private Pool: The current core's Per-Core private pool module receives the small memory blocks to be released and returns them to the free list that matches the metadata size category.

[0134] Step 403, Private Pool High Water Level Judgment: The Per-Core private pool module counts the amount of idle resources in the idle linked list and determines whether it is higher than the high water level threshold for this size level. If it is not higher, the release is completed and the process ends; if it is higher, the private pool is executed to return small blocks to the node pool.

[0135] Step 404, Private pool flows back to node pool: The Per-Core private pool module flows back a batch of idle small blocks of the same size to the node shared pool module of the node to which it belongs. The node shared pool module assigns them to the corresponding size of the idle small block linked list. The release and backflow are completed, and the process ends.

[0136] Step 405, Cross-core transfer release to node pool: The release execution module sends the small memory block to be released with metadata to the node shared pool module corresponding to the node identifier in the metadata (transfer release), and prohibits direct writing to the private pool module of the core.

[0137] Step 406, Small Block Reception Step in Node Pool: The shared pool module of the owning node receives the small memory block, reads the metadata to match the free linked list of small blocks of the same size level, and assigns it to the linked list.

[0138] Step 407, Node Pool Small Block High Water Level Judgment Step: The node shared pool module counts the amount of idle resources in the idle linked list and determines whether it is higher than the high water level threshold of the size level. If it is not higher, the release is completed and the process ends; if it is higher, the node pool is executed to return small blocks to the global pool.

[0139] Step 408, Node pool to global pool small block backflow step: The node shared pool module backflows a batch of idle small block resources of the same size level to the global memory pool module. The global memory pool module assigns them to the corresponding node partition and the corresponding size of the idle linked list. The release + backflow is completed, and the process ends.

[0140] Step 409, Global Pool Small Block System Return Step: If the global memory pool module determines that the amount of idle resources in the node partition and the size level is higher than the high watermark threshold, it returns the idle resources to the underlying system memory in batches to complete the final return.

[0141] (2) Medium / large block memory release and reflow process 2.1) Medium Block Release and Reflow Process When the execution entities are the node shared pool module and the global memory pool module, and a business thread initiates a request to release a middle block of memory (including the middle block of memory to be released, with metadata), the following steps are executed: Step 501, read the metadata of the middle block release: The release execution module reads the metadata of the middle block to be released, parses out the size category and the owner node identifier, and sends it to the node sharing pool module corresponding to the owner node identifier.

[0142] Step 502, release and merge of blocks in the node pool: The node shared pool module receives the middle block memory block, returns it to the middle block free list of the same size level, and performs a merge operation on adjacent free blocks to reduce memory fragmentation.

[0143] Step 503, High water level judgment step in the node pool: The node shared pool module counts the amount of idle resources in the idle linked list and determines whether it is higher than the high water level threshold of the size level. If it is not higher, the release is completed and the process ends; if it is higher, the step of returning blocks from the node pool to the global pool is executed.

[0144] Step 504, Block backflow from node pool to global pool: Batch backflow of idle medium block resources of the same size level to the global memory pool module.

[0145] Step 505, Global Pool Block System Return Step: The global memory pool module will return the medium block resources to the corresponding node partition and the free list of the same size level. If it is determined that the resource amount of the partition is higher than the high watermark threshold, it will return the resources to the system memory in batches, and the process will end.

[0146] 2) Large-scale release and reflux process When a large memory release request (including a large memory block to be released, with metadata) is initiated by a business thread and the execution entity is the global memory pool module, the following steps are executed: Step 601, read metadata of large block release: The release execution module reads the metadata of the large block to be released, parses out the size category and the node identifier to which it belongs, and sends it directly to the global memory pool module.

[0147] Step 602, Global Pool Large Block Release and Merging: The global memory pool module receives large memory blocks, returns them to the corresponding node partition and the large free block list of the same size level, and performs a merging operation on adjacent free blocks to reduce memory fragmentation.

[0148] Step 603, Global Pool Large Block High Water Level Judgment Step: The global memory pool module counts the amount of free resources in this partition and this size level, and determines whether it is higher than the high water level threshold. If it is not higher, the release is completed and the process ends; if it is higher, the global pool large block system return step is executed.

[0149] Step 604, Global Pool Large Block System Return: Return the idle large block resources to the underlying system memory in batches, complete the final return flow, and the process ends.

[0150] Furthermore, the memory allocation and release process of this application will be further explained below through several specific embodiments in conjunction with the aforementioned process steps.

[0151] Example 1: Local small block allocation (64B) in core 10 The business thread on core 10 initiates a 64B memory block allocation request and executes the following steps: Step 701, allocate request route resolution: The request routing module resolves the request into small request chunks and routes them to the core 10 private pool module.

[0152] Step 702, Private Pool Idle Resource Statistics Step: Core 10 private pool module matches 64B idle linked list, and counts the idle resource amount as 5, which is lower than the first low water level threshold of 8.

[0153] Step 703, Private pool requests replenishment from node pool: Core 10 private pool module sends a 64B small block resource replenishment request to node 0 shared pool module.

[0154] Step 704, Node Pool Idle Resource Statistics: Node 0's shared pool module matches a 64B small block of idle linked list, with an idle resource quantity of 40, which satisfies the replenishment request.

[0155] Step 705, Node pool replenishes private pool: Batch allocate 16 64B small block resources to the core 10 private pool module.

[0156] Step 706, Private Pool Small Block Allocation and Metadata Writing: The Core 10 private pool module allocates a 64B small block from the supplementary resources, writes metadata to it (size: small block 64B; owning core: 10; owning node: 0; source pool: Per-Core private pool), and returns the memory block with metadata to the business thread, indicating successful allocation.

[0157] Example 2: Core 33 releases a 64B block allocated to Core 10 across cores. The business thread on core 33 initiates a 64B block release request. The memory block to be released is a small block with metadata allocated on core 10, and the following steps are executed: Step 801, Release request metadata reading: Release execution module reads metadata and parses out the belonging core 10 and the belonging node 0.

[0158] Step 802, release core consistency judgment: determine that the currently executing core 33 is not the same as the core 10, and trigger the transfer release.

[0159] Step 803, Cross-core transfer release to node pool: The release execution module sends the 64B block with metadata to the node 0 shared pool module, and prohibits writing to the core 10 private pool module.

[0160] Step 804, small block reception in the node pool: The shared pool module of node 0 receives the small block and adds it to the 64B small block free list. At this time, the free resource quantity of the list is 41.

[0161] Step 805, Node pool small block high water level judgment: Node 0 shared pool module judges 41 < second high water level threshold 256, no resource return, release completed.

[0162] Step 806, subsequent intra-node resource reuse: If core 5 in node 0 initiates a 64B block supplementation request, the shared pool module of node 0 will prioritize allocating the relayed 64B block to the private pool module of core 5 to achieve intra-node resource reuse.

[0163] Example 3: Mid-block allocation and release in Core 15 (8KB) The business thread on core 15 initiates an 8KB block memory allocation request and executes the following steps: Step 901, Mid-block Request Route Resolution: The request routing module resolves the request as a mid-block request and routes it to the node 0 shared pool module; Step 902, statistics of free resources in the node pool: Node 0 shared pool module matches the free block linked list of 8KB, the amount of free resources is 50, which satisfies the request.

[0164] Step 903, Block allocation and metadata writing in the node pool: Node 0's shared pool module allocates an 8KB medium block, writes metadata (size: medium block 8KB; owner node: 0; source pool: node shared pool), and returns to the business thread, indicating successful allocation.

[0165] Step 904, Release Phase Input: The business thread on core 20 initiates a release request for the 8KB block.

[0166] Step 905, read metadata of the middle block release: The release execution module reads the metadata, parses out the owner node 0, and sends it to the node 0 shared pool module.

[0167] Step 906, Block Release and Merging in Node Pool: The node 0 shared pool module returns the block to the 8KB free block list and merges it with the adjacent free block into a 16KB free block.

[0168] Step 907, block high water level judgment in node pool: The amount of idle resources in the linked list is 51, which is less than the second high water level threshold of 256. There is no resource return, and the release is completed.

[0169] Beneficial effects: 1) Reduce cross-node access latency and improve resource reuse rate: By building the node shared pool intermediate layer module, small blocks of resources released across cores are preferentially aggregated and reused within their owning nodes, avoiding direct degradation to global layer processing, and memory access locality under NUMA architecture is greatly improved.

[0170] 2) Reduce memory fragmentation while balancing allocation efficiency and fragmentation management: By using a fixed-size hierarchical rule, small blocks are allocated quickly and lock-free by the core private pool module, while medium and large blocks are managed by the node / global pool module and free blocks are merged. This solves the problem of high fragmentation rate caused by mixed size management from the root.

[0171] 3) Achieve lock-free or low-contention allocation of small blocks of memory on the core local path to reduce concurrency contention: By using metadata-based transfer and release rules, strictly protect the local access boundary of the Per-Core private pool module, avoid direct write operations to non-core-owned modules, reduce the risk of concurrency contention and false sharing caused by cross-core release, and improve the performance of small block allocation in multi-core scenarios. 4) Improve resource scheduling controllability and reduce management complexity: Through hierarchical scheduling rules of the same size level, resources of each size are isolated and transferred, avoiding cross-size mixed scheduling. The resource replenishment and return path between levels is unique, and the scheduling stability and controllability are greatly improved.

[0172] 5) Adapting to the local priority requirements of NUMA architecture: The global memory pool module divides resources into partitions by node, prioritizes the allocation of resources to local nodes, and only uses cross-node fallback as a supplement, fully adapting to the non-uniform memory access characteristics of NUMA architecture.

[0173] 6) Reduce system call frequency and lower system overhead: The interaction between the global memory pool module and system memory is batch allocation / return, combined with high and low water level threshold control, which greatly reduces frequent system memory calls and lowers system-level memory management overhead.

[0174] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0175] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A hierarchical memory pool management method under a multi-core NUMA architecture, characterized in that, The hierarchical memory pool management method under the multi-core NUMA architecture includes: A Per-Core private pool module is created for each CPU core, a node shared pool module is created for each NUMA node, and a global memory pool module is created for the entire system. The global memory pool module, the node shared pool module, and the Per-Core private pool module form a three-level memory pool architecture with upstream and downstream linkage. The upstream of the Per-Core private pool module is the node shared pool module of its NUMA node, and the upstream of the node shared pool module is the global memory pool module. Metadata is generated for each allocated memory block; the metadata includes at least the core identifier and node identifier of the corresponding memory block. When a small memory block release request is received, the metadata of the memory block to be released is read, and it is determined whether the ownership core identifier in the metadata of the memory block to be released is consistent with that of the current release execution core. The small block is a memory block whose size is greater than or equal to the first preset threshold and less than or equal to the second preset threshold. The first preset threshold is less than the second preset threshold. If they are inconsistent, it is prohibited to write the memory block to be released directly to the Per-Core private pool module corresponding to the core identifier. Instead, the memory block to be released will be transferred to the node shared pool module corresponding to the corresponding core identifier based on the node identifier in the metadata of the memory block to be released. After receiving the memory block to be released from the relay, the node shared pool module will assign the memory block to the small free resource of the node shared pool module corresponding to the owner node identifier, as a shared resource within the owner node. When any Per-Core private pool module within the home node initiates a request to supplement small blocks of resources of the same size, the node's shared pool module will preferentially allocate memory blocks from the free resources of those small blocks.

2. The hierarchical memory pool management method under a multi-core NUMA architecture according to claim 1, characterized in that, The method further includes: Memory blocks with a size greater than the second preset threshold and less than the third preset threshold are classified as medium blocks, and memory blocks with a size greater than or equal to the third preset threshold are classified as large blocks; the second preset threshold is less than the third preset threshold. Small memory allocation requests are preferentially handled by the Per-Core private pool module, medium memory allocation requests are preferentially handled by the node shared pool module, and large memory allocation requests are preferentially handled by the global memory pool module.

3. The hierarchical memory pool management method under a multi-core NUMA architecture according to claim 2, characterized in that, When scheduling resources, a hierarchical scheduling rule based on the same size level is followed, specifically including: The Per-Core private pool module only initiates resource replenishment requests of the same size level to the node shared pool module of its NUMA node, and only returns idle resources of the same size level to the node shared pool module. The node shared pool module only initiates resource replenishment requests of the same size level to the global memory pool module, and only returns idle resources of the same size level to the global memory pool module. The memory blocks to be released transferred in the node shared pool module are only included in the idle resources of the same size level as themselves for scheduling.

4. The hierarchical memory pool management method under a multi-core NUMA architecture according to claim 2, characterized in that, The method further includes: Set a first low watermark threshold and a first high watermark threshold for the free list of each size level in each Per-Core private pool module; When the amount of free resources in the free list of the Per-Core private pool module is lower than the first low watermark threshold, a request is made to the shared pool module of the node to which it belongs for replenishment. When the amount of free resources in the free list of the Per-Core private pool module is higher than the first high water level threshold, the free resources are returned to the shared pool module of the node to which they belong. Set a second low watermark threshold and a second high watermark threshold for the free list of each size level in the shared pool module for each node; When the amount of free resources in the free linked list in the node shared pool module is lower than the second low watermark threshold, a request is made to the global memory pool module to replenish them. When the amount of free resources in the free list of the node shared pool module is higher than the second highest water level threshold, the free resources are returned to the global memory pool module. A third low watermark threshold and a third high watermark threshold are set for each node partition at each size level in the global memory pool module; the node partitions are divided according to NUMA nodes; When the amount of free resources in the node partition of the corresponding size level in the global memory pool module is lower than the third low watermark threshold, it requests memory from the underlying system in batches. When the amount of free resources in the node partition of the corresponding size level in the global memory pool module is higher than the third highest watermark threshold, the resources are returned to the underlying system memory in batches.

5. The hierarchical memory pool management method under a multi-core NUMA architecture according to claim 2, characterized in that, The metadata also includes memory block size categories; When a memory block is released, it is reclassified into the free resource of the corresponding size level according to the size category of the memory block in the metadata.

6. The hierarchical memory pool management method under a multi-core NUMA architecture according to claim 2, characterized in that, The method further includes: When the small free resources of the Per-Core private pool module are insufficient, a request for supplementary small resources of the same size is sent to the node shared pool module of the NUMA node to which it belongs. When the node shared pool module is short of idle medium blocks, it sends a request to the global memory pool module to replenish medium blocks of the same size. When the global memory pool module is insufficient to provide large blocks of free resources, it requests large blocks of resources of the same size from the underlying system memory in batches.

7. The hierarchical memory pool management method under a multi-core NUMA architecture according to claim 1, characterized in that, The method further includes: Set local execution context access constraints for each Per-Core private pool module; the local execution context access constraints include: only the CPU core to which the module belongs is allowed to perform read and write operations on the Per-Core private pool module in the local execution context, and non-cores are prohibited from directly accessing or modifying the idle resource structure of the Per-Core private pool module.

8. The hierarchical memory pool management method under a multi-core NUMA architecture according to claim 4, characterized in that, The method further includes: When the global memory pool module receives a memory allocation request, it prioritizes allocating memory from the resource partition of the node to which the CPU core that initiated the allocation request belongs; When the resource partition of the node to which the CPU core that initiated the allocation request belongs has insufficient idle resources, cross-node fallback scheduling is performed from the resource partitions of other nodes.

9. The hierarchical memory pool management method under a multi-core NUMA architecture according to claim 2, characterized in that, The method further includes: When a medium block memory allocation request is received, it is first processed by the node shared pool module of the NUMA node to which the CPU core that initiated the medium block memory allocation request belongs; When a memory release request is received, the metadata of the memory block to be released is read, and the memory block to be released is released to the node shared pool module corresponding to the corresponding node identifier according to the ownership node identifier in the metadata of the memory block to be released.

10. The hierarchical memory pool management method under a multi-core NUMA architecture according to claim 2, characterized in that, The method further includes: When a large memory allocation request is received, it is handled first by the global memory pool module; When a large memory block release request is received, the metadata of the large memory block to be released is read, and the large memory block to be released is released to the resource partition corresponding to the ownership node identifier in the global memory pool module according to the ownership node identifier in the metadata of the large memory block to be released.

Images