Processing method of storage resource mapping table mtt, electronic device and storage medium

Abstract

The application provides a storage resource mapping table MTT processing method, electronic equipment and storage medium, relates to the MTT processing technical field, and comprises the following steps: all MRs corresponding to the same MTT entry quantity are classified into a category; a multi-level page table structure is constructed for each category of MTT; the virtual byte offset of a target MTT in a global mapping space is calculated according to a step parameter; the table item content in the table item index corresponding to the current level physical page is read; if the next level physical base address pointed by the table item content is invalid, a physical page is allocated from a DDR storage pool, and the starting physical base address of the allocated physical page is backfilled into the current table item; the starting physical base address of the last level physical page is added to the remaining byte offset reserved by the final truncation to obtain the actual storage address of the target MTT in the physical storage medium; and the application inhibits memory waste and significantly reduces the underlying memory fragmentation phenomenon caused by forced alignment.

Description

Technical Field

[0001] This invention relates to the field of MTT processing technology, and in particular to a method, electronic device, and storage medium for processing a storage resource mapping table (MTT). Background Technology

[0002] When managing address mapping of the Host Memory Region (MR) at the underlying storage device level, the system needs to maintain a Mapping Table (MTT) in the local on-chip or onboard DDR to record the address translation relationships of the MR. Conventional management methods typically employ the buddy system algorithm to manage a fixed-size MTT physical memory pool, using powers of 2 as the smallest partitioning granularity. This mechanism has problems when mapping the actual MR: since the MR size does not strictly correspond to power-of-2 boundaries, if the total number of bytes occupied by the MR's MTT slightly exceeds a certain power, the system is forced to round up to the next power, thus requesting and occupying twice the amount of contiguous memory space actually needed, resulting in a serious waste of underlying storage resources. Furthermore, because this mode requires the system to pre-allocate the entire memory pool during initialization, its allocation logic is disconnected from the actual runtime creation order of the MR, making it impossible to elastically expand and release memory as needed during runtime, ultimately leading to memory fragmentation. Summary of the Invention

[0003] To address the aforementioned technical problems, the technical solution adopted by this invention is as follows:

[0004] According to a first aspect of this application, a method for processing a Storage Resource Mapping Table (MTT) is provided, comprising:

[0005] Based on the capacity of the host-side memory region MR, determine the number of MTT entries required by the MR during address translation, group all MRs with the same number of MTT entries into one category, and set the logarithm of the product of the number of MTT entries in this category and the number of bytes occupied by each MTT entry as the step size parameter.

[0006] A multi-level page table structure is constructed for the MTT corresponding to each type of MR; each level of the multi-level page table structure consists of physical pages, and the table entries in the upper level physical page store the starting address of the lower level physical page;

[0007] In response to access to the target MTT, obtain the number of the target MR to which the target MTT belongs and the step size parameter corresponding to its category, and calculate the starting virtual byte offset of the MTT mapping table block of the target MR in the global mapping space based on the step size parameter.

[0008] Starting from the highest-level root physical page of the multi-level page table structure, traverse downwards level by level. Based on the preset shift amount of the current level physical page, extract the table entry index of the current level physical page from the initial virtual byte offset, and read the table entry content of the current level physical page corresponding to the table entry index.

[0009] If the next-level physical base address pointed to by the table entry is invalid, a physical page is allocated from the DDR memory pool, and the starting physical base address of the allocated physical page is filled back into the current table entry.

[0010] After reading the next level physical base address, the updated virtual byte offset is updated bit by bit using a mask of the same order as the current level physical page's preset shift amount. The used high bits are cleared, and the low bit offsets used only for addressing the next level are retained.

[0011] After traversing all levels of the multi-level page table structure, the starting physical base address of the last-level physical page is added to the offset of the remaining bytes reserved by the final truncation to obtain the actual storage address of the target MTT in the physical storage medium.

[0012] According to another aspect of this application, a non-transitory computer-readable storage medium is also provided, wherein at least one instruction or at least one program is stored in the storage medium, and the at least one instruction or at least one program is loaded and executed by a processor to implement the above-described storage resource mapping table (MTT) processing method.

[0013] According to another aspect of this application, an electronic device is also provided, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0014] The present invention has at least the following beneficial effects:

[0015] The storage resource mapping table (MTT) processing method of the present invention,

[0016] By classifying MapReduce (MRs) according to the required number of MTT entries, and using the logarithm of the product of the number of MTT entries in each category and the number of bytes occupied by a single MTT entry as the step size parameter, the displacement span of bitwise addressing is expanded from a single MTT to the complete mapping table unit corresponding to the MR. When calculating the global offset, the hardware can directly use the left shift step size parameter based on the MR number to locate the virtual offset to the global starting position of the target MR mapping table block in one go. In the subsequent multi-level page table traversal, the controller strips the current level index based on a preset shift amount and truncates the used high-order offsets using a same-order mask, retaining only the low-order remaining offsets for lower-level addressing. At the same time, the system only dynamically allocates physical pages from the DDR memory pool and fills the base address back into the current table entry when there is a physical page missing in the current access path. Since there is no need to pre-allocate contiguous memory for the entire mapping table space during system startup, this scheme allows the occupancy of the underlying physical memory to dynamically expand and shrink with the actual access range of the MR, thereby effectively suppressing memory space waste and underlying fragmentation caused by forced rounding and alignment. Attached Figure Description

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

[0018] Figure 1 A flowchart illustrating the processing method of the Storage Resource Mapping Table (MTT) provided in an embodiment of the present invention. Detailed Implementation

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

[0020] It should be noted that, based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Furthermore, this device and / or practice the method can be implemented using other structures and / or functionalities besides one or more of the aspects set forth herein.

[0021] The following will refer to Figure 1 The flowchart shown illustrates a method for processing a Storage Resource Mapping Table (MTT), introducing one such method.

[0022] The processing method for the storage resource mapping table MTT includes the following steps:

[0023] S100: Based on the capacity of the host-side memory region MR, determine the number of MTT entries required for address translation of MR, group all MRs with the same number of MTT entries into one category, and set the logarithm of the product of the number of MTT entries in this category and the number of bytes occupied by each MTT entry as the step size parameter.

[0024] In this embodiment, when receiving an MR registration request issued by the host end, the controller divides the capacity size of the MR by a single mapping granularity (for example, 4KB) in the host memory configuration, and calculates the total number of MTT entries required by the MR. Subsequently, all MRs with the same total number of MTT entry requirements are classified into one resource category, and the product of the number of MTT entries under this category and the number of bytes occupied by a single MTT entry is taken as the total byte size of a single MTT mapping unit corresponding to the MR. The controller further calculates the binary logarithm corresponding to the product as a step parameter (for example, if a single MTT under this category is 8 Byte and the total number of entries is 512, the product is 4096, and the step parameter is 12). This step parameter is directly solidified as the bit width reference of this resource category, and is used for subsequent whole mapping unit shifting based on the MR number as the radix.

