Resource management method and device based on combination of slab allocator and buddy system

Abstract

The application provides a resource management method and device based on combination of Slab allocator and Buddy system, and relates to the technical field of computers. A Buddy system composed of multiple linked lists (recording start positions, interval lengths and use states of index intervals) is first constructed. A Slab cache area is constructed by allocating continuous index intervals from the Buddy system. When a resource request is received, available index units are searched and allocated in the Slab cache area by the Slab allocator. If not, a new continuous index interval is allocated by calling the Buddy system, and a new Slab cache area is constructed based on the interval. After the index units are released, if all the index units in the corresponding Slab cache area are released, the index interval corresponding to the Slab cache area is returned to the Buddy system. The application can effectively reduce fragmentation, improve resource utilization and system response speed while rapidly allocating and recycling MTT resources.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a resource management method and apparatus based on the combination of Slab allocator and Buddy system. Background Technology

[0002] In remote direct memory access (RDMA) technology, the memory translation table (MTT) is a key structure for managing the mapping from virtual addresses to physical addresses, and the efficient management of its index resources is crucial to system performance.

[0003] In existing technologies, MTT index resources are typically managed using a bitmap approach. While this method is simple to implement, it struggles to effectively maintain contiguous free areas during resource allocation, leading to frequent memory gaps and impacting the allocation efficiency of large resources. Furthermore, some improved solutions attempt to reduce fragmentation using multi-level lookup mechanisms, but this introduces additional hardware overhead, reducing cache hit rates and impacting access efficiency, especially under high concurrency and low latency scenarios.

[0004] Therefore, how to effectively reduce fragmentation, improve resource utilization and system response speed while ensuring rapid allocation and recycling of MTT resources has become an urgent technical challenge to be solved. Summary of the Invention

[0005] The purpose of this application is to provide a resource management method and apparatus based on the combination of Slab allocator and Buddy system, so as to alleviate the above-mentioned technical problems existing in the prior art.

[0006] In a first aspect, the present invention provides a resource management method based on the combination of a Slab allocator and a Buddy system, comprising:

[0007] Construct a Buddy system consisting of multiple linked lists. The linked lists are used to record the starting position, length, and usage status of the index interval. The index interval is divided according to powers of 2.

[0008] Slab caches are constructed by allocating contiguous index ranges from the Buddy system. Each Slab cache includes a management header and multiple fixed-size index units.

[0009] Upon receiving a resource request, the Slab allocator searches for and allocates available index units in the Slab cache.

[0010] When there are no available index units in the Slab cache, the Buddy system is invoked to allocate a new contiguous index range, and a new Slab cache is built based on this range.

[0011] After releasing an index unit, if all index units in the corresponding Slab buffer are released, the index range corresponding to that Slab buffer is returned to the Buddy system, and it is determined whether it can be merged with an adjacent index range.

[0012] In an optional implementation, the linked lists of the Buddy system are hierarchically managed according to the size of the index range, with each linked list corresponding to an index range of a power of 2.

[0013] In an optional implementation, the management header records the pointers to the free index necklace table, the usage status of the Slab, and the number of allocated index units.

[0014] In an optional implementation, the method further includes:

[0015] When allocating index units, the Slab allocator directly retrieves an available index unit from the free list and updates the allocated count in the management head.

[0016] In an optional implementation, when returning the index range to the Buddy system, the method further includes:

[0017] Determine if the index interval is adjacent to its neighboring Buddy interval and both are in an empty state. If so, merge them into a larger index interval and update the linked list structure.

[0018] In an optional implementation, the number and size of the Slab cache are dynamically adjusted based on the resource usage during system operation.

[0019] In an optional implementation, the method is applied to the management of MTT resources in an RDMA device, wherein the MTT resources are used to store mapping information from virtual addresses to physical addresses.

[0020] Secondly, the present invention provides a resource management device based on the combination of a Slab allocator and a Buddy system, comprising:

[0021] The first building module is used to build the Buddy system, which consists of multiple linked lists. The linked lists are used to record the starting position, length and usage status of the index interval. The index interval is divided according to powers of 2.

[0022] The second building module is used to allocate contiguous index ranges from the Buddy system to build Slab caches. Each Slab cache includes a management header and multiple fixed-size index units.

[0023] The lookup module is used to search for and allocate available index units in the Slab cache through the Slab allocator when a resource request is received.

