A memory block management method and controller

Abstract

The application provides a memory block management method and a controller, the method comprising: obtaining a configuration file in a Linux kernel, parsing a memory size interval from the configuration file, determining a use state of a memory block in the memory size interval, and setting a bit mark of the use state in a corresponding mark bit of each memory block; judging whether a memory size of a target memory block of a current allocation request is in the memory size interval, if yes, judging whether a first free list in an SLUB allocator is empty, the first free list being used for storing mark bits of memory blocks which are free; if not, sequentially selecting mark bits of the target memory block from the first free list in the SLUB allocator, and determining the target memory block according to the mark bits of the target memory block, for the current allocation request. The application can solve the problems of high memory block metadata occupation and low allocation efficiency in the SLUB allocator.

Description

Technical Field

[0001] This invention belongs to the field of Linux kernel memory management technology, and in particular relates to a memory block management method and controller. Background Technology

[0002] While existing SLUB allocators simplify the queue structure and metadata management of traditional SLAB allocators, two prominent issues remain in scenarios involving small memory blocks (especially high-frequency small objects ranging from 16 bytes to 256 bytes): First, metadata consumption is high. The SLUB allocator uses the `inuse` field of the `struct page` data structure to record the number of allocated objects in each SLAB. This field is of type `short unsigned int` (occupying 2 bytes). For a large number of small memory blocks, the `inuse` field alone consumes a significant amount of memory resources. In memory-constrained embedded devices, this metadata redundancy further squeezes available memory space. Second, currently, requesting the allocation of a memory block requires a global search for a suitable memory block, resulting in low efficiency in memory block allocation management.

[0003] Currently, most optimization solutions for Linux kernel memory management focus on large-scale modifications such as huge page memory optimization and buddy algorithm refactoring. These solutions are extensive and complex, requiring modifications to multiple core kernel modules, making it difficult to guarantee compatibility and stability. They are also unsuitable for embedded systems, IoT applications, and other scenarios with limited memory resources and sensitivity to kernel modifications. Furthermore, for localized optimization solutions targeting small memory block management in the SLUB allocator, there are currently no effective technical means to address the issues of metadata redundancy and low memory block management efficiency without affecting the compatibility of the original kernel architecture. Summary of the Invention

[0004] This invention provides a memory block management method and controller to address the problems of excessive memory block metadata usage and low allocation efficiency in the SLUB allocator within a preset memory size range without affecting the original kernel architecture.

[0005] This invention discloses a memory block management method based on the Linux kernel SLUB allocator, the method comprising: Obtain the configuration file in the Linux kernel, parse the memory size range from the configuration file, determine the usage status of the memory blocks within the memory size range, and set the usage status bit flag for each memory block. Determine whether the memory size of the target memory block of the current allocation request is within the memory size range. If it is within the memory size range, determine whether the first free list in the SLUB allocator is empty. The first free list is used to store the flag bits of memory blocks marked as free. If not, the target memory block is selected sequentially from the first free list of the SLUB allocator by its flag bit, and the target memory block is determined based on the flag bit of the target memory block for the current allocation request.

[0006] Optionally, setting the status bit flags for each memory block includes: Define an array of status flags of type unsigned char, the address of which points to the free field in the structpage data structure, wherein each element of the status flag array is a bit flag, and each bit flag indicates the usage status of the memory block as free or occupied.

[0007] Optionally, this also includes retrieving configuration files from the Linux kernel: The minimum and maximum memory capacities are written into a configuration file in the Linux kernel to configure the memory size range.

[0008] Optional, also includes: When releasing a memory block, determine whether the size of the currently released memory block is within the specified memory size range; If the memory is within the specified size range, the memory block is released and the bit flag corresponding to the released memory block is changed to free; The bit flag is changed to the flag corresponding to the free memory block and inserted at the tail of the first free list of the SLUB allocator.

[0009] Optionally, the step of releasing the memory block and modifying the bit flag corresponding to the released memory block to free includes: The corresponding element number in the status flag array is determined based on the position order of the currently released memory block among all memory blocks within the specified memory size range; Determine the binary bits in the free field that correspond to the element's sequence number; Set the bit flag in the binary bits to the binary number corresponding to the idle state.

[0010] Optionally, this also includes modifying the bit flag corresponding to the freed memory block to free before: Based on the bit flags of the currently freed memory block in the SLUB allocator, determine whether the preceding and following bit flags adjacent to the bit flag of the currently freed memory block are both free. If all are free, then the step of releasing the memory block and modifying the bit flag corresponding to the released memory block to free; inserting the flag corresponding to the memory block whose bit flag has been changed to free into the tail of the first free list of the SLUB allocator includes: The currently freed memory block, along with the memory blocks whose previous and subsequent bit flags are displayed, are merged into a contiguous memory block. The bit flags of the contiguous memory block are updated in one instruction, and the flags of the contiguous memory block are inserted into the tail of the free list in one go.

[0011] Optionally, this also includes modifying the bit flag corresponding to the freed memory block to free before: Determine if the physical address of the currently released memory block has an adjacent memory block that is currently free; If it exists, merge the current memory block with the adjacent memory block into a new memory block, determine and modify the bit flags of the new memory block; Determine whether the new memory block exceeds the range of the memory size range. If so, insert the flag of the new memory block into the preset second free list.

[0012] Optional, also includes: If the first free list in the SLUB allocator is empty, a memory block is selected from the global free list for the current allocation request.