[0025] The byte multiple is converted into the shift bit width through binary logarithm calculation, so that the algorithm can directly use an efficient shift instruction instead of a multiplication instruction in hardware, and the addressing latency is reduced.

[0026] Further, the step parameter is a logarithm value MR_GROUP_LOG corresponding to the total number of bytes MR_GROUP_SIZE occupied by a single MTT mapping unit under the corresponding MR classification; the MTT mapping unit is formed by consecutively arranging all MTT entries required by a single MR under the corresponding classification, and the number of MTT entries is determined after being aligned upward to a power of 2; the virtual byte offset OFFSET = MR_ID << MR_GROUP_LOG, where MR_ID is the consecutive number of the MR to which the target MTT belongs in the current classification logical space, and << is the logical left shift operator.

[0027] After the system completes the MR classification in S100 and determines the number of MTT entries required by a single MR under this classification (denoted as MTT_NUM), since the index bit width of the underlying physical page table and DDR addressing are both based on a power of 2, the firmware performs an upward alignment operation in the power-of-2 direction to align MTT_NUM to the nearest power of 2 (denoted as POW_MTT_NUM). Subsequently, the firmware calculates the product of POW_MTT_NUM under this classification and the number of bytes of a single MTT entry ENTRY_SIZE, to obtain the total number of bytes MR_GROUP_SIZE occupied by a single MTT mapping unit, that is, MR_GROUP_SIZE = POW_MTT_NUM × ENTRY_SIZE.

[0028] Subsequently, the firmware calculates the binary logarithm corresponding to the MR_GROUP_SIZE, takes it as the underlying step parameter MR_GROUP_LOG of this resource classification, and solidifies it in the configuration register of the hardware. The mathematical constraint relationship can be expressed as: .

[0029] During the S300 offset calculation phase, the controller's internal firmware retrieves the global logical sequential number MR_ID of the current target MR (this number represents which MR in the queue of this type of MR, not a specific MTT). The hardware logic unit directly calls a single-cycle logical left shift instruction (<<) to shift MR_ID left by MR_GROUP_LOG bits. The specific calculation formula is: OFFSET = MR_ID < <MR_GROUP_LOG。

[0030] For example, suppose the number of MTTs in a certain type of MapReduce (MR) is aligned upwards to 512, and a single MTT occupies 8 bytes (then MR_GROUP_SIZE is 4096 bytes, and MR_GROUP_LOG is fixed at 12). When the controller needs to access the target MR with MR_ID 3, the hardware directly executes 3<<12 (i.e., 3 multiplied by 4096), obtaining a virtual byte offset OFFSET=12288. Physically, this value indicates that the entire MTT mapping table corresponding to the target MR is located in the global mapping space, offset 12288 bytes from the starting address of the mapping area for that type. After this macroscopic positioning, the controller passes this offset to the subsequent multi-level page table traversal pipeline of the S400, and combines it with the local index of a single MTT within the MR to complete microscopic addressing in the next level traversal, ultimately locating the specific MTT entry.

[0031] In this embodiment, the total number of bytes of the MTT mapping unit of this type of MR is quantized into a binary logarithm as the step size reference, so that the addressing process from MR_ID to the starting position of the entire mapping table is completely simplified into a single clock cycle left shift instruction. Compared with traditional multiplication or large number accumulation operations, this single-cycle shift significantly reduces the instruction cycle overhead of the controller in the global offset initial calculation stage. At the same time, this method naturally ensures the power-law boundary alignment of the mapping table block at the physical page level, preventing cross-block misalignment in subsequent multi-level traversals.

[0032] S200, construct a multi-level page table structure for the MTT corresponding to each type of MR; each level of the multi-level page table structure is composed of physical pages, and the table entries in the upper level physical page store the starting address of the lower level physical page.

[0033] In this embodiment, within the DDR memory pool, the system constructs an independent N-level multi-level page table structure for each type of MR. The nodes of the page table structure consist of physical pages of a fixed size (e.g., 4KB). The logical relationship between entries within the page table is as follows: each entry in the parent physical page specifically stores the starting physical address of the DDR page in the next level (or child physical page). For example, for a 4KB physical page, if the entry size is 8 bytes, the page can contain a maximum of 512 entries, meaning the maximum number of branches at a single level is 512 (corresponding to a 9-bit index). This structure predefines the hierarchy depth only at the logical level; the physical layer page table is not allocated at this stage, but only provides an index skeleton for subsequent on-demand allocation.

[0034] The tree-like multi-level structure establishes the parent-child index relationship between physical pages. No matter how large the MR capacity is, the fixed-depth page table structure can quickly locate large-span mapping table blocks through hierarchical jumps.

[0035] Furthermore, the size of the physical page is 4KB; when the next-level physical base address pointed to by the table entry is invalid, the action of allocating a physical page from the DDR storage pool and backfilling the starting address of the table entry is triggered; this allocation and backfilling action is only performed when a physical page is missing in the current access path, and is not performed during the system initialization phase, which involves pre-allocating the entire multi-level page table space to which the target MR belongs.

[0036] In this embodiment, in the hardware controller (such as an NVMe controller or a DPU chip), since the host-side memory access and the controller's internal DMA transfer are usually aligned to a minimum unit of 4KB, and the number of entries that a single-level physical page table can hold (e.g., 4KB / 8Byte = 512 entries) also happens to be a power of 2, this embodiment strictly fixes the allocation granularity of the underlying physical pages to 4KB.

[0037] During subsequent execution, the controller is designed with a physical address validity determination circuit. When the firmware reads the entry content in the corresponding table index of the current physical page, it will hand it over to the hardware logic for verification. If the read entry value is all 0s (or meets the preset invalid bit flag, such as the highest bit being 0), it is determined that "the physical base address is invalid".

[0038] At this point, the hardware addressing pipeline pauses the current access task and triggers the firmware's internal exception handling mechanism via a hardware signal. The memory pool management module in the firmware (based on the underlying DDR free list) responds to this signal, allocating a contiguous 4KB physical memory segment from the free blocks of the DDR memory pool. After obtaining the DDR starting base address of this 4KB physical memory, the firmware initiates a hardware write-back instruction, immediately writing the newly allocated physical address to the DDR location of the current parent page table entry, completing the physical page backfilling and mapping anchoring.

[0039] This "allocation and backfilling" action has strict limitations in terms of time: it is only triggered when a physical page is missing for the first time on the current addressing path. Once backfilling is complete, the entry has a valid physical address, and any subsequent request to access the MTT belonging to that path can directly hit that physical page without reallocation.