[0024] The module calls the Buddy system to allocate a new contiguous index range when there are no available index units in the Slab buffer, and then builds a new Slab buffer based on that range.

[0025] The release module is used to return the index range corresponding to the Slab buffer to the Buddy system after releasing the index unit if all index units in the corresponding Slab buffer have been released, and to determine whether it can be merged with the adjacent index range.

[0026] Thirdly, the present invention provides an electronic device including a processor and a memory, the memory storing computer-executable instructions that can be executed by the processor, and the processor executing the computer-executable instructions to implement the resource management method based on the combination of Slab allocator and Buddy system according to any of the foregoing embodiments.

[0027] Fourthly, the present invention provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are invoked and executed by a processor, the computer-executable instructions cause the processor to implement the resource management method based on the combination of the Slab allocator and the Buddy system according to any of the foregoing embodiments.

[0028] This application provides a resource management method and apparatus based on the combination of a Slab allocator and a Buddy system. By combining the Slab allocator and the Buddy system, an efficient resource management method is achieved: the Buddy system adopts a linked list structure partitioned by powers of 2, which can quickly allocate contiguous index intervals and effectively merge adjacent intervals after release, significantly reducing external fragmentation; the Slab allocator manages fixed-size index units within contiguous intervals, improving allocation and reclamation efficiency and reducing internal fragmentation. Through the collaborative work of the Buddy system and the Slab allocator, both the efficiency of resource allocation and the dynamic adaptability of the system under different loads are ensured. This method effectively improves MTT resource utilization and hardware access efficiency, and is suitable for high-performance computing and low-latency communication scenarios. Attached Figure Description

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

[0030] Figure 1 A flowchart illustrating a resource management method based on the combination of a Slab allocator and a Buddy system, provided as an embodiment of this application;

[0031] Figure 2 A schematic diagram of an index unit provided in an embodiment of this application;

[0032] Figure 3 A structural diagram of a resource management device based on the combination of a Slab allocator and a Buddy system, provided in an embodiment of this application;

[0033] Figure 4 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0035] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0036] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0037] Terminology Explanation:

[0038] 1. Buddy System: The Buddy System is a memory allocation and reclamation strategy primarily used to manage variable-sized memory blocks.

[0039] 2. Slab: The slab mechanism is a memory allocation strategy used to efficiently manage and allocate fixed-size memory blocks. Each slab consists of multiple entries (memory blocks, also known as memory units), and each entry is typically the same size.

[0040] 3. MTT: MTT is a structure used to manage the mapping of virtual addresses to physical addresses. In RDMA (Remote Direct Memory Access) technology, MTT is used to store and manage device memory address mappings to ensure that remote hosts can access specified physical memory regions.

[0041] In RDMA devices, the MTT (Mean Transmission Terminal) manages the mapping from virtual addresses to physical addresses, and software typically uses a bitmap to record the allocation of MTT resources. However, traditional bitmap schemes have the following problems:

[0042] Hole problem: The bitmap can only manage the MTT index, while the hardware can only access the MTT based on the start index and entry count;

[0043] Fragmentation issue: When releasing MTT resources, fragmentation may occur within the bitmap, making it difficult to allocate large blocks of MTT resources.

[0044] To address the fragmentation issue, some technical solutions employ multi-level table lookups to manage MTT entries. While this approach can reduce fragmentation to some extent, it increases the overhead of hardware table lookups. Given the critical nature of MTT as a frequently accessed resource, using multi-level tables can lead to uneven data distribution, resulting in decreased cache hit rates and impacting data access efficiency.

[0045] Based on this, embodiments of this application provide a resource management method based on the combination of the Slab allocator and the Buddy system, see [link to relevant documentation]. Figure 1 As shown, the method mainly includes the following steps:

[0046] Step S110: Construct a Buddy system consisting of multiple linked lists. The linked lists are used to record the starting position, length, and usage status of the index interval. The index interval is divided according to powers of 2.

[0047] During the system initialization phase, the first step is to construct an index resource pool based on the Buddy system. This includes building the resource pool data structure, configuring linked list node information, and performing initialization processes. Specifically:

[0048] Resource pool data structure construction involves first establishing multiple linked list structures, each managing an index range of a specific size. In practical implementation, the MTT index item is abstracted as follows: Figure 2 The resources shown are managed, and each index item has its own subscript. The index range can be divided according to powers of 2, such as the range of 1, 2, 4, 8, 16 consecutive index items. This example is for illustration only and is not a specific limitation.