[0013] Optional, also includes: If the memory size of the target memory block in the current allocation request exceeds the memory size range and is less than the theoretical maximum memory block capacity of the second free list, then determine whether the second free list in the SLUB allocator is empty. If not, the target memory block is selected sequentially from the second free list of the SLUB allocator, and the target memory block is determined based on the target memory block's flag bit for the current allocation request; If the second free list in the SLUB allocator is empty, a memory block is selected from the global free list for the current allocation request.

[0014] Another aspect of the present invention discloses a controller comprising: The information acquisition module is used to acquire configuration files in the Linux kernel, parse the memory size range from the configuration files, determine the usage status of memory blocks within the memory size range, and set the usage status bit flag for each memory block. The matching and determination module is used to determine whether the memory size of the target memory block of the current allocation request is within the memory size range. If it is within the memory size range, it determines whether the first free list in the SLUB allocator is empty. The first free list is used to store the flag bits of memory blocks marked as free. The request processing module is used to, if not, sequentially select the target memory block's flag bit from the first free list of the SLUB allocator, determine the target memory block based on the flag bit of the target memory block, and use it for the current allocation request.

[0015] As can be seen from the above technical solution, this invention first parses the configuration file to determine the memory size range and the memory blocks to be managed. Then, it sets a memory block usage status flag to record the usage status of the memory block in the form of a bit flag, which greatly reduces the amount of metadata. When allocating a memory block for a request, it first determines whether the target size required by the request is within the range, and then checks the corresponding first free list, avoiding traversing all lists and reducing invalid operations. When the first free list is not empty, the required memory blocks are directly selected sequentially. The flag bit ensures that free memory blocks can be quickly located. This invention, by setting a flag bit to record the usage status of memory blocks, and then setting the flag bit of the free list to store the memory blocks with an empty usage status, greatly reduces the amount of metadata of memory blocks, improves the efficiency of memory block allocation and location, effectively solves the defects of low allocation efficiency, time-consuming location, and large kernel overhead in the background, improves the real-time performance of memory allocation, and reduces kernel resource consumption. Furthermore, this invention only performs local optimization on the small memory block management part of the SLUB allocator, without refactoring the core logic of kernel memory management. It is suitable for memory-constrained scenarios such as embedded systems and IoT, effectively reducing the metadata overhead of small memory block management, improving allocation and release efficiency, and ensuring system stability. Attached Figure Description

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

[0017] Figure 1 A flowchart illustrating the memory block management method based on the Linux kernel SLUB allocator in an embodiment of the present invention is shown.

[0018] Figure 2 This diagram illustrates the flag bits of the memory block management method based on the Linux kernel SLUB allocator in an embodiment of the present invention.

[0019] Figure 3 A schematic diagram of the first free list of the memory block management method based on the Linux kernel SLUB allocator in an embodiment of the present invention is shown.

[0020] Figure 4 A schematic diagram of the controller in an embodiment of the present invention is shown. Detailed Implementation

[0021] To more clearly illustrate the present invention, the following description, in conjunction with embodiments and accompanying drawings, further explains the invention. Similar components in the drawings are indicated by the same reference numerals. Those skilled in the art should understand that the specific description below is illustrative rather than restrictive and should not be construed as limiting the scope of protection of the present invention.

[0022] In the Linux kernel memory management subsystem, the SLUB allocator, as the only slab-type allocator currently available (SLOB was removed in Linux kernel version 6.4 and SLAB was removed in Linux kernel version 6.5), is mainly responsible for handling high-frequency, small-amount memory allocation requests in the kernel, such as the memory allocation and release of small objects like process descriptors (task_struct) and file objects (inode). It is one of the core modules that ensures the efficient operation of the kernel.

[0023] While existing SLUB allocators simplify the queue structure and metadata management of traditional SLAB allocators, two prominent issues remain in scenarios involving small memory blocks (especially high-frequency small objects ranging from 16 bytes to 256 bytes): First, metadata consumption is high. The SLUB allocator uses the `inuse` field of the `struct page` data structure to record the number of allocated objects in each SLAB. This field is of type `short unsigned int` (occupying 2 bytes). For a large number of small memory blocks, the `inuse` field alone consumes a significant amount of memory resources. In memory-constrained embedded devices, this metadata redundancy further squeezes available memory space. Second, currently, requesting memory block allocation requires a global search for suitable memory blocks, resulting in low memory block allocation management efficiency. Furthermore, existing technologies suffer from untimely merging of free blocks. The SLUB allocator's free block merging relies primarily on a passive triggering mechanism when memory is scarce. After frequent allocation and release of small memory blocks, adjacent free objects cannot be merged in a timely manner, easily leading to internal memory fragmentation. Over long-term operation, this can result in decreased memory utilization and even memory allocation failures.

[0024] Currently, most optimization solutions for Linux kernel memory management focus on large-scale modifications such as massive page memory optimization and buddy algorithm refactoring. These solutions are extensive and complex, requiring modifications to multiple core kernel modules, making compatibility and stability difficult to guarantee. They are also unsuitable for embedded systems, IoT applications, and other scenarios with limited memory resources and sensitivity to kernel modifications. Furthermore, localized optimization solutions for small memory block management in the SLUB allocator lack effective technical means to address metadata redundancy and low memory block management efficiency without affecting the compatibility of the original kernel architecture. Additionally, these solutions tend to accumulate significant amounts of memory fragmentation.