[0040] Unlike traditional designs that require all MTT space for MRs to be allocated in advance during the initialization phase, this embodiment only configures and locks the physical address of the top-level root page table (Root PageTable) for various MRs during the entire system power-on startup phase. The system does not pre-allocate massive amounts of 4KB physical pages at the underlying level based on the size of the MR.

[0041] For example, if a certain type of MapReduce logically requires a large amount of mapping space (such as 1TB+1B), but the actual host access is only concentrated in a very small data area, then this embodiment can meet the access requirements by allocating 2-3 levels of physical pages totaling several 4KB on the corresponding data path, without having to allocate all the memory corresponding to the complete mapping space required by the MapReduce at once as in conventional algorithms.

[0042] By allocating physical memory only when a physical page fault first occurs, the waste of DDR physical memory caused by forced rounding up (e.g., allocating 2TB of mapping space for 1TB+1B) is completely prevented. The allocation of underlying physical pages is limited only by the number and coverage of "page faults" triggered by actual host access, giving the space occupied by multi-level page tables on physical DDR a flexible and elastic scaling capability.

[0043] S300, in response to access to the target MTT, obtains the number of the target MR to which the target MTT belongs and the step size parameter corresponding to its category, and calculates the starting virtual byte offset of the MTT mapping table block of the target MR in the global mapping space based on the step size parameter.

[0044] In this embodiment, within the storage controller or DPU running this method, when the hardware parsing engine receives a read / write command from the host (such as NVMe SGL disassembly or DMA data transfer task), if the command hits a registered MR, the controller firmware will first locate the control block corresponding to that MR. In the control block, the firmware directly reads the unique logical number assigned to the MR (denoted as MR_ID). Simultaneously, through the category index table defined in step S100, the hardware state machine or firmware obtains the step size parameter (MR_GROUP_LOG) corresponding to the MR category.

[0045] At the actual logic operation level, the arithmetic logic unit embedded in the controller does not perform time-consuming multiplication operations. Instead, it directly calls the preset MR_GROUP_LOG parameter and executes a single-clock-cycle logical left shift instruction between MR_ID and that parameter: virtual byte offset OFFSET = MR_ID < <MR_GROUP_LOG。

[0046] For example: if in step S100 the MR is classified as a single MR containing 512 MTT entries (and 512 is up-aligned to powers of 2), and each MTT entry occupies 8 bytes, then the total size of the MTT mapping table block corresponding to this type of MR is 4096 bytes (512 × 8), and the corresponding step size parameter MR_GROUP_LOG is set to 12 (i.e., 2...). 12 =4096). When the controller needs to access the target MR numbered 1000 under this category, the hardware directly performs a left shift of 1000 by 12 bits (equivalent to multiplying by 4096), resulting in a relative starting byte offset of 4096000 for the entire mapping table block corresponding to this MR in the global mapping space. After obtaining the starting offset of this macroblock, further addressing will be performed by combining the single MTT local index inside the MR.

[0047] The calculated OFFSET value will be used as the "initial byte offset" in subsequent steps S400 to S700 and input into the multi-level page table's hierarchical index calculation pipeline. This is used to peel off the high-order index from top to bottom, enabling the hardware to seamlessly transition from macroblock jumps to single MTT physical page positioning.

[0048] By directly quantizing the MTT mapping table block size into a binary bit width (logarithmic) parameter, this scheme completely transforms the cross-MR block jump calculation, which originally required large number multiplication, into a single-cycle left shift instruction that can be completed in the hardware circuit. This not only significantly reduces the execution cycle of global offset address calculation and effectively reduces the first addressing latency of front-end data requests, but also naturally ensures the physical page boundary alignment of the mapping table block.

[0049] S400 traverses down the multi-level page table structure from the highest-level root physical page. Based on the preset shift amount of the current-level physical page, it extracts the table entry index of the current-level physical page from the initial virtual byte offset and reads the table entry content of the current-level physical page corresponding to the table entry index.

[0050] In this embodiment, the system starts from the top-level root physical page of the category (fixed in a preset global entry register) and, combined with the hierarchical depth constructed in step S200, enters a loop of traversing downwards level by level. For the current level, the algorithm reads the preset shift amount (SHIFT[level]) for that level, which is obtained by superimposing the step size parameter of the category and the index bit width of the current level and all levels below it, wherein:

[0051] SHIFT[level]=MR_GROUP_LOG+level×PAGE_INDEX_BITS);

[0052] Then execute the current level index = virtual byte offset >> SHIFT[level].

[0053] For example: If the logarithm MR_GROUP_LOG corresponding to the total size of a single MR mapping table block under the current category is 12 (for example, the MR contains 512 entries and each entry occupies 8 bytes, with a total block size of 4096 bytes), and the single-level physical page table entry index bit width PAGE_INDEX_BITS is 9, then the preset shift amount SHIFT[0] of the last-level physical page (Level0) is equal to 12; the preset shift amount SHIFT[1] of the next level (Level1) is equal to 21; and the preset shift amount SHIFT[2] of the highest level (Level2) is equal to 30. The value obtained after performing the corresponding shift is the specific table entry index of the mapping table block corresponding to the MR in the corresponding level physical page table of the multi-level page table. The controller reads the table entry content in the current physical page based on this offset.

[0054] By using a preset shift amount, the global offset is directly divided into the indexes required by each level of page table, avoiding the traditional address splitting and parsing operations and improving hardware traversal efficiency.

[0055] Further, the preset shift amount of the current-level physical page is SHIFT[level]=MR_GROUP_LOG+level×PAGE_INDEX_BITS; where MR_GROUP_LOG is the step parameter, PAGE_INDEX_BITS is the bit width of the single-level physical page table entry index, and level is the level index value incrementing upward from the lowest level of the multi-level page table structure; the current-level entry index level_offset=OFFSET>>SHIFT[level]; OFFSET is the remaining byte offset after truncation at the current stage; the mask MASK[level]=(1<<SHIFT[level])-1; the formula for bitwise truncation update is: OFFSET=OFFSET&MASK[level]; & is the bitwise AND operator.

[0056] In this embodiment, in the hardware logic (S400 to S600) for step-by-step traversal of the multi-level page table, the controller needs to use the preset shift amount corresponding to the current traversal level to split the virtual byte offset into the entry index of each level. To achieve this goal, the system firmware pre-calculates and solidifies a shift amount array SHIFT[level] when initializing various types of multi-level page tables. The definition formula of this array is: SHIFT[level]=MR_GROUP_LOG+level×PAGE_INDEX_BITS.

