A dynamic memory partitioning algorithm for multi-accelerator heterogeneous systems

Abstract

The application relates to a dynamic memory partitioning algorithm for a multi-accelerator heterogeneous system, and relates to a robot heterogeneous computing system simultaneously provided with a CPU and multiple special accelerators. The algorithm is composed of three algorithm modules, namely a memory access analysis module, a global data management module and a memory resource allocation module. The application classifies the accelerators by analyzing the memory access behaviors of the accelerators, and realizes different memory resource allocation and sharing strategies according to the characteristics of accelerators of different categories, thereby improving the utilization rate of memory resources. The application also aims at the problems of uneven resource allocation caused by static memory resource allocation of a traditional memory partitioning algorithm and intensified local memory resource contention of multiple accelerators. On the basis of the page coloring technology, in combination with global data management, the application realizes unified allocation and release of memory bank resources, and finally realizes dynamic allocation of memory resources, optimizes the problem of inconsistent resource allocation and demand caused by static resource allocation, and alleviates the problem of intensified local memory resource contention of multiple accelerators.

Description

Technical Field

[0001] The present invention relates to a heterogeneous computing system for robots that simultaneously have a CPU and multiple dedicated accelerators, and more specifically to a dynamic memory partitioning algorithm for multi-accelerator heterogeneous systems. Background Technology

[0002] The increasing intelligence of robots places higher demands on the computing power and power consumption of the computing devices they carry. With the increasing number of accelerators in robots, shared memory resources among accelerators become a major performance bottleneck. The mainstream operating systems for modern robots employ a "blind" random physical page allocation mechanism. When a page miss occurs, a physical page (or multiple pages with contiguous addresses) is randomly retrieved from the buddy system, and the OS establishes a virtual-physical mapping in the page table. This allocation method results in data being stored arbitrarily in memory across different accelerators, leading to data access interference and decreased accelerator memory access efficiency. Therefore, memory partitioning for accelerators in heterogeneous computing systems for robots is crucial for improving accelerator memory access efficiency and reducing memory access latency.

[0003] Memory partitioning algorithms intervene in the mapping process from virtual pages to physical frames in the operating system, achieving specific mappings between virtual pages and physical frames. This maps data from different computing cores to different locations in memory, effectively isolating the data of different computing cores at the physical memory level. This algorithm can effectively reduce data access interference between computing cores and improve the memory access efficiency of accelerators.

[0004] Existing memory partitioning algorithms are mainly designed for traditional multi-core CPU scenarios. Due to the variability of tasks executed in CPU scenarios, partitioning strategies are mainly focused on static partitioning. When applied to heterogeneous computing systems for robots, this can exacerbate the problem of multiple accelerators competing for local resources. Dynamic partitioning algorithms for CPUs can adjust resource allocation based on the CPU's memory access characteristics, but these algorithms use a static allocation method and cannot dynamically allocate memory resources according to the needs of different accelerators, which can lead to a decrease in memory resource utilization. Summary of the Invention

[0005] The purpose of this invention is to provide a dynamic memory partitioning algorithm for multi-accelerator heterogeneous systems, the algorithm comprising:

[0006] (a) Analyze the memory access characteristics of each accelerator in real time. Capture the memory access information of the accelerator by analyzing data such as memory access request volume and request completion status, and calculate two indicators: row hit rate and MPKI.

[0007] The specific process of (a) is as follows:

[0008] (a-1) Periodically count the number of memory access requests for each accelerator over a period of time and the status of the memory access process, and update and maintain it in real time;

[0009] (a-2) Based on the statistical information of each accelerator, calculate the accelerator row hit rate and MPKI index;

[0010] (b) Accelerators are classified based on row hit rate and MPKI, and are divided into three categories: High Hit Rate and Memory-Intensive (HRHM), High Hit Rate and Memory-Inactive (HRLM), and Low Hit Rate (LR).

[0011] The specific process of (b) is as follows:

[0012] (b-1) If the computing core is a CPU, then add LR; otherwise, perform accelerator classification.

[0013] (b-2) Compare the accelerator row hit rate with the threshold Rth. If it is lower than Rth, add the accelerator to LR.

[0014] (b-3) If the row hit rate is higher than Rth, compare the accelerator MPKI with the threshold Mth. If it is lower than Mth, add the accelerator to HRLM.