[0025] In view of this, embodiments of the present invention provide a memory block management method based on the Linux kernel SLUB allocator, such as... Figure 1 As shown, the method includes: Obtain the configuration file in the Linux kernel, parse the memory size range from the configuration file, determine the usage status of the memory blocks within the memory size range, and set the usage status bit flag for each memory block. Determine whether the memory size of the target memory block of the current allocation request is within the memory size range. If it is within the memory size range, determine whether the first free list in the SLUB allocator is empty. The first free list is used to store the flag bits of memory blocks marked as free. If not, the target memory block is selected sequentially from the first free list of the SLUB allocator by its flag bit, and the target memory block is determined based on the flag bit of the target memory block for the current allocation request.

[0026] This invention first parses the configuration file to determine the memory size range and then identifies the memory blocks to be managed. Next, it sets a memory block usage status flag to record the memory block's usage status, significantly reducing metadata volume. When allocating a memory block for a request, it first checks if the target size required by the request falls within the range, then checks the corresponding first free list, avoiding traversing all lists and reducing invalid operations. When the first free list is not empty, the required memory blocks are directly selected sequentially. The flag ensures quick location of free memory blocks. This invention, by setting flags to record the memory block's usage status and then setting flags for empty memory blocks in the free list, greatly reduces the amount of metadata for memory blocks, improves memory block allocation and location efficiency, and effectively solves the shortcomings of low allocation efficiency, time-consuming location, and high kernel overhead in the previous invention. It improves the real-time performance of memory allocation and reduces kernel resource consumption. Furthermore, this invention only performs local optimization on the small memory block management part of the SLUB allocator, without refactoring the core kernel memory management logic. It is suitable for memory-constrained scenarios such as embedded systems and IoT, effectively reducing the metadata overhead of small memory block management, improving allocation and release efficiency, and ensuring system stability.

[0027] In this optional implementation, the memory block management method first completes the configuration of the memory size range to limit the range of small memory blocks to be managed. The specific process is as follows: before obtaining the configuration file in the Linux kernel, the minimum memory capacity and the maximum memory capacity are written into the configuration file in the Linux kernel to configure the memory size range.

[0028] Understandably, most small memory block allocation requests target memory sizes within a certain range. In order not to affect the original kernel architecture and to improve program compatibility, technicians can set the minimum and maximum memory capacities according to the memory allocation requirements of the actual application scenario, and write these two parameters into the Linux kernel configuration file to complete the configuration of the memory size range.

[0029] After configuring the memory size range, during the memory block allocation process, the configuration file in the Linux kernel can be obtained, the memory size range can be parsed from the configuration file, the usage status of memory blocks within the specified memory size range can be determined, and a flag indicating the usage status can be set for each memory block. Therefore, in this optional implementation, only the specific values ​​of the minimum and maximum memory capacities in the configuration file need to be set or modified to set or update the memory size range. Dynamic management of memory blocks in different memory size ranges can be achieved without modifying the memory block management program, enabling this application to adapt to memory-constrained scenarios such as embedded systems and the Internet of Things, and allowing for flexible configuration.

[0030] In a specific example, firstly, the configuration file containing the minimum and maximum memory capacities is obtained through the file read interface provided by the Linux kernel. By parsing this configuration file, the specific values ​​of the minimum and maximum memory capacities are extracted. For example, the minimum memory capacity is 16 bytes, and the maximum memory capacity is 256 bytes. This determines the memory size range to be 16 bytes to 256 bytes. This range covers frequently allocated small objects in the Linux kernel, such as small fields in the process descriptor `task_struct` and basic attributes of file objects (inodes). The 16-byte to 256-byte range then clearly identifies the small memory blocks within this range that require unified management. These memory blocks are all managed by the Linux kernel's SLUB allocator and are used to respond to various memory allocation and deallocation requests.

[0031] In a specific example, two configuration parameters can be added to the kernel boot configuration file / boot / config-xxx: Minimum memory capacity: SLUB_SMALL_MEM_MIN; Maximum memory capacity: SLUB_SMALL_MEM_MAX; Users can adjust these two parameters to optimize the range based on the embedded device's memory resources, such as 128MB or 256MB of memory, without needing to recompile the kernel.

[0032] Subsequently, the system iterates through the memory blocks, checking each block's size against a specified range. Assume eight memory blocks fall within this range. For each of these eight blocks, their current usage status is determined, including both idle and occupied states. An idle state indicates the block is not currently occupied by any process and can be used to respond to memory allocation requests; an occupied state indicates the block is currently occupied by a process and cannot respond to new memory allocation requests. After determining the usage status of each block, a flag is set to indicate its usage status. This flag enables rapid querying of memory block usage status and significantly reduces the amount of metadata associated with the memory blocks, thus minimizing operation time and resource consumption.

[0033] It should be noted that the minimum and maximum memory capacities mentioned above can be 16 bytes for the minimum and 256 bytes for the maximum. Of course, in practical applications, these values ​​can be flexibly adjusted according to the memory allocation requirements of the actual application scenario. They are not fixed values, and this application does not limit them.

[0034] In an optional implementation, setting the flag bits corresponding to each memory block using the status bit flag includes: Define an array of status flags of type unsigned char, the address of which points to the free field in the structpage data structure, wherein each element of the status flag array is a bit flag, and each bit flag indicates the usage status of the memory block as free or occupied.

[0035] Understandably, based on the existing struct page data structure in Linux kernel version 6.5, which contains a reserved free field, i.e. a field not used by the SLUB allocator, this reserved free field can be used as a flag bit for the status of small memory blocks, to store the bit flag of the usage status.