[0057] Wherein, MR_GROUP_LOG is the step parameter set in S100, which represents the binary logarithm corresponding to the total size of a single MR mapping table block under the current MR classification (that is, the total number of MTT entries multiplied by the number of bytes occupied by a single MTT entry, and the total number of bytes after being upward aligned to a power of 2). If a single MTT entry in this category is 8Byte and the number of MTT entries is 512 (already aligned), the total size is 4096B, and MR_GROUP_LOG is fixed at 12. PAGE_INDEX_BITS is the bit width of the single-level physical page table entry index (for example, if 512 8B entries can be accommodated inside a 4KB physical page, PAGE_INDEX_BITS is fixed at 9); level is the index of the current level, and its definition rule is to increment upward starting from the last-level physical page (leaf node), where the last level is set to 0, its upper level is set to 1, and the highest level is set to N-1. Under this setting, the shift amount of the last level (level=0) is equal to MR_GROUP_LOG, and the shift amount value increases as the level goes higher, ensuring that the highest-level index can extract the highest bit of the offset of the MR mapping table block.

[0058] During the process in which the controller traverses downward from the highest level, a shift operation for extracting the entry index is performed for the current level: level_offset=OFFSET>>SHIFT[level]. Here, OFFSET is the byte offset remaining after the previous levels of mask truncation in the current phase (the initial value is the global virtual byte offset calculated in S300). This right shift operation directly moves the high-order bits representing the current level index in OFFSET to the low-order bits.

[0059] For example, assume that MR_GROUP_LOG is 12, and the physical page table index bit width PAGE_INDEX_BITS is 9. Then SHIFT[0]=12, SHIFT[1]=21, and SHIFT[2]=30. If the global offset OFFSET at the start of a certain traversal is right-shifted by 30 bits at the highest level (level=2) to extract the entry index of this level, and after the entry is read to point to the next-level physical page, the controller needs to clear the highest-level index bits that have been used.

[0060] The controller calculates the mask MASK[level] of the same order according to the current level shift amount: MASK[level]=(1<<SHIFT[level])-1. In binary bits, this mask is represented as all low SHIFT[level] bits being 1, and all higher bits being 0. Then the bitwise AND operation is performed: OFFSET=OFFSET&MASK[level]. For example, if SHIFT[2] of the highest level has just been processed, the low 30 bits of the mask MASK[2] are 1. After the bitwise AND operation, all data above the high 30 bits are cleared, and OFFSET is updated to a value that only includes bits within the low 30 bits. This new OFFSET will be directly used for index extraction of the next level (level=1), and so on, until it finally descends level by level to the last-level physical page.

[0061] Through the two bit-width-based coupling variables SHIFT and MASK, the controller can quickly strip the traversed high-order indices using single-cycle shift and bitwise AND instructions without maintaining any complex counters or performing conditional judgments. This ensures that in complex multi-level addressing, the offset truncation operation at each level is monotonic and branch-free, which greatly reduces power consumption loss and delay fluctuation of the hardware pipeline caused by branch prediction failures.

[0062] S500: If the next-level physical base address pointed to by the entry content is invalid, a physical page is allocated from the DDR storage pool, and the starting physical base address of the allocated physical page is written back to the current entry.

[0063] In this embodiment, after the controller enters step S400 to read the table entry content from the current level physical page, it will perform a validity check on the data of the table entry within the same instruction cycle executed by the hardware state machine or firmware. The physical implementation of this check is usually to check whether the table entry address field is equal to a preset invalid flag (e.g., all zeros in binary, or the highest bit is a reserved invalid flag). If the check result is "valid", this step is skipped directly, and the physical base address is sent to the S600 pipeline; if the check result is "invalid", the hardware addressing operation will be immediately suspended, and a "page fault allocation" request will be distributed to the microcode processing unit or DDR memory management hardware inside the controller.

[0064] Upon receiving the request, the memory management hardware retrieves the head node from a pre-initialized linked list of free DDR physical pages (which typically manages 4KB fixed-size physical memory blocks), completes a physical page fetch and allocation, and returns the starting physical address of that physical page in DDR memory. To support high-concurrency access, this fetching operation usually involves atomic compare-and-swap (CAS) or spinlock protection to prevent address overlap when multiple cores / channels allocate memory simultaneously.

[0065] After obtaining the starting base address of the newly allocated physical page, the controller must immediately perform an "entry backfill" operation. The specific process is as follows: the controller constructs a write request, using the newly obtained starting base address of the physical page as the data payload, and writes it to the DDR location of the corresponding entry index (level_offset) in the current level physical page. This backfill operation must strictly guarantee the write order and persistence. Typically, the hardware will use a write buffer or direct memory access (DMA) to quickly flush the 4-byte or 8-byte entry data back to the DDR storage medium.

[0066] For example: Suppose that an addressing path has an entry index of L at the current level. The controller reads the entry's content as 0x0000_0000 and determines it to be invalid. It then requests a 4KB physical page from the DDR pool with a starting address of 0xA000_0000. The controller then performs a DDR write operation, filling 0xA000_0000 back into the current physical page offset L×8 bytes. After this backfilling, the page fault path is successfully anchored.

[0067] This mechanism compresses the "time and space overhead" of physical page allocation to the moment when a specific access path is first missing. This makes the physical DDR capacity occupied by multi-level page tables strictly equivalent to the logical range of the current actual access hit, completely eliminating the need for blind memory allocation of massive MRs during system startup, and fundamentally eradicating the memory space waste caused by power-order alignment.

[0068] After reading the next-level physical base address, S600 uses a mask of the same order as the preset shift amount of the current physical page to perform a bitwise truncation update on the updated virtual byte offset, clearing the used high bits and retaining the low bit offset that is only used for addressing the next level.

[0069] In this embodiment, after the S500 determination and obtaining the next-level physical base address, the controller needs to immediately perform a "bit stripping" operation on the offset to clean up the variables used for addressing the next level. In actual hardware logic circuits or microcode execution engines, this step includes two parallel or sequential sub-actions: mask generation and bit-by-bit truncation.

[0070] Mask generation level: The calculation unit within the controller generates a mask of the same order based on the shift amount SHIFT[level] corresponding to the current level, using shift and subtraction instructions. The calculation formula is MASK[level] = (1 < ... <SHIFT[level])-1。

[0071] In the binary representation, bits 0 through SHIFT[level]-1 are all "1", and all higher bits are "0". Combining this with the relationship SHIFT[level] = MR_GROUP_LOG + level × PAGE_INDEX_BITS in step S400, the "1"s in the lower bits of this mask precisely cover the logarithm of the total byte width of the MR mapping table block under the current category, MR_GROUP_LOG, as well as the total index bit width of the current level and all lower levels below it.

[0072] Bitwise execution level: After obtaining the mask, the controller hardware logic directly performs a single-cycle bitwise AND operation (&) on the current virtual byte offset (OFFSET). This operation aligns the current OFFSET value in the register with the MASK[level] and performs a logical AND operation. The result of the bitwise AND is either written directly back to the same OFFSET register or forwarded to the input register of the next addressing pipeline.