[0015] (b-4) Otherwise, add the accelerator to HRHM;

[0016] (c) Based on accelerator classification, accelerators of the same type are grouped together, and subsequent memory resource allocation is carried out on a group basis. The memory resource allocation unit is a memory bank.

[0017] The specific process of (c) is as follows:

[0018] (c-1) If the accelerator is HRHM, one accelerator is treated as a group, and each accelerator is allocated memory resources separately and used exclusively.

[0019] (c-2) If the accelerator is HRLM, two accelerators are combined into one group, and the two accelerators share the allocated memory resources.

[0020] (c-3) If the accelerator is LR, all accelerators in the category are grouped into one group, and memory resources are allocated to the group, which are shared by all accelerators in the group.

[0021] (d) When the system is initially running, all accelerators are classified as LR and a bank resource is allocated to the group to complete the initial memory resource allocation.

[0022] (e) During system operation, the CPU category remains LR, while the accelerator category changes as needed. The accelerator category is adjusted in real time based on the accelerator's memory access characteristics, and memory resources are released in a timely manner according to the adjusted group status.

[0023] The specific process of (e) is as follows:

[0024] (e-1) Analyze the memory access characteristics of the accelerator. If the accelerator category remains unchanged, the accelerator grouping information and its group status remain unchanged.

[0025] (e-2) If the accelerator category changes, perform group adjustment, update the group status information of the accelerator, and adjust the accelerator to the new category group;

[0026] (e-3) Check the original packet status information of the accelerator and release the memory resources allocated to the packet in a timely manner;

[0027] (f) When a page fault occurs in the system, determine the computing core to which the virtual page belongs, determine the group to which the computing core belongs, and allocate a memory physical frame to store the page data read by the system from the disk.

[0028] The specific process of (f) is as follows:

[0029] (f-1) Determine the process ID of the virtual page to which the page fault occurred;

[0030] (f-2) Based on the process information, determine the CPU core ID or accelerator to which the virtual page belongs;

[0031] (f-3) Obtain the group to which the computing core belongs through the background mapping information, and obtain the memory resource information allocated to the group;

[0032] (f-4) Obtain the free bank resource ID number of the allocated memory resources in this group, and allocate a free physical frame for this virtual page;

[0033] (g) If the group has exhausted its allocated memory resources and there are no more physical frames to allocate during the allocation of physical frames, then a memory bank resource will be allocated to the group.

[0034] The specific process of (g) is as follows:

[0035] (g-1) View the global memory resource allocation table to obtain information on currently allocable memory resources;

[0036] (g-2) If there is currently free memory bank resource available for allocation, a bank resource will be allocated to the group, and the resource allocation status and the group information will be updated.

[0037] (g-3) If there are no free memory bank resources available for allocation, then according to the memory resource occupancy of each group, a memory bank resource from another group is preempted and allocated to that group.

[0038] (h) After allocating a physical frame for the virtual page to which the page fault belongs, change the relevant data of the page in the page table, map the page data to the allocated physical frame, and complete the remapping of the physical frame.

[0039] (i) During system operation, steps (f)-(h) will be executed continuously to complete the remapping of system virtual pages to physical frames.

[0040] This invention proposes a memory mapping management system for multi-accelerator heterogeneous computing systems based on physical frame reallocation. The system includes:

[0041] The memory access analysis module periodically analyzes the memory access behavior of accelerators, classifies accelerators, and implements different grouping strategies for different categories of accelerators according to their characteristics.

[0042] The global data management module maintains global memory resource allocation information and resource information allocated to each group, and updates resource allocation information and accelerator grouping information regularly.

[0043] The memory resource allocation module is responsible for allocating physical memory frames when the system experiences a page fault. It also allocates memory bank resources to the group in a timely manner based on the group's allocated resources. Simultaneously, it monitors the group's status and reclaims the group's allocated memory resources after checking the status of its members, thus achieving dynamic allocation and reclamation of memory resources.