[0049] Linked list node information refers to each linked list node recording the starting position, length, and usage status of the index range. The usage status includes whether it is free or occupied.

[0050] The initialization process involves dividing the entire index space into multiple intervals of power 2 size based on the total number of available MTT resources in the system, and then inserting these intervals into the corresponding level of linked lists.

[0051] Step S120: Allocate consecutive index ranges from the Buddy system to construct Slab caches. Each Slab cache includes a management header and multiple fixed-size index units.

[0052] Building upon the aforementioned Buddy system, a Slab cache is constructed to manage fixed-size MTT index entries; this involves Slab cache partitioning. Specifically, during Slab cache partitioning, a contiguous index range is allocated from the Buddy system and divided into several sub-ranges as Slab caches. Each Slab cache includes a management header and multiple fixed-size index units.

[0053] In an optional implementation, the management header records pointers to the free index chain, the usage status of the Slab, and the number of allocated index units. Corresponding to the aforementioned Slab cache, the management header records metadata such as the status of the Slab cache, pointers to the free index chain, and the number of allocated indexes.

[0054] Step S130: Upon receiving a resource request, the available index unit is searched and allocated in the Slab cache area by the Slab allocator.

[0055] When a resource request is received, the Slab allocator will first perform priority allocation, that is, the Slab allocator will first search for a free index unit in the corresponding Slab cache area.

[0056] If a free cell exists, an index cell is retrieved from the free list and the management data is updated.

[0057] Step S140: When there are no available index units in the Slab cache, call the Buddy system to allocate a new continuous index range and build a new Slab cache based on the range.

[0058] If the search finds no available index units in the current Slab cache, the Buddy system is invoked to allocate a new contiguous index range. Further, a new Slab cache is constructed based on the newly allocated index range, and the allocation operation is performed.

[0059] In step S150, after releasing the index unit, if all index units in the corresponding Slab buffer are released, the index range corresponding to the Slab buffer is returned to the Buddy system, and it is determined whether it can be merged with the adjacent index range.

[0060] After the index resources are released, the following process is executed:

[0061] Release to Slab buffer: Return the freed index unit to the free list of the corresponding Slab buffer and update the allocated count;

[0062] Slab reclamation judgment: If all index units in a Slab cache are released, the index range corresponding to that Slab cache is returned to the Buddy system;

[0063] Interval merging operation: In the Buddy system, determine whether the interval can be merged with the adjacent Buddy interval (also known as partner interval). If it can be merged, merge it into a larger interval and update the linked list structure.

[0064] By combining the Buddy system with the Slab allocator, a hierarchical MTT index resource management method was constructed. This hierarchical management approach solves the problems of low efficiency and severe fragmentation in existing MTT resource management technologies. It not only achieves efficient resource scheduling but also ensures rapid allocation of fixed-size resource items, significantly improving the overall system response speed and stability. The specific benefits are as follows:

[0065] 1. Improve the efficiency of resource allocation and recycling.

[0066] Buddy system offers fast allocation: Based on power-of-2 interval partitioning and linked list management, the Buddy system can quickly locate contiguous index blocks that meet the requested size, avoiding the overhead of bit-by-bit lookup in the traditional bitmap method.

[0067] Slab Allocator Fast Response: By maintaining a fixed-size index cell cache, the Slab Allocator ensures that frequent resource allocation and release operations incur almost no additional overhead, significantly improving response speed.

[0068] 2. Reduce fragmentation and improve resource utilization.

[0069] The Buddy system reduces external fragmentation: The Buddy system uses a range merging mechanism to merge adjacent ranges after release into a larger range, effectively reducing external fragmentation caused by resource release.

[0070] Slab allocator reduces internal fragmentation: The Slab mechanism manages fixed-size objects, avoiding internal fragmentation caused by inconsistent object sizes in traditional allocation methods.

[0071] 3. Enhance the system's dynamic adaptability and scalability

[0072] The hierarchical structure supports multi-level granular management: the Buddy system is responsible for the dynamic management of large blocks of resources, while the Slab allocator is responsible for the rapid allocation of fine-grained resources. The combination of the two forms a multi-level resource management architecture that can adapt to the resource needs of different scenarios.

[0073] Flexible scalability: When the Slab cache cannot meet the request, it automatically calls the Buddy system to request new resources, ensuring that the system can still run stably under high load.