[0073] For example: Under the case setting of continuing step S400, assuming that the logarithm of the total size of a single MR mapping table block in the current category is MR_GROUP_LOG, and the page table index bit width is 9. Then the highest level SHIFT[2]=12+2×9=30, SHIFT[1]=21, SHIFT[0]=12. After processing the highest level (level=2) and successfully reading the next level base address, the controller immediately generates MASK[2]=(1<<30)-1 (that is, a mask with all lower 30 bits set to 1). Assume that the current binary value stored in the OFFSET register is 0x8123456789. The controller executes 0x8123456789&0x3FFFFFFF. Since the high bits (30th bit and above) of 0x8123456789 are forcibly cleared in the bitwise AND operation, the OFFSET register value is updated to a value containing only the lower 30 bits. This value is then used as a new virtual byte offset and flows into the next level addressing loop of level=1. The corresponding table entry index is extracted by shifting SHIFT[1]=21, and so on until the last level.

[0074] By employing a fixed-width mask bitwise AND operation, the offset "high-bit stripping" task in the multi-level addressing process can be completed within a single clock cycle. This mechanism avoids the logical blocking caused by using division or modulo instructions. Combined with subsequent shift loops, it ensures that the pipeline for the entire multi-level page table traversal process is always in a branchless, continuous running state, significantly reducing the clock cycle overhead of hardware addressing.

[0075] S700, after traversing all levels of the multi-level page table structure, adds the starting physical base address of the last-level physical page to the offset of the remaining bytes reserved by the final truncation, and obtains the actual storage address of the target MTT in the physical storage medium.

[0076] In this embodiment, in the multi-level page table traversal pipeline, when the level counter (level) decreases level by level according to the loop logic of steps S400 to S600 until it falls below 0, the hardware control logic determines that the traversal process has ended. At this time, the physical address (level_addr) held in the current addressing register has undergone N level-by-level jumps and is finally locked as the DDR starting physical base address of the last-level physical page (leaf node).

[0077] Meanwhile, the initial OFFSET value has been cropped to the lowest MR_GROUP_LOG bits after right-shift extraction by SHIFT[level] at each level and bitwise truncation by MASK[level]. Since the initial OFFSET calculated in S300 is strictly equal to the MR number left-shift step parameter (i.e., OFFSET=MR_ID<<MR_GROUP_LOG), its lowest MR_GROUP_LOG bits are always 0 in binary representation. Therefore, the remaining byte offset OFFSET_final finally retained after traversing level by level in the loop is necessarily 0. Physically, this offset represents the starting relative offset of the entire MTT mapping table block corresponding to the target MR within the last-level physical page to which it belongs.

[0078] When performing final positioning, the address addition unit inside the controller directly performs hardware-level addition operation on the two aforementioned values: the actual physical address of the target MTT = the starting base address of the last-level physical page + 0. In the specific chip circuit implementation, this addition can be directly completed by the address splicing logic, which is equivalent to directly taking the starting base address of the last-level physical page as the physical storage address of the first MTT entry in the target MR mapping table block. For example: assuming that after level-by-level jump of the three-level page table, the reading value of the starting base address register of the last-level physical page is 0xA000_0000. Since the final remaining offset OFFSET_final is necessarily 0, after the addition operation, the controller obtains that the physical base address of the target MR mapping table block is 0xA000_0000. Since all MTT entries corresponding to this MR are sequentially and continuously arranged in this last-level physical page, the continuous data area starting from this base address constitutes the mapping table block of the target MR (for example, a 4KB physical page that can accommodate 512 MTT entries). The controller can then directly access a specific MTT entry under this MR according to the physical base address in combination with the specific MTT local index inside the MR (the in-page offset generated based on the byte size of a single MTT).

[0079] When the traversal to the end is completed, a single addition or address splicing can determine the physical starting base address of the target MR mapping table block. Since this base address is located at the starting boundary of the 4KB physical page, accessing a specific entry in the mapping table block corresponding to this MR will not cause cross-page read / write overflow at all, which ensures the addressing closure and alignment of the underlying DDR access.

[0080] In an exemplary embodiment, the method further comprises:

[0081] Establishing a hierarchical bitmap structure for the MTT corresponding to each type of MR; in the hierarchical bitmap structure, a single bit in the upper-level sub-bitmap is used to indicate whether there is an MTT number ID in an idle state in the bitmap group of the corresponding lower-level sub-bitmap.

[0082] In this embodiment, during system firmware startup or the initialization phase of various MR categories, the controller allocates an independent hierarchical bitmap management area for each resource category. This hierarchical bitmap is not a single large array, but adopts a multi-level nested bitmap structure. In specific implementation, the bottom-level (leaf level) bitmap is usually divided into a bitmap group with a fixed number of bits (e.g., 64 bits), and each bit in this group directly maps to a specific MTT number ID (a bit of 0 indicates idle, and a bit of 1 indicates allocated).

[0083] Above this structure, adjacent parent-level sub-bitmaps consist of only a small number of bits, with each bit corresponding one-to-one with the next-level bitmap group. The mapping rule is as follows: specific bits in the parent-level sub-bitmap are used to indicate whether the corresponding next-level bitmap group currently has "free IDs". For example, if all 64 ID bits in the next-level bitmap group are set to 1 (i.e., all have been allocated), then the corresponding parent bit in the parent-level group will be set to 1 (indicating that the group is full); conversely, if even one ID bit in the next-level bitmap group is 0, then the parent bit will remain 0 (indicating that the group has free IDs).

[0084] In physical implementation, this structure typically uses a fixed-size DDR array for contiguous storage. To reduce hardware concurrency conflicts, bitmap group updates often employ atomic compare-and-swap (CAS) instructions that support multiple levels. During the initialization phase, the hierarchical bitmap allocates only a small amount of physical memory to the root node (top level), and the next level bitmap group is not pre-allocated; instead, when the MTT ID is allocated for the first time, a complete bitmap group (e.g., 8 bytes corresponding to 64 bits) is requested from the DDR memory pool as needed, and its physical address is anchored to the corresponding index of the parent bitmap, forming a dynamically expanding tree-like bitmap structure.

[0085] For example, suppose a hierarchical bitmap of a certain type of MR is divided into 3 levels. The bottom bitmap group is 64 bits. If there is a bottom bitmap group (group 0 in the figure) that has not yet been assigned any IDs (all 0s), the 0th bit in its corresponding upper-level bitmap is 0. When the system needs to assign IDs, the hardware scans the top-level bitmap, finds that the 0th bit is 0, and directly jumps to the bottom bit 0, using a hardware bit scan instruction (such as find-first-zero) to quickly locate the first free bit and set it to 1. If all 64 bits of the bottom bit 0 are eventually filled, the hardware will actively flip the 0th bit of the upper-level bitmap to 1. When subsequent ID allocations are scanned again at the top level, since the 0th bit of the top level has become 1, the hardware will determine that the group is full, ignore it, and continue scanning subsequent bits, thus skipping the scanning process of these 64 IDs.