[0036] Specifically, an array of status flags of type `unsigned char` can be defined. The address of the status flag array points to the free field in the `struct page` data structure. Each element of the status flag array serves as a bit flag, indicating whether the memory block is free or occupied. For example, in this embodiment, considering the eight memory blocks within the memory size range, an array of status flags of type `unsigned char` is defined. The length of this status flag array is determined by the number of memory blocks. Since each field occupies one byte (8 bits), such as... Figure 2As shown, only one field is needed to locate and mark the usage status of eight memory blocks. This allows for the storage and management of the usage status of a memory block using a single binary bit. The address of this status mark array points to the free field in the struct page data structure. In other words, the existing free fields in the struct page data structure are allocated to the status mark array. By using the existing free fields in the struct page data structure to store each element of the status mark array, there is no need for a complex memory block metadata structure or additional resources to store the metadata in the form of the tag bit in this application, which greatly improves resource utilization.

[0037] In this configuration, each element of the status flag array corresponds to a bit flag of a memory block. Each binary bit serves as a bit flag for a memory block. For example, for five memory blocks within a memory size range, their order within all memory blocks can be determined based on their physical address order. This physical address order allows each memory block to be mapped to an element in the status flag array from smallest to largest. The first to fifth elements of the status flag array (array element numbers 0-4) correspond to the first to fifth memory blocks within the five memory blocks within the memory size range, respectively, and these blocks are ordered sequentially according to their physical addresses. Optionally, a binary bit of "0" can be set to indicate that the corresponding memory block is idle, and a binary bit of "1" can indicate that the corresponding memory block is occupied. This setting can be adjusted according to actual needs, as long as the distinction between idle and occupied bit flags is clear and quick to identify, without requiring a fixed marking rule.

[0038] Assuming an initial state with 5 memory blocks within a given memory size range, 2 blocks are occupied and 3 are free, then in the corresponding status flag array, the bits corresponding to the 2 occupied blocks are all set to "1", and the bits corresponding to the 3 free blocks are all set to "0". This status flag array allows for quick querying of the usage status of each memory block within its size range, without needing to traverse the complete attribute information of the memory blocks; only the corresponding bits need to be read to determine the status. This significantly reduces the time required for status queries, especially in scenarios with frequent memory block allocation and release requests, thereby significantly reducing operation time and kernel overhead.

[0039] Upon receiving a current memory allocation request, the system determines the size of the target memory block required by the request, and then checks whether the target memory size is within the previously configured memory size range. If the target memory size is within this range, it further checks whether the first free list in the SLUB allocator is empty; if the target memory size exceeds this range, it does not need to check the first free list and directly proceeds to the subsequent allocation process for memory exceeding the range.

[0040] The first free list is specifically used to store the marker bits of memory blocks that are marked as free and fall within the aforementioned memory size range. This facilitates quick location and retrieval of memory blocks, avoiding the tedious operation of global traversal. For example, after setting the marker bits for 5 memory blocks within the memory size range, the marker bits of all memory blocks marked as free (binary bit "0") are inserted into the first free list. In this embodiment, there are initially 3 free memory blocks, so the first free list initially stores the marker bits of these 3 memory blocks, and at this time, the first free list is not empty. In a specific example, such as... Figure 2 As shown, each byte in the status flag array contains 8 flag bits. The flag bits with element numbers 0, 2, 3, 5, 6, and 7 have a value of 0, indicating an idle status. These flag bits can be stored in the first free linked list, as shown below. Figure 3 As shown.

[0041] Since the first free list is not empty, the flag bits of target memory blocks are selected sequentially from the first free list of the SLUB allocator. The target memory block is determined based on its flag bits for the current allocation request. For example, starting from the head of the first free list, the flag bits of each memory block in the list are read sequentially. First, the flag bits of the first memory block are read. If it is a target memory block available for request processing, its order and position can be determined based on its flag bits, quickly locating the memory block for allocation to the request. Assuming the size of the first memory block does not match the target memory size, the next memory block is read until a usable target memory block is found. Then, the flag bit of the memory block allocated to the request is changed from "0" to "1" (indicating that the memory block is already occupied), and the flag bit of that memory block is removed from the first free list. The memory block is then allocated to the current memory allocation request, completing the memory allocation. The entire allocation process does not require traversing the global memory blocks; it only requires sequential searching in the first free list. Furthermore, the availability of memory blocks can be quickly confirmed through flag bits, significantly improving allocation efficiency and reducing kernel overhead.

[0042] In an optional implementation, if the first free list in the SLUB allocator is empty, a memory block is selected from the global free list for the current allocation request.

[0043] Specifically, for scenarios where the first free list is empty, this invention also provides a corresponding processing method. If the first free list in the SLUB allocator is empty, a memory block is selected from the global free list for the current allocation request. Specifically, assuming that all three free memory blocks in the current first free list have been allocated, and the first free list is empty, if there is an allocation request with a target memory size within the memory size range, the first free list is not queried again; instead, a suitable memory block is directly selected from the global free list.

[0044] The global free list stores all memory blocks that are in a free state except for the first free list. At this time, the global free list is traversed to find a memory block that is in a free state and whose memory size matches the target size, and the memory block allocation for this request is completed.

[0045] It should be noted that the global free list is traversed only when the first free list is empty. This design maximizes the advantages of the first free list's categorized management, reduces the frequency of global traversal, thereby reducing kernel overhead and improving allocation efficiency. Even when the first free list is empty, the global free list ensures that allocation requests are responded to promptly, avoiding allocation failures and guaranteeing the stability and reliability of memory management.