[0074] 4. Improve hardware access efficiency

[0075] Cache hit rate optimization: Because the Slab mechanism ensures the continuity of resources and the Buddy system controls the distribution pattern of resources, the access to the MTT index is more concentrated, which improves the cache hit rate and reduces the hardware lookup latency.

[0076] Reduced overhead of multi-level table lookup: Compared with the multi-level table structure in the existing technology, this solution avoids multiple table lookup operations, improves hardware access efficiency, and is suitable for low-latency scenarios such as high-performance computing and RDMA.

[0077] For ease of understanding, the following provides a detailed description of the specific implementation of the resource management method based on the combination of Slab allocator and Buddy system provided in the embodiments of this application.

[0078] The linked lists of the Buddy system provided in this application embodiment are managed hierarchically according to the size of the index range, with each linked list corresponding to an index range of a power of 2. This hierarchical management mechanism enables the system to efficiently find, allocate, and merge resources of different granularities.

[0079] Specifically, during system initialization, based on the total MTT index space size (e.g., 256 index entries), the index range is divided into multiple levels according to powers of 2, such as consecutive index ranges of different sizes like 1, 2, 4, 8, 16, 32, 64, 128, and 256. Each level corresponds to a linked list used to manage all available free ranges within that level.

[0080] Here is a specific example to illustrate this:

[0081] Assuming the system has a total of 256 MTT index entries (numbered 0 to 255), the system constructs a linked list structure of the following level:

[0082] Level 0 linked list: manages intervals of size 1 (i.e., a single index item), totaling 256;

[0083] Level 1 linked list: manages intervals of size 2, totaling 128;

[0084] Level 2 linked list: manages intervals of size 4, totaling 64; ...

[0085] Level 8 linked list: manages an interval of size 256, only 1 (i.e. the entire index space).

[0086] When the system receives a request to allocate 10 consecutive MTT index entries, the Buddy system rounds the request size up to the nearest power of 2 (i.e., 16), and then checks if there are 16 free consecutive index intervals in the 4th-level linked list. If they exist, the interval is allocated; otherwise, a 32-index-entry interval is taken from a higher level (such as the 5th level), split into two 16-index-entry intervals, one of which is allocated, and the other is inserted into the 4th-level linked list as a free resource.

[0087] During the resource release phase, the system checks whether the "partner" of the released range is also in an idle state. For example, if the released range is [0~15], its "partner" range is [16~31]. If this range is also idle, the two will be merged into a range of 32 index entries and inserted into the 5th level linked list, thereby realizing automatic resource sorting and efficient reuse.

[0088] Through the aforementioned hierarchical management mechanism, the system can quickly respond to resource requests of different sizes, effectively reduce resource fragmentation, and improve overall resource utilization and allocation efficiency.

[0089] Furthermore, in one embodiment of this application, the Slab allocator directly retrieves an available index unit from the free list and updates the allocated count in the management header when allocating index units, thereby achieving fast and efficient resource allocation. The specific implementation process is as follows:

[0090] Each slab cache consists of a management header and multiple fixed-size index units. The management header records metadata such as the slab's status, free index list pointers, allocated counts, and the cache type to which the slab belongs. The free index units are organized in a linked list manner, with each index unit's head storing a pointer to the next free unit, forming a singly linked list structure.

[0091] Here is a specific example to illustrate this:

[0092] Suppose the system has a Slab buffer for managing MTT index units of size 1. This Slab contains 16 index units (numbered 0 to 15). During the initialization phase, all units are in an idle state, and the free list sequentially connects units 0→1→2→…→15. The management head records that the currently allocated count is 0.

[0093] When an index allocation request is received, the Slab allocator first locates the corresponding Slab buffer, reads the free list pointer from its management header, retrieves the head node of the list (i.e., index unit 0), and removes it from the free list. It then updates the allocated count in the management header to 1 and returns the index unit for use.

[0094] If another allocation request is made subsequently, the Slab allocator continues to retrieve the next node from the free list until the free list is empty. At this point, the system will call the Buddy system to request a new contiguous index range and build a new Slab cache to satisfy subsequent requests.

[0095] Through the above methods, the Slab allocator can achieve fast allocation and efficient management of fixed-size index units, significantly reducing allocation latency and improving the overall system response performance.