[0086] By establishing a mapping mechanism between higher-level bits and the idle states of lower-level bitmap groups, the ID allocation process avoids the inefficient action of traversing the entire large bitmap byte by byte. When allocating IDs, the hardware only needs to scan a very small number of bytes in the top-level bitmap to quickly determine which lower-level bitmap groups still have idle bits, achieving skip-addressing and extremely low allocation latency in massive ID management scenarios. At the same time, the on-demand allocation design of bitmap groups also avoids blind full pre-occupancy of bitmap memory during the initialization phase.

[0087] Furthermore, the method also includes a step of allocating MTT IDs through the hierarchical bitmap structure:

[0088] Starting from the highest level of the hierarchical bitmap structure, scan downwards level by level to obtain the high-level index H_IDX ​​corresponding to the free bit in the current level bitmap; locate the intermediate level bitmap group based on H_IDX ​​to obtain the intermediate level index M_IDX, and continue to locate the lowest level bitmap group to obtain the lowest level index L_IDX.

[0089] The target MTT ID is obtained by assembling the indexes at each level according to the following formula:

[0090] ID=(H_IDX<<(P_BITS×2))|(M_IDX< <P_BITS)|L_IDX;

[0091] Where << is the bitwise left shift operator, | is the bitwise OR operator, and P_BITS is the binary power corresponding to the number of bits in the lowest-level bitmap group.

[0092] In this embodiment, the controller firmware first loads the physical base address of the highest-level sub-bitmap of the current class into a general-purpose register. The firmware calls the underlying hardware bit scan instruction (such as CTZ, which calculates the number of trailing zeros, or ffs, which finds the first set bit) to directly scan the data bits (e.g., 64 bits) of the current level bitmap. Once a bit is found to be 0 (indicating the presence of a free ID within the group), the firmware records the bit order of that bit in the current level as the high-order index H_IDX.

[0093] Subsequently, using H_IDX ​​as the offset, the controller calculates the physical base address of the intermediate-level bitmap group in DDR and performs the same bit scan operation again to extract the index M_IDX of the intermediate-level free bits. Next, based on M_IDX, it jumps to the lowest-level (lowest-level) bitmap group, scans and extracts the lowest-level free bit index L_IDX within the lowest-level bitmap group. After determining L_IDX, the firmware must immediately set the corresponding bit of L_IDX in the lowest-level bitmap group to 1 to complete the physical preemption of this ID; if all 64 bits in the lowest-level bitmap group have already been set to 1, it is necessary to backtrack and update the corresponding parent indicator bits of the intermediate and highest levels to 1 to indicate that the ID group is full.

[0094] After completing the three-level index extraction, the firmware performs bit assembly for numbering according to the specification parameter P_BITS of the underlying bitmap group. P_BITS is physically defined as the binary power corresponding to the number of bits in a single underlying bitmap group (for example, if the underlying bitmap group fixedly uses 64 bits, P_BITS is 6).

[0095] The final assembly formula for the MTT number ID is: ID=(H_IDX<<(P_BITS×2))|(M_IDX<<P_BITS)|L_IDX. In this logic, H_IDX<<(P_BITS×2) directly shifts the high-level index left to the highest bit segment of the global ID (equivalent to skipping 2 P_BITS ×2 P_BITS IDs); M_IDX<<P_BITS shifts the middle index left to the middle bit segment of the global ID; L_IDX is directly filled into the low bit segment. The three segments of data are superimposed and merged through the bitwise OR operation | to form a complete, continuous and non-overlapping MTT number ID.

[0096] For example, assuming that this embodiment adopts a 3-layer bitmap, and each underlying group contains 64 bits, then P_BITS is 6. Three bitmap allocation requests of the current category are processed simultaneously. The hardware scans the first-layer bitmap to obtain H_IDX=1, scans the corresponding middle-layer bitmap to obtain M_IDX=2, and scans the corresponding underlying bitmap group to obtain L_IDX=5.

[0097] Substituting into the formula for calculation: ID=(1<<(6×2))|(2<<6)|5=(1<<12)|128|5=4096+128+5=4229.

[0098] Thus, the system successfully calculates the MTT ID with the logical number 4229 for the current allocation operation.

[0099] By performing hierarchical segmentation on the large bitmap and converging the bit scan to a local space of a single group of 64 bits, the allocation operation only executes three tiny bit scan and shift operations at the hardware level, which completely avoids the full traversal of the continuous DDR space during massive MTT allocation. The simple bitwise left shift and bitwise OR operations in the formula ensure extremely low latency when the firmware synthesizes the final ID, effectively improving the processing throughput of the resource application link in the I / O path.

[0100] Further, the method further comprises: a step of reclaiming the MTT number ID by using the hierarchical bitmap structure:

[0101] The recycling of MTT IDs is typically triggered on the host side after releasing the corresponding MR or after the controller completes a specific I / O transfer task. In a multi-level bitmap structure, the parent node bits of each level bitmap do not blindly record the number of child node allocations, but rather record the "full load state" of the child bitmap group. Therefore, the core engineering logic for ID release is to atomically clear the underlying occupied bits and reversely determine whether a "full load to idle" state transition has been triggered, thereby unlocking the parent node bits level by level.

[0102] After releasing the target MTT ID, set the corresponding bit of L_IDX in the lowest-level bitmap group to zero.

[0103] After receiving a specific target ID to be reclaimed, the firmware performs an inverse operation to split and restore the ID into L_IDX. The controller then calculates the physical base address of the lowest-level bitmap group corresponding to this ID in DDR, and uses L_IDX as an offset to initiate a write operation to this DDR address, forcibly setting the corresponding bits to 0 (physically implemented as an atomic bitwise AND operation, such as the BIT_CLEAR instruction). After the zeroing operation is completed, the firmware immediately reads the 64 bits of data of the current underlying bitmap group and executes an all-zero determination instruction. If the determination result is not all zeros (other IDs in the group are still occupied), the backtracking process terminates immediately; if the determination result is all zeros (indicating that the group is completely unoccupied), it proceeds to the next stage.

[0104] Determine if all bits in the current lowest-level bitmap group are in a zero state. If so, backtrack to the next higher level and set the corresponding M_IDX indicator bit in the intermediate-level bitmap group to zero.