[0046] In an optional embodiment, the memory block management method of the present invention further includes a memory block release process, which works in conjunction with the allocation process to achieve efficient management and recycling of memory blocks. The specific process is as follows: when releasing a memory block, it is determined whether the memory size of the currently released memory block is within the memory size range; if it is within the memory size range, the memory block is released and the bit flag corresponding to the released memory block is modified to free; the bit flag corresponding to the memory block whose bit flag has been changed to free is inserted into the tail of the first free linked list of the SLUB allocator.

[0047] Specifically, assuming a process terminates and needs to release its occupied memory block, the first step is to determine if the memory block's size is within a specified range. If it is, after releasing the memory block, the corresponding bit flag is changed to free. Optionally, if the memory block exceeds the range, only the block itself needs to be released, its basic free attribute modified, without modifying the aforementioned status flag array, and then its flag bit inserted into the global free list.

[0048] Specifically, the process involves determining the element number in the status flag array based on the position of the currently released memory block among all memory blocks within the specified memory size range; determining the binary bit in the free field corresponding to the element number; and setting the bit flag in the binary bit to the binary number corresponding to the free usage status. This process enables modification of the bit flag's usage status, ensuring that the bit flag remains consistent with the actual usage status of the memory block for subsequent allocation requests.

[0049] For example, the currently released memory block is the third of five memory blocks within the memory size range. First, its position among the five memory blocks is determined to be the third, so the element number corresponding to the third memory block is 2. The address of this element in the free field of the struct page data structure can be calculated from the address of the status flag array. Then, it is determined that the corresponding binary bit in this element changes from occupied to free. Since the binary number corresponding to the free state is "0", the bit flag of the binary bit corresponding to element number 2 is changed from "1" (occupied) to "0" (free), completing the bit flag modification.

[0050] Subsequently, the flag of the memory block is inserted at the end of the first free list. This adds a free memory block to the first free list. When a suitable memory allocation request arises later, this memory block can be selected from the list for allocation, achieving memory block recycling. For example, if the previously allocated third memory block is released, its flag is changed to "0," and its flag, i.e., element number 2, is inserted at the end of the first free list. Now, in addition to the original free memory blocks, the first free list includes information about the third memory block. The next time a suitable allocation request arises, this memory block can be retrieved sequentially and allocated, ensuring full utilization of memory resources.

[0051] It is important to note that the modification of the bit flags must be consistent with the actual release state of the memory block to avoid discrepancies between the bit flags and the actual state. Otherwise, allocation errors will occur, affecting the stability of memory management. Therefore, during the release of a memory block, it is necessary to first confirm whether the memory size of the memory block is within the specified range, and then modify the bit flags according to the corresponding rules to ensure the accuracy and standardization of the operation.

[0052] In an optional implementation, in order to further improve the utilization of memory resources and avoid the waste of resources and reduced efficiency caused by multiple operations required to release multiple adjacent free memory blocks, before modifying the bit flag corresponding to the released memory block to free, a step of judging and merging the free status of adjacent memory blocks is included. The specific process is as follows: According to the bit flag of the currently released memory block in the SLUB allocator, it is determined whether the usage status of the preceding bit flag and the following bit flag adjacent to the bit flag of the currently released memory block are both free; if they are both free, the currently released memory block and the memory blocks with preceding and following bit flags are merged into a contiguous memory block, the bit flag of the contiguous memory block is updated by one instruction, and the flag bits of the contiguous memory block are inserted into the tail of the first free linked list.

[0053] Specifically, assuming the currently released memory block is the 3rd memory block, before modifying its bit flag to free, the usage status of the memory blocks corresponding to the preceding and following bit flags of this memory block is first queried, i.e., the bit flags of the 2nd memory block (the preceding memory block) and the 4th memory block (the following memory block). If the 2nd and 4th memory blocks are in a state of just being released or about to be released and their bit flags need to be modified, then the 2nd, 3rd, and 4th memory blocks are merged into a single contiguous memory block. A single bit flag modification instruction is used to uniformly modify the bit flags of the 2nd, 3rd, and 4th memory blocks. Then, an insertion operation is performed to insert the 2nd, 3rd, and 4th memory blocks into the first free list. This avoids resource waste and efficiency reduction caused by multiple identical operations. Furthermore, checking only two adjacent memory blocks avoids the additional resource consumption caused by excessive memory block recursive queries, thus promoting maximum resource utilization and efficient system operation.

[0054] It should be noted that merging adjacent memory blocks only occurs when both the preceding and succeeding memory blocks of the currently released memory block are free. If only one adjacent memory block is free, or both adjacent memory blocks are occupied, merging is not performed; instead, the bit flag of the currently released memory block is modified to free, and it is inserted into the first free linked list. This design ensures the formation of contiguous memory blocks while avoiding unnecessary merging operations, balancing efficiency and practicality.

[0055] In an optional implementation, before modifying the bit flag corresponding to the released memory block to free, the method further includes: determining whether there is an adjacent memory block with a free usage state at the physical address of the currently released memory block; if so, merging the current memory block with the adjacent memory block into a new memory block, determining and modifying the bit flag of the new memory block; determining whether the new memory block exceeds the range of the memory size range, and if so, inserting the flag bit of the new memory block into a preset second free linked list.

[0056] Specifically, considering the eight memory blocks in this embodiment, assuming the currently released memory block is the fifth memory block, we first determine whether the memory blocks physically adjacent to this memory block are free. These memory blocks can be memory blocks within a memory size range or other global memory blocks. Assuming the sixth memory block is currently free, and the currently released fifth memory block and its adjacent sixth memory block are adjacent free memory blocks, we merge these two memory blocks into a new memory block. The memory size of the merged new memory block is the sum of the memory sizes of the two memory blocks. In this way, memory block merging can be achieved simultaneously during the memory block release process, reducing the fragmentation rate while releasing and reclaiming memory blocks.