[0096] In an optional implementation, when returning the index interval to the Buddy system, it can be further determined whether the index interval is adjacent to its neighboring Buddy interval and both are in an idle state. If so, they are merged into a larger index interval, and the linked list structure is updated. In specific implementations, each index interval in the Buddy system is managed as a fixed-size power of 2. Each interval has a "buddy," which is another interval of the same size and adjacent to it. The system uses a specific algorithm (such as the parity of the starting index and the interval size) to determine whether two intervals are each other's buddies.

[0097] Here is a specific example to illustrate:

[0098] Assuming the system has an index range of 0 to 255, and the Buddy system manages intervals of size 16, meaning each interval contains 16 consecutive index entries, and there are currently two adjacent intervals:

[0099] Interval A: Starting index is 0, length is 16, status is idle;

[0100] Interval B: Starting index is 16, length is 16, and status is also idle.

[0101] At this point, the system determines that the two intervals are each other's "partners," meaning they are the same size, physically adjacent, and both are in an idle state. Therefore, the system merges these two intervals into a larger interval with a starting index of 0 and a length of 32, removes the two intervals from the original linked list of size 16, and inserts the merged interval into the linked list corresponding to size 32.

[0102] In the subsequent resource allocation process, when a request requires 32 index entries, the merged interval can be directly retrieved from the linked list, thereby effectively reducing resource fragmentation and improving resource utilization and allocation efficiency.

[0103] Through the aforementioned mechanism, this application can automatically identify and merge adjacent free intervals after the index interval is released, forming a larger contiguous resource block and further optimizing resource management performance. This entire process, by strictly defining the identifier, status, and linking relationships of the index interval, achieves dynamic allocation and reclamation of a large range of index resources, ensuring that allocation strategies can be effectively adjusted in large-scale resource management and reducing scattered gaps.

[0104] Furthermore, in one embodiment of this application, the number and size of the Slab cache are dynamically adjusted according to the resource usage during system operation, thereby improving the flexibility and adaptability of resource management. The specific implementation process is as follows:

[0105] Each Slab cache manages fixed-size MTT index units (e.g., sizes of 1, 2, 4, etc.). During operation, the system continuously monitors the usage of each Slab cache, including metrics such as idle rate and allocation failure rate. When a Slab cache frequently experiences resource shortages or remains underutilized for extended periods, the system dynamically adjusts its capacity or number according to a preset strategy.

[0106] Here is a specific example to illustrate:

[0107] Suppose the system has a Slab cache that manages MTT index units of size 1. The initial configuration contains 16 index units (numbered 0-15) to handle frequent small-granularity resource requests. During system operation, if the Slab cache frequently experiences allocation failures (i.e., the free list is empty), the system will determine that the current cache capacity is insufficient and trigger an expansion mechanism. This expansion mechanism involves: requesting a new contiguous index range (e.g., 16 index units) from the Buddy system; constructing a new Slab cache based on this range; and adding the new cache to the Slab allocator's management structure, thereby increasing the supply capacity of this type of resource.

[0108] Conversely, if a Slab cache remains idle for an extended period (e.g., its usage rate is below a set threshold), the system will trigger a reclamation mechanism to release the entire Slab cache back to the Buddy system and remove it from the Slab allocator's management structure, thus freeing up resources for other uses.

[0109] Through the above dynamic adjustment mechanism, the resource configuration of the Slab cache can be flexibly adjusted according to the actual operating status, thereby improving the system resource utilization and response performance.

[0110] The method described above in this application can be applied to the management of MTT resources in RDMA devices. MTT (Memory Translation Table) is used to store the mapping information from virtual addresses to physical addresses and is a key data structure for remote memory access in RDMA devices.

[0111] During RDMA communication, the user program specifies remotely accessible memory regions by registering Memory Regions (MRs). The system needs to allocate a set of contiguous MTT index entries for each MR to describe the physical address mapping information of that memory region. Since the hardware requires that the MTT index entries be contiguous, efficient MTT resource management is crucial to RDMA performance.

[0112] In a specific example, suppose that in a certain RDMA device, the system manages a total of 1024 MTT index entries (numbered 0 to 1023) to support address mapping requests from multiple users' memory mapping (MR) entries. When a user initiates a request to register a memory region, the system needs to allocate a contiguous MTT index range for it. The above method achieves efficient management of MTT resources, including:

[0113] The Buddy system builds an index pool: During the initialization phase, the system builds an index resource pool based on the Buddy system, divides the entire MTT index space into multiple intervals of power 2 size, and maintains multiple linked lists to manage these intervals.