[0044] The beneficial effects of this invention are that it provides a dynamic memory partitioning algorithm for multi-accelerator heterogeneous systems. This dynamic memory partitioning is implemented based on page coloring technology and a virtual memory pool design. This invention classifies accelerators by analyzing their memory access behavior and implements different memory resource allocation and sharing strategies for different categories of accelerators, alleviating the problem of memory resource waste caused by traditional memory partitioning algorithms that do not consider accelerator memory access characteristics, thus greatly improving memory resource utilization. Furthermore, this invention addresses the problem of uneven resource allocation and increased contention for local memory resources among multiple accelerators caused by static memory resource allocation in traditional memory partitioning algorithms. Based on page coloring technology and combined with global data management, it implements a virtual memory pool to achieve unified management of memory resources and dynamically allocates resources according to the real-time needs of multiple accelerators. This ultimately achieves dynamic memory partitioning, optimizing the problem of inconsistent resource allocation and demand caused by static resource allocation and alleviating the problem of increased contention for local memory resources among multiple accelerators. Attached Figure Description

[0045] Figure 1This is a flowchart of the memory access analysis of the present invention.

[0046] Figure 2 This is a flowchart of the memory resource allocation process of the method of the present invention.

[0047] Figure 3 This is a schematic diagram of the physical frame remapping principle of the present invention. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be described in detail below with reference to the accompanying drawings and specific implementation steps, but this is not intended to limit the invention.

[0049] This invention provides a dynamic memory partitioning algorithm for multi-accelerator heterogeneous systems. The algorithm consists of three modules: a memory access analysis module, a global data management module, and a memory resource allocation module. The memory access analysis module periodically analyzes the memory access behavior of multiple accelerators, classifies them, and implements different grouping strategies for different categories of accelerators based on their characteristics. The global data management module maintains global memory resource allocation information, allocated resource information for each group, and memory access information for multiple accelerators, and periodically updates the resource allocation information and accelerator grouping information. The memory resource allocation module is responsible for allocating physical memory frames to accelerators when a page fault occurs, performing remapping, and allocating memory bank resources to accelerator groups in a timely manner based on the allocated resources of each group. Simultaneously, it monitors the group status and reclaims the allocated memory resources of the group based on the members within the group, thus achieving dynamic allocation and reclamation of memory resources.

[0050] Specifically, the implementation of the above dynamic memory partitioning algorithm for multi-accelerator heterogeneous systems is as follows:

[0051] S1: Real-time analysis of memory access characteristics of each accelerator. By analyzing data such as memory access request volume and request completion status, the accelerator memory access information is captured, and two metrics, row hit rate and MPKI, are calculated.

[0052] Specifically, step S1 includes the following sub-steps:

[0053] S1-1: Set the initial cycle to 1,000,000 (unit: cycles). Use this cycle as the unit to count the number of memory access requests for each accelerator over a period of time and the status of the memory access process. The global data management module will update and maintain the relevant data in real time.

[0054] S1-2: Based on the accelerator information maintained by the global data management module, calculate the accelerator Row Hit Rate and MPKI metric. The formulas for calculating Row Hit Rate and MPKI are as follows:

[0055] Row Hit Rate=(〖Req〗_end-〖Req〗_start) / (〖TolReq〗_end-〖TolReq〗_start)

[0056] MPKI=(〖L2miss〗_end-〖L2miss〗_start) / (〖ins〗_end-〖ins〗_start)×1000

[0057] S2: Based on Row Hit Rate and MPKI, accelerators are categorized into three types: High Hit Rate and Memory-Intensive (HRHM), High Hit Rate and Memory-Inactive (HRLM), and Low Hit Rate (LR). The detailed grouping process is as follows... Figure 1 As shown.

[0058] Specifically, step S2 includes the following sub-steps:

[0059] S2-1: First, determine the type of the computing core. If the computing core is a CPU, add it to LR; otherwise, perform accelerator classification.

[0060] S2-2: Compare the accelerator Row Hit Rate with the threshold Rth. If it is lower than Rth, add the accelerator to LR. If the Row Hit Rate is higher than Rth, compare the accelerator MPKI with the threshold Mth. If it is lower than Mth, add the accelerator to HRLM.

[0061] S2-4: Otherwise, add the accelerator to HRHM;

[0062] S3: Based on accelerator classification, group accelerators of the same type together, and allocate memory resources to each group as a unit, with the memory resource allocation unit being a memory bank. The following sub-steps are performed on the accelerator grouping:

[0063] S3-1: If the accelerator is HRHM, one accelerator is treated as a group, and each accelerator is allocated memory resources separately and used exclusively.

[0064] S3-2: If the accelerator is HRLM, two accelerators are combined into one group, and the two accelerators share the allocated memory resources.