[0057] It should be noted that when multiple memory blocks are merged into a new memory block and all of the new memory blocks are within the memory size range, the flag bits of all memory blocks need to be updated according to the physical address order of the merged new memory block in all memory blocks, and the bit flags in the flag bits are updated at the same time.

[0058] Understandably, merging multiple memory blocks may exceed the memory size range. Therefore, optionally, if a memory block within the memory size range is merged with other global memory blocks to form a new memory block whose size exceeds the range of the memory size range, the new memory block is inserted into a global linked list for subsequent use. If all memory blocks merged into a new memory block are within the memory size range, the upper limit of the memory size of the merged new memory block is clear. Therefore, a second free linked list can be preset with memory greater than the memory size range but less than the upper limit of merging 3 memory blocks (for example, when the maximum memory capacity is 256, the upper limit is 3*256). The flag of the new memory block is inserted into the preset second free linked list for memory block allocation for business requests of the corresponding memory size. Through this release and merging process, a memory block of moderate size can be obtained, enabling fast allocation of the corresponding requested memory block and improving memory management efficiency.

[0059] The second free list stores the flags of consecutive free memory blocks that exceed the aforementioned memory size range after merging. It is managed separately from the first free list and the global free list to facilitate subsequent processing of large memory allocation requests exceeding the range, avoid confusion with free memory blocks within the range, and further improve allocation efficiency. For example, if the new memory block resulting from merging the 5th and 6th memory blocks exceeds the memory size range, after setting the flag and its value to free for the new memory block, it is inserted into the second free list. Subsequent large allocation requests exceeding the range can directly query the second free list in the SLUB allocator. If the second free list is empty, then the global free list is queried, reducing the number of steps.

[0060] Specifically, taking the eight memory blocks in this embodiment as an example, assuming that the second free list currently stores the new memory blocks that exceed the range after the above-mentioned merging, the theoretical maximum memory block capacity of the second free list is the maximum size that the currently released memory block may reach after merging with the two adjacent memory blocks.

[0061] If there is a current allocation request where the target memory size exceeds the memory size range but is smaller than the theoretical maximum capacity of the second free list, the process first checks if the target memory size exceeds the memory size range. If it does, and the target memory size exceeds the range but is smaller than the theoretical maximum memory block capacity of the second free list, the process then checks if the second free list is empty. Since the second free list contains merged contiguous memory blocks that exceed the range, it is not empty. The target memory block is then selected sequentially from the second free list based on its flag bit, and the target memory block is determined accordingly.

[0062] For example, the second free list only stores the above-mentioned merged contiguous memory blocks that exceed the interval. The flag bit of the memory block is read, and its corresponding flag bit is obtained. The memory block is in a free state, and its memory size is greater than or equal to the target size, which is suitable for the current allocation request. Therefore, the contiguous memory block is allocated to the current request, and the flag bit of the memory block is modified to the occupied state. At the same time, the information of the memory block is removed from the second free list, and the allocation is completed.

[0063] If the second free list is currently empty (e.g., the merged memory blocks exceeding the range have already been allocated), and a memory allocation request exceeds the range and is smaller than the theoretical maximum capacity, then the second free list is determined to be empty. A suitable free memory block is then searched in the global free list to complete the allocation. For example, if the second free list is empty and there is a large allocation request exceeding the range, the global free list is traversed to find a free memory block with a suitable size. If multiple scattered free memory blocks exist with a suitable total capacity but cannot be merged into a contiguous block, the large allocation request cannot be satisfied, and new memory resources must be requested from the system. If contiguous free memory blocks exist (not merged into the second free list), then these contiguous blocks can be allocated, fulfilling the request.

[0064] It should be noted that the first and second free linked lists in this application can adopt the FIFO (First In First Out) mechanism. When allocating, free memory blocks are searched first from the dedicated linked list to shorten the search time; when releasing, the free memory block is inserted into the end of the linked list to simplify the linked list operation logic.

[0065] The following specific example will further illustrate this application. This embodiment is based on Linux kernel version 6.6 (SLAB and SLOB have been removed, only the SLUB allocator is retained), and its functionality focuses on optimizing the management of small memory blocks of 16 bytes to 256 bytes. It does not modify the core architecture of the SLUB allocator or the original kernel memory management interface. The specific implementation steps are as follows: Step 1: The default small memory block size range is 16 bytes to 256 bytes. This range covers frequently allocated small memory blocks (objects) in the Linux kernel, such as small fields in the process descriptor `task_struct` and basic attributes of file object inodes. Add two configuration parameters to the kernel boot configuration file (` / boot / config-xxx`): `SLUB_SMALL_MEM_MIN` (default 16) and `SLUB_SMALL_MEM_MAX` (default 256). Users can modify these two parameters to adjust the optimization range according to the memory resources of the embedded device (e.g., 128MB or 256MB of memory) without recompiling the kernel.

[0066] Step 2: Based on the existing struct page data structure in Linux kernel version 6.5, which contains a reserved free field (not used by the SLUB allocator), this embodiment uses this reserved field as a bit marker storage area for the small memory block status, as specifically implemented as follows: 1. Remove the inuse field (short-signed int type, 2 bytes) from the struct page data structure to record the usage status of small memory blocks, thus avoiding metadata redundancy; 2. Define the reserved free field of struct page as an unsigned char type slab_bitmap array. Each array element (1 byte) is used as a bit flag, corresponding to the status of 8 small memory blocks. A value of 1 for each bit flag indicates that the corresponding small memory block has been allocated, and a value of 0 indicates that the corresponding small memory block is free. 3. Two new helper functions have been added: bitmap_set() and bitmap_get(). The bitmap_set() function is used to update the corresponding bit flag of slab_bitmap when allocating / deallocating small memory blocks; the bitmap_get() function is used to query the status of a specified small memory block (by judging by the value of the bit flag). These two functions are only called by the small memory block management module of the SLUB allocator and do not affect other kernel modules.