[0105] Since the underlying group has been determined to be in an all-zero state, the controller must refresh the parent indicator bit; otherwise, the system will not be able to detect that the underlying group has returned to an idle state. The firmware calculates the physical DDR address of the corresponding parent bit in the intermediate level based on the M_IDX reconstructed from the original ID, and also performs a bit-zeroing operation. After writing, the firmware must perform an all-zero check on the entire bitmap group (also 64 bits) to which the current intermediate level parent bit belongs. If there are other underlying groups in this intermediate level group that are occupied, the backtracking stops here, retaining the 1 state of the parent bit of this intermediate group; if the intermediate level bitmap group is also determined to be all zero, the backtracking continues upwards.

[0106] Determine if all bits in the intermediate bitmap group are in a zero state. If so, continue backtracking to the highest level and set the H_IDX ​​indicator bit in the highest level bitmap to zero.

[0107] Following the all-zero determination result from Phase 2, the controller shifts the backtracking focus to the highest-level (top-level) bitmap. The firmware calculates the position of the corresponding bit at the top level based on H_IDX ​​and performs a zeroing operation. Since there are no higher-level structures at the top level, the recycling process ends after the zeroing operation is completed. The entire process ensures accurate synchronization of the state from bottom to top.

[0108] For example: Suppose the current controller receives a release request and needs to release the MTT with ID number 4229.

[0109] The firmware was deduced from 4229 to have H_IDX=1, M_IDX=2, and L_IDX=5.

[0110] First, the 5th bit in the underlying bitmap group is set to zero. The firmware reads the current data of this underlying bitmap group (for example, if 2 bits in the bitmap group were originally occupied, after clearing the 5th bit, the 7th bit is still occupied, and the group data is not all 0s). Since it is not all 0s, the release at this level is complete, and backtracking stops immediately.

[0111] If the 7th bit, the only one in that group, is subsequently released, the underlying group data becomes all zeros. The firmware will then trigger a backtracking process, moving the parent indicator bit corresponding to M_IDX=2 to 0 in the intermediate bitmap group and determining if the intermediate group is all zeros. This process continues until the top layer.

[0112] Through a rigorous underlying all-zero check and an upward step-by-step backtracking mechanism, the multi-level bitmap structure can maintain real-time consistency of "parent node bit indicating child group idle state" with minimal computational cost. This on-demand cascading state clearing logic ensures that after the system has undergone frequent allocation and release of a large number of random IDs, the bitmap structure will not experience a "pseudo-fullness" phenomenon due to delayed updates of parent nodes (i.e., the underlying layer clearly has empty slots, but the parent node shows as full), thus ensuring the long-term stability and accuracy of the ID allocation mechanism.

[0113] Furthermore, in the hierarchical bitmap structure, the bit mapping relationship between adjacent levels is expanded by a fixed power multiple; in the lowest-level sub-bitmap, it is expanded by 2... P_BITS Each bit is divided into a bitmap group, and each bit in the upper-level sub-bitmap corresponds to the idle state of a bitmap group in the lowest-level sub-bitmap.

[0114] In the specific physical implementation of the multi-level bitmap structure, the size of the bottom-level bitmap group is not arbitrarily set, but is strictly limited by the register width of the hardware access interface. In actual hardware design, the status register used for bit operations inside the controller (such as the DPU or memory master controller) is typically 64 bits wide. Therefore, in this embodiment, the granularity of the bottom-level bitmap group is fixed at 2. P _BITSP_BITS is a number of bits, where P_BITS corresponds to the binary power of the bit width of the bitmap group (for example, P_BITS is 6 for 64 bits).

[0115] In the mapping logic of hierarchical bitmaps, the mapping relationship between adjacent levels exhibits a strict "power-law multiplication" characteristic and forms a tree structure with full coverage. Specifically, in the lowest-level sub-bitmap, every 2... P_BITS Each bit is fixed into a physical bitmap group. The 2 bits within this group... P_BITS Each bit uniquely maps to a physical MTT ID (a bit value of 0 indicates idle, and 1 indicates occupied). Above this underlying physical bitmap group, a single bit in the parent child bitmap is specifically used to mark the "global idle state within the group" of this underlying bitmap group.

[0116] Its physical mapping rule is: the Nth bit in the parent child bitmap is always anchored to the Nth bit in the bottom child bitmap. P_BITS Bitmap groups. The state of the parent bit is updated in real time based on the occupancy of the lower-level bitmap groups: if all 2 bits in the Nth bitmap group at the bottom level are filled... P_BITS If all bits are 1 (meaning all IDs in the group have been allocated and there are no empty bits available for allocation), then the Nth bit of the parent is set to 1 by the hardware firmware (indicating that the group is full); conversely, if any bit in the underlying bitmap group is 0 (meaning there is an empty ID), the corresponding bit of the parent will be kept or updated to 0 (indicating that there is still space in the group).

[0117] In DDR physical memory arrangement, when calculating the physical offset address of the next-level bitmap, the firmware directly uses the parent index value shifted left by P_BITS bits (i.e., multiplied by 2). P_BITS By using this method, the storage address of the next level corresponding bitmap group in DDR can be accurately located without maintaining an additional mapping table.

[0118] For example: Assume the underlying physical bitmap group uses 64 bits (P_BITS=6). The 10th bit in the intermediate bitmap register always physically corresponds to the idle state indicator of the 10th 64-bit bitmap group at the underlying level. If at least one MTT ID in the 10th group at the underlying level is in an unallocated idle state (i.e., there is 0 in the group), then the 10th bit in the intermediate level is always 0; the 10th bit in the intermediate level only flips to 1 when all 64 bits of the 10th group at the underlying level are allocated to 1 by the application (fully loaded).

[0119] By strictly adhering to a fixed index mapping relationship that expands exponentially, the system does not require additional hash tables or search algorithms during initialization. When the firmware or hardware jumps to the next level bitmap group based on the parent index, it only needs to use a single bit shift operation to calculate the physical address of the next level, making the entire bitmap structure present a continuous logical characteristic in DDR with extremely fast random access capabilities.

[0120] Furthermore, although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0121] Embodiments of the present invention also provide a non-transitory computer-readable storage medium that can be disposed in an electronic device to store at least one instruction or at least one program related to implementing a method in the method embodiments, wherein the at least one instruction or the at least one program is loaded and executed by the processor to implement the method provided in the above embodiments.

[0122] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0123] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0124] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0125] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0126] Embodiments of the present invention also provide an electronic device, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0127] The electronic device is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments in this application.

[0128] Electronic devices are manifested in the form of general-purpose computing devices. Components of an electronic device may include, but are not limited to: at least one processor, at least one memory, and a bus connecting different system components (including memory and processor).

[0129] The memory stores program code that can be executed by the processor, causing the processor to perform the steps in the various embodiments described in this specification.

[0130] The memory may include readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory, and may further include read-only memory (ROM).

[0131] The memory may also include programs / utilities having a set (at least one) of program modules, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0132] A bus can represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus that uses any of the various bus structures.