[0065] S3-3: If the accelerator is LR, all accelerators in the category are grouped into one group, and memory resources are allocated to the group, which are shared by all accelerators in the group.

[0066] S4: When the system first starts running, it first performs initialization. All accelerators are classified as LR and a bank resource is allocated to this group, completing the initial memory resource allocation.

[0067] S5: During system operation, the CPU category remains LR, while the accelerator category changes as needed. The accelerator category is adjusted in real-time based on the accelerator memory access characteristics, and memory resources are released as needed based on the adjusted group status. The following steps are executed for accelerator type changes and group adjustments:

[0068] S5-1: Analyze the memory access characteristics of the accelerator. If the accelerator category remains unchanged, the accelerator grouping information and its group status remain unchanged.

[0069] S5-2: If the accelerator category changes, perform group adjustment, update the group status information of the accelerator, and adjust the accelerator to the new category group;

[0070] S5-3: Check the original group status information of the accelerator. If the count value of the group is 0, release the allocated memory resources of the group and set the status to false; otherwise, keep the group unchanged.

[0071] S6: The memory access analysis module continuously executes steps S1–S6 to update the real-time status and groups of accelerators. During this period, the memory access analysis module determines whether an accelerator is running. If it determines that an accelerator was not running in the previous statistical period, it ignores the statistical data of that accelerator in this stage to reduce frequent changes in accelerator classification.

[0072] S7: When a page fault occurs, the system determines the accelerator to which the virtual page belongs, the group to which the accelerator belongs, and allocates a physical memory frame to store the page data read from the disk. The remapping of the virtual page to the physical frame after a page fault performs the following steps:

[0073] S7-1: Determine the process ID of the virtual page to which the page fault occurred, and based on the process information, determine the CPU core ID or accelerator to which the virtual page belongs;

[0074] S7-2: Obtain the group to which the accelerator belongs and the memory resource information allocated to the group through the background mapping information;

[0075] S7-3: If the group has available physical frames, obtain the idle bank resource ID number for the group, allocate an idle physical frame for the virtual page, modify the relevant data for the page in the page table, and map the page data to the allocated physical frame, completing the physical frame remapping. The virtual page to physical frame mapping process is as follows: Figure 3 As shown;

[0076] S7-4: If the allocated memory resources for this group are exhausted and there are no more physical frames to allocate, the memory resource allocation module will allocate memory resources for it. The specific memory resource allocation process is as follows: Figure 2As shown. First, check the global memory resource allocation table to obtain information on currently allocatable memory resources;

[0077] S7-5: If there are currently free memory bank resources available for allocation, a bank resource will be allocated to the group and the resource allocation status and group information will be updated; if there are currently no free memory bank resources available for allocation, a memory bank resource from another group will be preempted and allocated to the group based on the memory resource occupancy of each group.

[0078] S8: After allocating a physical frame for the virtual page to which the page fault belongs, modify the relevant data of the page in the page table, map the page data to the allocated physical frame, and complete the remapping of the physical frame.

[0079] S9: During system operation, steps S6-S8 will be executed continuously to complete the remapping of all virtual pages to physical frames during system operation.

Claims