[0067] The simplified code snippet related to the struct page is as follows (only fields relevant to this invention are shown): struct page { void *freelist; / / Existing field, pointing to the first free object in the slab. short unsigned int offset; / / Existing field, marking the position of the next free object pointer. unsigned char slab_bitmap[]; / / Add a bit marker field to store the state of the small memory block. / / Other original fields remain unchanged. }; It should be noted that those skilled in the art can set the specific program code of the newly added functions in this application according to actual needs, which is a conventional technical means in the field and will not be described in detail here.

[0068] Step 3: In the kfree() function (kernel small memory block release function) of the SLUB allocator, add adjacent free block detection and merging logic. Use lightweight judgment, only check one adjacent object before and one adjacent object after the currently released object. The specific implementation is as follows: 1. When a small memory block is released, the bitmap_get() function is called to query the status of the preceding object (the index of the current object is minus 1) and the following object (the index of the current object is plus 1) of the currently released object (by judging by the bit flags in slab_bitmap). 2. If both the preceding and following objects are in a free state, then merge the three objects into a single contiguous free block, update the slab_bitmap bit flags (set the corresponding bit flags of the three objects to 0), and insert the merged free block into the corresponding position in the free object linked list; 3. If only the preceding or following object is in an idle state, it will not be merged for the time being. Instead, the bit flag of the currently released object will be updated to avoid excessive consumption of CPU resources. 4. The merging logic is triggered only when a small memory block is released, without adding a separate merging thread, ensuring the real-time nature of the release operation and without consuming additional CPU resources.

[0069] Step 4: In each per-CPU cache of the SLUB allocator, add a dedicated free list for small memory blocks, small_mem_freelist, as follows: 1. In the per-CPU cache structure, a new field called small_mem_freelist is added. This field is a doubly linked list that only stores free small memory blocks within the range preset in step 1. 2. Modify the kmalloc() function (kernel memory allocation function) of the SLUB allocator. When the size of the memory allocation request is within the preset optimization range, it will first search for free objects in the small_mem_freelist linked list (using a FIFO mechanism, prioritizing the head object of the linked list); if the linked list is empty, it will then search in the global free linked list to ensure allocation efficiency. 3. Modify the kfree() function of the SLUB allocator to insert small memory blocks that are freed within the preset optimization range at the end of the small_mem_freelist linked list, simplifying linked list operations and avoiding frequent traversal of the linked list.

[0070] Step 5: Compatibility and Stability Testing. The optimization method of this invention was ported to Linux kernel version 6.5 and tested on an embedded device (256MB memory, ARM architecture). The test scenario was high-frequency kernel allocation and release of small memory blocks (simulating process creation / destruction and file read / write scenarios). The test results are as follows: 1. Metadata overhead: Small memory block metadata usage is reduced by 78%, saving approximately 8MB of memory space compared to the original SLUB allocator; 2. Memory fragmentation rate: After running for 24 hours, the memory fragmentation rate in small memory block scenarios decreased from 32% to 10%, and memory utilization improved by 22%. 3. Allocation and release efficiency: Small memory block allocation efficiency is improved by 23%, release efficiency is improved by 17%, and kernel response speed shows no significant fluctuation; 4. Compatibility: Fully compatible with existing kernel modules (file system, process management, network protocol stack), with no crashes, memory leaks, or other issues.

[0071] In this embodiment, all optimization logic focuses on the small memory block management module of the SLUB allocator. The changes only involve local adjustments to the three core functions of the SLUB allocator (kmalloc(), kfree(), slab_init()) and the struct page data structure. The functionality is not large, the compatibility is strong, and it can effectively solve the pain points in the existing technology and adapt to memory-constrained scenarios such as embedded systems and the Internet of Things.

[0072] In an optional embodiment, the present invention also provides a controller for implementing the above-described memory block management method based on the Linux kernel SLUB allocator, such as... Figure 4 As shown, the controller includes: an information acquisition module 11, a matching determination module 12, and a request processing module 13.

[0073] The information acquisition module 11 is used to acquire configuration files in the Linux kernel, parse memory size ranges from the configuration files, determine the usage status of memory blocks within the memory size range, and set the usage status bit flags for each memory block. The matching determination module 12 is used to determine whether the memory size of the target memory block of the current allocation request is within the memory size range. If it is within the memory size range, it determines whether the first free list in the SLUB allocator is empty. The first free list is used to store the flag bits of memory blocks marked as free. The request processing module 13 is used to select the target memory block's flag bit from the first free list of the SLUB allocator in sequence if no, and determine the target memory block for the current allocation request based on the flag bit of the target memory block.