[0133] Electronic devices can also communicate with one or more external devices (e.g., keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable user interaction with the electronic device, and / or any device that enables the electronic device to communicate with one or more other computing devices (e.g., routers, modems, etc.). This communication can be achieved through input / output (I / O) interfaces. Furthermore, electronic devices can communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via network adapters. The network adapter communicates with other modules of the electronic device via a bus. It should be understood that other hardware and / or software modules can be used in conjunction with the electronic device, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0134] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0135] Embodiments of the present invention also provide a computer program product including program code, which, when the program product is run on an electronic device, causes the electronic device to perform the steps of the methods described above in various exemplary embodiments of the present invention.

[0136] While specific embodiments of the invention have been described in detail by way of examples, those skilled in the art should understand that the examples are for illustrative purposes only and are not intended to limit the scope of the invention. Those skilled in the art should also understand that various modifications can be made to the embodiments without departing from the scope and spirit of the invention.

Claims

1. A method for processing a Storage Resource Mapping Table (MTT), characterized in that, comprising: determining the number of MTT entries required for address translation of the memory region MR according to the capacity size of the MR at the host end, classifying all MRs corresponding to the same number of MTT entries into one category, and setting the logarithm of the product of the number of MTT entries under the category and the number of bytes occupied by each MTT entry as a step parameter; constructing a multi-level page table structure for the MTT corresponding to each category of MR; each level of the multi-level page table structure is composed of physical pages, and the entries in the upper-level physical page store the start addresses of the lower-level physical pages; in response to an access to a target MTT, acquiring the number of the target MR to which the target MTT belongs and the step parameter corresponding to the category it belongs to, and calculating the starting virtual byte offset of the MTT mapping table block of the target MR in the global mapping space according to the step parameter; traversing down level by level starting from the highest-level root physical page of the multi-level page table structure, extracting the entry index of the current-level physical page from the initial virtual byte offset according to the preset shift amount of the current-level physical page, and reading the entry content in the current-level physical page corresponding to the entry index; if the lower-level physical base address pointed to by the entry content is invalid, allocating a physical page from the DDR storage pool, and backfilling the starting physical base address of the allocated physical page into the current entry; after reading the lower-level physical base address, performing bitwise truncation update on the updated virtual byte offset by using a mask of the same order as the preset shift amount of the current-level physical page, clearing the used high bits, and retaining the low-bit offset only used for lower-level addressing; after all levels of the multi-level page table structure are traversed, adding the starting physical base address of the last-level physical page and the remaining byte offset retained by the final truncation to obtain the actual storage address of the target MTT in the physical storage medium.

2. The method according to claim 1, characterized in that, The step parameter is a logarithm MR_GROUP_LOG corresponding to the total number of bytes MR_GROUP_SIZE occupied by a single MTT mapping unit under the corresponding MR category; wherein the MTT mapping unit is formed by consecutively arranging all MTT entries required by a single MR under the corresponding category, and the number of MTT entries is determined after being aligned up to a power of 2; The initial virtual byte offset OFFSET=MR_ID<<MR_GROUP_LOG; wherein MR_ID is the consecutive number of the MR to which the target MTT belongs in the current category logical space, and << is a logical left shift operator.

3. The method according to claim 1, characterized in that, The preset shift amount SHIFT[level] of the current-level physical page=MR_GROUP_LOG×PAGE_INDEX_BITS; wherein MR_GROUP_LOG is the step parameter, PAGE_INDEX_BITS is the bit width of the entry index of the single-level physical page, and level is a level index value incrementing upwards starting from the lowest level of the multi-level page table structure; The current-level entry index level_offset=OFFSET>>SHIFT[level]; OFFSET is the remaining byte offset after truncation at the current stage; The mask MASK[level]=(1<<SHIFT[level])-1; the formula for the bitwise truncation update is: OFFSET=OFFSET&MASK[level]; where & is a bitwise AND operator.

4. The method according to claim 1, characterized in that, The size of the physical page is 4KB; when the next-level physical base address pointed to by the entry content is invalid, the action of allocating a physical page from the DDR storage pool and backfilling the start address of the entry is triggered; this allocation and backfilling action is only performed when a physical page miss occurs on the current access path, and does not perform full pre-allocation of physical memory for the entire multi-level page table space to which the target MR belongs during the system initialization phase.

5. The method according to claim 1, characterized in that, The method further comprises: Establishing a hierarchical bitmap structure for the MTT corresponding to each type of MR; in the hierarchical bitmap structure, a single bit in the upper-level sub-bitmap is used to indicate whether there is an MTT number ID in an idle state in the bitmap group of the corresponding lower-level sub-bitmap.

6. The method according to claim 5, characterized in that, The method further comprises the step of allocating an MTT number ID through the hierarchical bitmap structure: Scanning level by level downward starting from the highest level of the hierarchical bitmap structure, to obtain the high-order index H_IDX corresponding to the idle bit in the current-level bitmap; Locating to the intermediate-level bitmap group according to H_IDX to scan and obtain the intermediate-level index M_IDX, and further locating to the lowest-level bitmap group to scan and obtain the lowest-level index L_IDX; Assembling the indexes of all levels according to the following formula to obtain the target MTT number ID: ID=(H_IDX<<(P_BITS×2))|(M_IDX<<P_BITS)|L_IDX; wherein << is a bitwise left shift operator, | is a bitwise OR operator, and P_BITS is the binary power corresponding to the number of bits in the lowest-level bitmap group.

7. The method according to claim 6, characterized in that, The method further comprises the step of reclaiming the MTT number ID by using the hierarchical bitmap structure: After releasing the target MTT number ID, setting the bit corresponding to L_IDX in the lowest-level bitmap group to zero; Judging whether all bits in the current lowest-level bitmap group are in a zero state, and if so, backtracking to the upper level, and setting the bit indicated by the corresponding M_IDX in the intermediate-level bitmap group to zero; Judging whether all bits in the intermediate-level bitmap group are in a zero state, and if so, continuing to backtrack to the highest level, and setting the bit indicated by H_IDX in the highest-level bitmap to zero.

8. The method according to claim 6, characterized in that, In the hierarchical bitmap structure, the bit mapping relationship between adjacent levels is expanded by a fixed power multiple; in the lowest level sub-bitmap, it is expanded by 2... P_BITS Each bit is divided into a bitmap group, and each bit in the upper-level sub-bitmap corresponds to the idle state of the bitmap group of the lowest-level sub-bitmap.

9. A non-transitory computer-readable storage medium, wherein the storage medium stores at least one instruction or at least one program segment, characterized in that, The at least one instruction or the at least one segment of program is loaded and executed by a processor to implement the processing method for the storage resource mapping table MTT according to any one of claims 1 to 8.

10. An electronic device, characterized in that, Comprising a processor and the non-transitory computer-readable storage medium according to claim 9.

Images