1. A dynamic memory partitioning method for multi-accelerator heterogeneous systems, wherein, Dynamic memory partitioning is implemented based on a virtual memory pool design. This design, combined with global data management, enables unified management of memory resources and dynamically allocates resources according to the real-time needs of multiple accelerators. The method consists of three modules: a memory access analysis module, a global data management module, and a memory resource allocation module. The memory access analysis module periodically analyzes the memory access behavior of multiple accelerators, classifies them, and implements different grouping strategies for different categories of accelerators based on their characteristics. The global data management module maintains global memory resource allocation information, allocated resource information for each group, and memory access information for multiple accelerators, and periodically updates resource allocation information and accelerator grouping information. The memory resource allocation module is responsible for allocating physical memory frames to accelerators when a system page fault occurs, performing remapping, and allocating memory bank resources to accelerator groups in a timely manner based on the allocated resources of each group. Simultaneously, it monitors the group status and reclaims allocated memory resources for the group based on the members within the group, achieving dynamic allocation and reclamation of memory resources. Includes the following steps: S1: The memory access analysis module analyzes the memory access characteristics of each accelerator in real time, statistically analyzes the memory access request volume and status of each accelerator over a period of time, and calculates two metrics: Row Hit Rate and MPKI. The global data management module updates and maintains the accelerator analysis data in real time. The formulas for calculating Row Hit Rate and MPKI are as follows: ， ； S2: Based on the accelerator memory access analysis information maintained by the global data management module, the accelerators are divided into three categories: high hit rate and memory-intensive HRHM, high hit rate and memory-inefficient HRLM, and low hit rate LR. S3: Based on accelerator classification information, accelerators of the same type are grouped together, and subsequent memory resource allocation is carried out on a group basis. The memory resource allocation unit is a memory bank. S4: When the system is initially running, the memory resource allocation module is initialized, all accelerators are classified as LR, and a bank resource is allocated to the group to complete the initial memory resource allocation; S5: During system operation, the CPU category is always LR, while the accelerator category is changed as needed; the accelerator category is adjusted in real time according to the accelerator memory access characteristics, and memory resources are released in a timely manner according to the adjusted group status. S6: The memory access analysis module will continuously execute steps S1–S5 to achieve real-time status and group updates for accelerators. During this period, the memory access analysis module will determine whether the accelerator is running. If it is determined that the accelerator has not run in the previous statistical period, the statistical data of the accelerator in this stage will be ignored to reduce the frequent changes in accelerator classification. S7: When a page fault occurs in the system, determine the accelerator to which the virtual page belongs, determine the group to which the accelerator belongs, check the resources allocated to the group, find a free physical memory frame and allocate it to store the page data read by the system from the disk; S8: After allocating a physical frame for the virtual page to which the page fault belongs, modify the data of that page in the page table, map the page data to the allocated physical frame, and complete the remapping of the physical frame; S9: During system operation, steps S6-S8 will be executed continuously to complete the remapping of all virtual pages to physical frames during system operation.

2. The method according to claim 1, characterized in that, Step S2 includes the following sub-steps: S2-1: Compare the accelerator Row Hit Rate with the threshold Rth. If it is lower than Rth, add the accelerator to LR. S2-2: If the Row Hit Rate is higher than Rth, compare the accelerator MPKI with the threshold Mth. If it is lower than Mth, add the accelerator to HRLM; otherwise, add the accelerator to HRHM. S2-3: Store the accelerator classification information in the global data management module and update and maintain it in real time; Step S3 includes performing the following sub-steps on the grouping of accelerators: S3-1: If the accelerator type is HRHM, one accelerator is treated as a group, and each accelerator is allocated memory resources separately and used exclusively. S3-2: If the accelerator type is HRLM, two accelerators are combined into one group, and the two accelerators share the allocated memory resources. S3-3: If the accelerator type is LR, all accelerators in the category are grouped into one group, and memory resources are allocated to this group, which are shared by all accelerators in the group. Step S5 includes the following sub-steps for accelerator type change and grouping adjustment: S5-1: Analyze the memory access characteristics of the accelerator. If the accelerator category remains unchanged, the accelerator grouping information and its group status remain unchanged. S5-2: If the accelerator category changes, perform group adjustment, update the group status information to which the accelerator belongs, and adjust the accelerator to the new category group; check the original group status information of the accelerator. If the group has no members, release the memory resources allocated to the group; otherwise, keep the group unchanged. Step S7 includes the remapping of virtual pages to physical frames after a page fault, which involves the following sub-steps: S7-1: Determine the process ID of the virtual page to which the page fault occurred, and based on the process information, determine the CPU core ID or accelerator to which the virtual page belongs; obtain the group to which the accelerator belongs through background mapping information, and obtain the memory resource information allocated to the group; S7-2: If there are available physical frames in the group, obtain the idle bank resource ID number of the group, allocate an idle physical frame for the virtual page, modify the data of the page in the page table, map the page data to the allocated physical frame, and complete the remapping of the physical frame. S7-3: If the group has exhausted its allocated memory resources and there are no physical frames available for allocation, the memory resource allocation module will allocate memory resources for it. First, it will check the global memory resource allocation table to obtain the information on currently available memory resources. S7-4: If there are currently free memory bank resources available for allocation, a bank resource will be allocated to the group and the resource allocation status and group information will be updated; if there are currently no free memory bank resources available for allocation, a memory bank resource from another group will be preempted and allocated to the group based on the memory resource occupancy of each group.

Images