[0114] The Slab allocator manages fixed-size index units: For common small-granularity MTT requests (such as 4 index entries), the system allocates contiguous intervals from the Buddy system to build Slab caches, and each Slab cache manages fixed-size index units.

[0115] Dynamic resource allocation and reclamation: When a user initiates an MR registration request, the Slab allocator first searches for available index units in the corresponding cache area; if the cache area resources are insufficient, it calls the Buddy system to expand resources; after the MR is released, the system reclaims the index units and determines whether the entire Slab cache area can be merged into the Buddy system.

[0116] For example, user A initiates a Registered MR (Matchmaker Register) request, requesting the allocation of 12 consecutive MTT (Mean Transmission Tolerance) index entries. The system rounds the request size up to 16 (the nearest power of 2) and calls the Buddy system to search for 16 available index entry ranges. If found, it allocates the range and records it in the address mapping table of the MR. If user A subsequently releases the MR, the system returns the range to the Buddy system and determines whether it can be merged with adjacent ranges to reduce fragmentation.

[0117] Through the above mechanism, this application achieves efficient management of MTT resources in RDMA devices, significantly improving address mapping efficiency, resource utilization and system stability, and is suitable for high-performance network communication and remote memory access scenarios.

[0118] In summary, the resource management method based on the combination of the Slab allocator and the Buddy system provided in this application achieves efficient management of MTT resources by combining the Buddy system and the Slab allocator. The Buddy system effectively reduces external fragmentation and supports dynamic allocation of large resources, while the Slab allocator improves the efficiency of small-granularity resource allocation and reduces internal fragmentation. The synergy between the two improves resource utilization, allocation and reclamation speed, and system dynamic adaptability, making it particularly suitable for high-performance scenarios such as RDMA, and significantly optimizing memory management performance and hardware access efficiency.

[0119] Based on the above method embodiments, this application also provides a resource management device based on the combination of Slab allocator and Buddy system, see [link to relevant documentation]. Figure 3 As shown, the device mainly includes the following parts:

[0120] The first building module 310 is used to build a Buddy system consisting of multiple linked lists. The linked lists are used to record the starting position, length and usage status of the index interval. The index interval is divided according to powers of 2.

[0121] The second building module 320 is used to allocate contiguous index ranges from the Buddy system to build Slab caches, each Slab cache including a management header and multiple fixed-size index units;

[0122] The lookup module 330 is used to look up and allocate available index units in the Slab cache through the Slab allocator when a resource request is received;

[0123] Module 340 is invoked to call the Buddy system to allocate a new contiguous index range when there are no available index units in the Slab buffer, and to build a new Slab buffer based on that range.

[0124] The release module 350 is used to return the index range corresponding to the Slab buffer to the Buddy system after releasing the index unit if all index units in the corresponding Slab buffer have been released, and to determine whether it can be merged with the adjacent index range.

[0125] In one feasible implementation, the linked lists of the Buddy system are hierarchically managed according to the size of the index interval, with each linked list corresponding to an index interval of a power of 2.

[0126] In one feasible implementation, the management header records the pointers to the free index necklace table, the usage status of the Slab, and the number of allocated index units.

[0127] In one feasible implementation, the above apparatus further includes: a first update module, configured to: when allocating index units, the Slab allocator directly retrieves an available index unit from the free list and updates the allocated count in the management head.

[0128] In one feasible implementation, when returning the index interval to the Buddy system, the above-mentioned device further includes: a second update module, used to: determine whether the index interval is adjacent to its adjacent Buddy interval and both are in an idle state; if so, merge them into a larger index interval and update the linked list structure.

[0129] In one feasible implementation, the number and size of the Slab cache are dynamically adjusted based on the resource usage during system operation.

[0130] In one feasible implementation, it is applied to the management of MTT resources in an RDMA device, wherein the MTT resources are used to store mapping information from virtual addresses to physical addresses.

[0131] The resource management device based on the combination of Slab allocator and Buddy system provided in this application has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts of the resource management device based on the combination of Slab allocator and Buddy system that are not mentioned in the embodiment can be referred to the corresponding content in the aforementioned resource management method embodiment based on the combination of Slab allocator and Buddy system.