[0074] In summary, this invention relates to the field of Linux kernel memory management technology and discloses an optimized management method for small memory blocks in the Linux kernel SLUB allocator. The aim is to solve the problems of excessive metadata consumption, untimely merging of free blocks leading to memory fragmentation, and low allocation efficiency in existing SLUB allocators during small memory block allocation and release. The method includes: optimizing the struct page metadata storage structure for small memory blocks within a preset range, using bit-marking instead of independent fields to record object usage status, reducing metadata memory consumption; adding an active adjacent free block detection mechanism during small memory block release to judge and merge adjacent free objects in real time, reducing internal fragmentation; and establishing a dedicated cache linked list for small memory blocks to shorten the free object lookup time during allocation. This invention only partially optimizes the small memory block management module of the SLUB allocator, without refactoring the core kernel memory management logic. It is suitable for memory-constrained scenarios such as embedded systems and IoT, effectively reducing metadata overhead in small memory block management, improving allocation and release efficiency, reducing memory fragmentation, and ensuring system stability.

[0075] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in this embodiment.

[0076] This invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in this embodiment.

[0077] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the present invention, and are not intended to limit the implementation of the present invention. For those skilled in the art, other variations or modifications can be made based on the above description. It is impossible to exhaustively list all the implementation methods here. All obvious variations or modifications derived from the technical solutions of the present invention are still within the protection scope of the present invention.

Claims

1. A memory block management method based on the Linux kernel SLUB allocator, characterized in that, The method includes: Obtain the configuration file in the Linux kernel, parse the memory size range from the configuration file, determine the usage status of the memory blocks within the memory size range, and set the usage status bit flag for each memory block. Determine whether the memory size of the target memory block of the current allocation request is within the memory size range. If it is within the memory size range, determine whether the first free list in the SLUB allocator is empty. The first free list is used to store the flag bits of memory blocks marked as free. If not, the target memory block is selected sequentially from the first free list of the SLUB allocator based on its flag bit, and the target memory block is determined according to the flag bit of the target memory block for the current allocation request; The setting of the status bit flags used in the flag bits corresponding to each memory block includes: Define an array of status flags of type unsigned char, the address of which points to the free field in the struct page data structure, wherein each element of the status flag array is a bit flag, and each bit flag indicates the usage status of the memory block as free or occupied.

2. The memory block management method according to claim 1, characterized in that, This also includes before retrieving configuration files from the Linux kernel: The minimum and maximum memory capacities are written into a configuration file in the Linux kernel to configure the memory size range.

3. The memory block management method according to claim 1, characterized in that, Also includes: When releasing a memory block, determine whether the size of the currently released memory block is within the specified memory size range; If the memory is within the specified size range, the memory block is released and the bit flag corresponding to the released memory block is changed to free; The bit flag is changed to the flag corresponding to the free memory block and inserted at the tail of the first free list of the SLUB allocator.

4. The memory block management method according to claim 3, characterized in that, The step of releasing the memory block and modifying the corresponding bit flag of the released memory block to free includes: The corresponding element number in the status flag array is determined based on the position order of the currently released memory block among all memory blocks within the specified memory size range; Determine the binary bits in the free field that correspond to the element's sequence number; Set the bit flag in the binary bits to the binary number corresponding to the idle state.

5. The memory block management method according to claim 3, characterized in that, This also includes before modifying the bit flag corresponding to the freed memory block to free: Based on the bit flags of the currently freed memory block in the SLUB allocator, determine whether the preceding and following bit flags adjacent to the bit flag of the currently freed memory block are both free. If all are free, then the step of releasing the memory block and modifying the bit flag corresponding to the released memory block to free; inserting the flag corresponding to the memory block whose bit flag has been changed to free into the tail of the first free list of the SLUB allocator includes: The currently freed memory block, along with the memory blocks whose previous and subsequent bit flags are displayed, are merged into a contiguous memory block. The bit flags of the contiguous memory block are updated in one instruction, and the flags of the contiguous memory block are inserted into the tail of the free list in one go.

6. The memory block management method according to claim 5, characterized in that, This also includes before modifying the bit flag corresponding to the freed memory block to free: Determine if the physical address of the currently released memory block has an adjacent memory block that is currently free; If it exists, merge the current memory block with the adjacent memory block into a new memory block, determine and modify the bit flags of the new memory block; Determine whether the new memory block exceeds the range of the memory size range. If so, insert the flag of the new memory block into the preset second free list.

7. The memory block management method according to claim 1, characterized in that, Also includes: If the first free list in the SLUB allocator is empty, a memory block is selected from the global free list for the current allocation request.

8. The memory block management method according to claim 6, characterized in that, Also includes: If the memory size of the target memory block in the current allocation request exceeds the memory size range and is less than the theoretical maximum memory block capacity of the second free list, then determine whether the second free list in the SLUB allocator is empty. If not, the target memory block is selected sequentially from the second free list of the SLUB allocator, and the target memory block is determined based on the target memory block's flag bit for the current allocation request; If the second free list in the SLUB allocator is empty, a memory block is selected from the global free list for the current allocation request.

9. A controller, characterized in that, The controller includes: The information acquisition module is used to acquire configuration files in the Linux kernel, parse the memory size range from the configuration files, determine the usage status of memory blocks within the memory size range, and set the usage status bit flag for each memory block. The matching and determination module is used to determine whether the memory size of the target memory block of the current allocation request is within the memory size range. If it is within the memory size range, it determines whether the first free list in the SLUB allocator is empty. The first free list is used to store the flag bits of memory blocks marked as free. The request processing module is used to, if not, sequentially select the target memory block's flag bit from the first free list of the SLUB allocator, determine the target memory block based on the flag bit of the target memory block, and use it for the current allocation request; The information acquisition module is specifically used to define a status flag array of type unsigned char. The address of the status flag array points to the free field in the struct page data structure. Each element of the status flag array serves as a bit flag, and each bit flag indicates the usage status of the memory block as free or occupied.

Images