[0132] This application also provides an electronic device, such as... Figure 4 The diagram shows the structure of the electronic device 100, which includes a processor 41 and a memory 40. The memory 40 stores computer-executable instructions that can be executed by the processor 41. The processor 41 executes the computer-executable instructions to implement any of the above-mentioned resource management methods based on the combination of Slab allocator and Buddy system.

[0133] exist Figure 4 In the illustrated embodiment, the electronic device further includes a bus 42 and a communication interface 43, wherein the processor 41, the communication interface 43, and the memory 40 are connected via the bus 42.

[0134] The memory 40 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 43 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 42 may be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus 42 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0135] Processor 41 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 41 or by instructions in software form. Processor 41 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in the memory. The processor 41 reads the information in the memory and, in conjunction with its hardware, completes the steps of the resource management method based on the combination of the Slab allocator and the Buddy system in the aforementioned embodiment.

[0136] This application also provides a computer-readable storage medium storing computer-executable instructions. When these computer-executable instructions are called and executed by a processor, they cause the processor to implement the above-described resource management method based on the combination of the Slab allocator and the Buddy system. For specific implementation details, please refer to the foregoing method embodiments, which will not be repeated here.

[0137] The computer program product of the resource management method and apparatus based on the combination of Slab allocator and Buddy system provided in this application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.

[0138] Unless otherwise specifically stated, the relative steps, numerical expressions, and values ​​of the components and steps described in these embodiments do not limit the scope of this application.

[0139] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0140] In the description of this application, it should be noted that the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0141] In the description of this application, it should also be noted that, unless otherwise expressly specified and limited, the terms "set up," "install," "connect," and "link" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0142] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A resource management method based on the combination of Slab allocator and Buddy system, characterized in that, include: Construct a Buddy system consisting of multiple linked lists. The linked lists are used to record the starting position, length, and usage status of index intervals. The index intervals are divided according to powers of 2. The linked lists of the Buddy system are hierarchically managed according to the size of the index intervals, with each linked list corresponding to an index interval of a power of 2 size. Slab caches are constructed by allocating contiguous index ranges from the Buddy system. Each Slab cache includes a management header and multiple fixed-size index units. The management header records pointers to free index necklace tables, the usage status of the Slab, and the number of allocated index units. Upon receiving a resource request, the Slab allocator searches for and allocates an available index unit in the Slab cache. When allocating an index unit, the Slab allocator directly retrieves an available index unit from the free list and updates the allocated count in the management head. When there are no available index units in the Slab cache, the Buddy system is invoked to allocate a new continuous index range, and a new Slab cache is built based on this range. After releasing an index unit, if all index units in the corresponding Slab cache are released, the index range corresponding to the Slab cache is returned to the Buddy system, and it is determined whether it can be merged with an adjacent index range. When returning the index range to the Buddy system, it is determined whether the index range is adjacent to its adjacent Buddy range and both are in an idle state. If so, it is merged into a larger index range and the linked list structure is updated. The method is applied to the management of MTT resources in an RDMA device, wherein the MTT resources are used to store mapping information from virtual addresses to physical addresses.

2. The resource management method based on the combination of Slab allocator and Buddy system according to claim 1, characterized in that, The number and size of the Slab cache are dynamically adjusted based on the resource usage during system operation.

3. A resource management device based on the combination of a Slab allocator and a Buddy system, characterized in that, The apparatus for performing the method of claim 1, comprising: The first construction module is used to construct a Buddy system consisting of multiple linked lists. The linked lists are used to record the starting position, length and usage status of the index interval. The index interval is divided according to powers of 2. The second building module is used to allocate consecutive index intervals from the Buddy system to build Slab caches, each Slab cache including a management header and multiple fixed-size index units; The lookup module is used to search for and allocate available index units in the Slab cache area through the Slab allocator when a resource request is received; The module is used to call the Buddy system to allocate a new continuous index interval when there are no available index units in the Slab cache, and to build a new Slab cache based on the interval. The release module is used to return the index range corresponding to the Slab buffer to the Buddy system after releasing the index unit if all index units in the corresponding Slab buffer have been released, and to determine whether it can be merged with the adjacent index range.

4. An electronic device, characterized in that, It includes a processor and a memory, the memory storing computer-executable instructions that can be executed by the processor, the processor executing the computer-executable instructions to implement the resource management method based on the combination of Slab allocator and Buddy system as described in claim 1 or 2.

5. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the resource management method based on the combination of the Slab allocator and the Buddy system as described in claim 1 or 2.

Images