Resource management and task scheduling method for reconfigurable hardware accelerator oriented heterogeneous computing cluster

Abstract

This invention discloses a method for resource management and task scheduling of heterogeneous computing clusters for reconfigurable hardware accelerators, comprising: a management control node dividing time into equally spaced scheduling time slots; at each scheduling time slot, the management control node collecting request processing tasks arriving in the previous scheduling time slot and the currently idle computing resources of the heterogeneous computing cluster; the management control node establishing a three-sided matching game framework for request processing tasks, service functions, and heterogeneous computing nodes; the management control node defining the preference criteria of each party based on the optimization objective; the management control node running a three-sided stable matching algorithm for matching; the management control node offloading request processing tasks to the heterogeneous computing nodes where the matching service functions are located for processing based on the matching results; waiting for the next scheduling time slot to arrive, and repeating the above steps. This method can effectively reduce the total task processing latency while maintaining a high task completion rate and task satisfaction.

Description

Technical Field

[0001] This invention relates to the field of task scheduling and resource management technology, and in particular to a method for resource management and task scheduling of heterogeneous computing clusters oriented towards reconfigurable hardware accelerators. Background Technology

[0002] Heterogeneous computing refers to a computing system composed of processors with different instruction sets and architectures. Unlike other processors, the Central Processing Unit (CPU) can run independently, while other accelerator processors require the CPU's assistance to operate. Therefore, heterogeneous computing typically refers to a CPU+xPU heterogeneous computing architecture (xPU broadly refers to other non-CPU hardware accelerators). Hardware accelerators are further divided into application-specific hardware accelerators and reconfigurable hardware accelerators, such as Graphics Processing Units (GPUs) and Field-Programmable Gate Arrays (FPGAs). Application-specific hardware accelerators have fixed functions, while reconfigurable hardware accelerators can change their functions on demand through software reconfiguration. Heterogeneous computing integrates CPUs and various types and architectures of hardware accelerators, enabling larger-scale, higher-performance, and more efficient computing. Therefore, heterogeneous computing nodes based on CPU+xPU are widely used in high-performance computing, artificial intelligence (AI) and other fields. In this case, the CPU is responsible for executing the parts of the computing task that do not require acceleration, while the xPU focuses on executing large-scale computing-intensive tasks and is responsible for executing the parts of the computing task that require acceleration.

[0003] Heterogeneous computing clusters integrate a large number of heterogeneous computing nodes, thereby providing greater computing power for computing tasks. Due to the short iteration cycles and rapid updates of computing hardware technologies, heterogeneous computing clusters inevitably include heterogeneous computing nodes from different periods, of different types, and of different models in order to save costs. For example, some heterogeneous computing nodes integrate a large number of CPU cores, GPUs, or FPGAs, and have high performance, while others integrate fewer processors and have lower performance. Therefore, how to efficiently utilize computing resources and schedule tasks in heterogeneous computing clusters is a very urgent problem to be solved, and also a very challenging one.

[0004] Currently, the invention patent "Method, Device, and Storage Medium for Allocating Computing Resources Based on Hybrid Distributed Architecture" (CN110704186 A) proposes a resource scheduling method. This method primarily divides tasks into different task queues based on task type and into different logical clusters based on the types of computing resources on different physical machines. Then, it allocates task queues to the corresponding logical clusters. However, this method fails to consider the interests of both the tasks and computing resources, thus failing to achieve a stable match between them and hindering efficient utilization of computing resources. Furthermore, it does not consider the advantages of CPU, FPGA, and GPU hardware resources, which can be arbitrarily combined as needed, and the functional reconfiguration capabilities of hardware accelerators. The invention patent "Heterogeneous Computing System and its Computing Node Selection Method, Device, Equipment, and Medium" (CN 116954873 A) requires continuous testing of the heterogeneous computing system, resulting in resource waste. The invention patent "A Computing Framework Management System" (CN 117075930A) proposes a heterogeneous computing cluster architecture but does not provide specific methods for resource management and task scheduling. The invention patent "Task Scheduling Method, Apparatus, Device and Medium for Heterogeneous Computing Systems" (CN 115756803 A) proposes a hybrid scheduling strategy based on distribution estimation algorithm and graph random walk strategy, which is a hybrid scheduling strategy of vertex greedy and edge greedy. It not only fails to consider the "CPU+xPU" ​​heterogeneous computing architecture when processing computing tasks, but also fails to consider the profit-seeking demands of computing resources. The invention patent "Task Allocation Method Based on Energy-Aware Profit Maximization in Heterogeneous Computing Systems" (CN 202211039025.3) also employs a greedy strategy, first allocating computing resources to tasks that can generate the maximum profit, without considering the "CPU+xPU" ​​heterogeneous computing architecture. Meanwhile, current resource management and task scheduling methods also include some based on machine learning and evolutionary algorithms (such as genetic algorithms, ant colony optimization, differential evolution, etc.). Among them, machine learning-based resource management and task scheduling methods require a large amount of training before they can be used, making them difficult to apply to computing cluster systems that do not have the conditions for large-scale training. Evolutionary algorithm-based resource management and task scheduling methods, on the other hand, will have their computational complexity and iteration time increase exponentially with the expansion of system scale, thereby increasing task scheduling time and reducing task processing efficiency. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a heterogeneous computing cluster resource management and task scheduling method for reconfigurable hardware accelerators that can effectively reduce the total task processing latency while maintaining a high task completion rate and task satisfaction.

[0006] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is: a method for resource management and task scheduling of heterogeneous computing clusters for reconfigurable hardware accelerators, comprising the following steps:

[0007] 1) The management and control node divides time into equally spaced scheduling time slots;

[0008] 2) During the scheduling time, the management and control node collects the request processing tasks that arrived in the previous scheduling time slot and the currently idle computing resources of the heterogeneous computing cluster. The scheduling time refers to the end time of each scheduling time slot.

[0009] 3) The management and control node establishes a three-way matching game framework oriented towards request processing tasks, service functions (SF), and heterogeneous computing nodes;

[0010] 4) Management and control nodes are based on the optimization objectives and the preferences of all parties.

[0011] 5) The management and control node runs a trilateration stable matching algorithm to match tasks with service functions;

[0012] 6) The management and control node will offload the request processing task to the heterogeneous computing node where the matching service function is located based on the matching result;

[0013] 7) Wait for the next scheduling time slot to arrive, and then repeat steps 2)-6) to schedule the request processing tasks that arrive in each scheduling time slot.

[0014] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0015] 1) This invention addresses the interests of the three parties: request processing task, service function SF, and heterogeneous computing nodes. It constructs a three-sided matching game framework using a three-sided matching game strategy and proposes a three-sided matching algorithm based on request processing task, service function SF, and heterogeneous computing nodes. It has been proven that the algorithm can achieve stable three-sided matching after a finite number of iterations and has relatively low computational complexity.

[0016] 2) Based on two optimization objectives: maximizing the task completion rate and minimizing the total task processing delay, this invention designs a delay-greedy preference criterion and a dual-interval preference criterion for each party in the matching game process. Simulation results show that the trilateral matching algorithm proposed in this invention can effectively reduce the total task processing delay and improve task satisfaction while maintaining a high task completion rate.

[0017] 3) This invention combines the proposed trilateral matching algorithm with the constructed time slot model, enabling real-time scheduling of request processing tasks arriving within each time slot. Attached Figure Description

[0018] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments;

[0019] Figure 1 This is a flowchart of the method described in the embodiments of the present invention;

[0020] Figure 2 This is a schematic diagram of the service instance creation process in an embodiment of the present invention;

[0021] Figure 3 This is a schematic diagram of a heterogeneous computing cluster in an embodiment of the present invention;

[0022] Figure 4 This is a comparison chart of simulation results of the task completion rate with other existing task scheduling algorithms in this embodiment of the invention;

[0023] Figure 5 This is a comparison chart of simulation results with other existing task scheduling algorithms in terms of the total task processing latency in this embodiment of the invention;

[0024] Figure 6 This is a comparison chart of simulation results with other existing task scheduling algorithms in terms of task satisfaction in this embodiment of the invention. Detailed Implementation

[0025] 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 a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0026] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0027] Overall, such as Figure 1 As shown in the figure, this invention discloses a method for resource management and task scheduling of heterogeneous computing clusters for reconfigurable hardware accelerators, including the following steps:

[0028] 1) The management and control node divides time into equally spaced scheduling time slots;

[0029] 2) During the scheduling time, the management and control node collects the request processing tasks that arrived in the previous scheduling time slot and the currently idle computing resources of the heterogeneous computing cluster. The scheduling time refers to the end time of each scheduling time slot.

[0030] 3) The management and control node establishes a three-sided matching game framework oriented towards request processing tasks, service functions (SF), and heterogeneous computing nodes;

[0031] 4) Management and control nodes are based on the optimization objectives and the preferences of all parties.

[0032] 5) The management and control node runs a trilateration stable matching algorithm to match tasks with service functions;

[0033] 6) The management and control node will offload the request processing task to the heterogeneous computing node where the matching service function is located based on the matching result;

[0034] 7) Wait for the next scheduling time slot to arrive, and then repeat steps 2)-6) to schedule the request processing tasks that arrive in each scheduling time slot.

[0035] The steps described above will be explained in detail below.

[0036] First, the service instance creation process is introduced; then, the heterogeneous computing resource cluster model, resource allocation model, task scheduling model, and optimization objectives are described; finally, a three-sided matching game framework and a three-sided stable matching algorithm are given.

[0037] Service instance creation process:

[0038] The request processing tasks involved in this application include traditional application tasks and complex computational tasks. The former are processed on the CPU, while the latter require the assistance of hardware accelerators for processing. This application collectively refers to GPUs or FPGAs running complex algorithms such as AI as hardware accelerators. To provide multiple services to the request processing tasks, the heterogeneous computing nodes involved in this application adopt a "CPU + hardware accelerator" computing architecture, such as... Figure 2 As shown. When a heterogeneous computing node creates an SF instance for a request processing task, it first needs to obtain corresponding idle computing resources (CPU, FPGA, or GPU). Then, based on Virtual Machine (VM) or Docker technology, the service function SF software stored on the hard disk is dynamically loaded onto the CPU, FPGA, or GPU to run, thereby completing the creation of an SF instance. Next, the request processing task can be processed on the SF instance. Without loss of generality, this application classifies service function SFs into three categories based on the computing resources occupied by the SF instance: single-core CPU SF, dual-core "CPU+FPGA" SF, and dual-core "CPU+GPU" SF. Figure 2 As shown, a single-core CPU SF service instance only occupies a CPU core and is used to handle some low-complexity tasks, such as... Figure 2 ① in the middle is: Service Function SF 1,1When creating a service instance, it only needs to include the SF. 1,1 The software can be dynamically loaded onto currently idle CPU cores; however, service instances of "CPU+FPGA" dual-core SF and "CPU+FPGA" dual-core SF not only require CPU cores but also FPGA or GPU assistance to run complex algorithms such as AI, for handling computationally intensive tasks, such as... Figure 2 ② in the middle is: Service Function SF 1,2 When creating a service instance, its service function software consists of two parts: one part is loaded onto the currently idle CPU core for execution, and the other part is loaded onto the currently idle GPU device for execution, thus reconstructing the GPU device into a hardware accelerator with the corresponding function. Figure 2 ③ is: Service Function SF 1,3 When creating a service instance, its service function software consists of two parts: one part is loaded onto the currently idle CPU core for execution, and the other part is loaded onto the currently idle FPGA device for execution, thus reconstructing the FPGA device into a hardware accelerator with the corresponding function.

[0039] Heterogeneous computing clusters:

[0040] like Figure 3 As shown, this application considers a scenario for resource management and task scheduling of heterogeneous computing resource clusters. The heterogeneous computing resource cluster comprises several heterogeneous computing nodes and a management and control node, all interconnected via high-speed Ethernet. Each heterogeneous computing node carries a certain number of CPU, GPU, and FPGA computing resources and deploys several service functions (SFs). The number of computing resources and deployed service functions (SFs) may differ between different heterogeneous computing nodes. The management and control node can monitor the resource usage of all heterogeneous computing nodes in real time via Ethernet and run the proposed three-sided matching game algorithm to offload request processing tasks to the optimal heterogeneous computing node for processing. This scenario can be defined as... in, Represented as a heterogeneous computing cluster, i.e., a collection of heterogeneous computing nodes, U m U represents the m-th heterogeneous computing node, 1≤m≤M, where M represents the number of heterogeneous computing nodes in the heterogeneous computing cluster; at each scheduling time, U m The idle computing resources it supports include One CPU core, FPGA and One GPU; This represents all SF types deployed in a heterogeneous computing cluster. Among them, a single-core CPU SF has I1 types, represented as... The "CPU+FPGA" dual-core SF has I2 types, represented as: The "CPU+GPU" dual-core SF has I3 types, represented as follows: Then the equation Furthermore, considering the heterogeneity between heterogeneous computing nodes, the computing resources carried by different heterogeneous computing nodes and the number of SF deployed may differ, defining... U m The SF set deployed on, among which, Always true, SF m,q U m The qth type of SF deployed, totaling Q m Types; finally, define Θ = {Ω1,Ω2,…,Ω} k ,…,Ω K} represents the set of tasks currently being processed, where Ω k Let K represent the k-th pending request service task, where 1 ≤ k ≤ K, and K represents the number of pending request tasks received.

[0041] Resource allocation model:

[0042] like Figure 2 As shown, considering information security issues during task processing, this application stipulates that each SF instance exclusively occupies one CPU, FPGA, or GPU. Furthermore, to ensure that tasks with different service requests receive fair service, this application stipulates that the number of service instances created by any SF is limited, and they cannot occupy all computing resources on heterogeneous computing nodes. Therefore, the following definition is provided. For SF m,q in U m The maximum number of service instances that can be created simultaneously must meet the following constraints:

[0043]

[0044]

[0045]

[0046] Inequality (1) indicates that at any scheduling time, the number of any single-core CPU SF instances running on a heterogeneous computing node cannot exceed the number of idle CPU cores it carries; Inequality (2) indicates that at any scheduling time, the number of any dual-core "CPU+FPGA" SF instances running on a heterogeneous computing node cannot exceed the number of idle "CPU+FPGA" combinations it carries; Inequality (3) indicates that at any scheduling time, the number of any dual-core "CPU+GPU" SF instances running on a heterogeneous computing node cannot exceed the number of "CPU+GPU" combinations it carries.

[0047] Finally, define For SF m,qThe number of service instances created at each scheduling time must meet the following constraints:

[0048]

[0049]

[0050]

[0051]

[0052] Inequality (4) ensures that at each scheduling time, the number of instances created by any service function SF cannot exceed the specified upper limit; Inequality (5) ensures that at each scheduling time, U m The total number of "CPU+FPGA" dual-core SF instances created cannot exceed U m The number of idle CPU+FPGA combinations carried; Inequality (6) ensures that at the scheduling time, U m The total number of dual-core SF instances (CPU+GPU) created cannot exceed U. m The number of idle CPUs and GPUs carried; Inequality (7) ensures that at the scheduling time, U m The total number of SF instances created cannot exceed U. m The total number of idle CPU cores.

[0053] Task scheduling model:

[0054] This application defines binary integer variables. This indicates the management and control node's control over task Ω. k The scheduling strategy. When When, it indicates task Ω k Scheduled to U m Above, by SF m,q Service instance processing; when At that time, task Ω k Not processed. Additionally, definition. For task Ω k in U m The processing latency is considered. Given that each request task can be processed by at most one service function instance, the following inequality continues to be satisfied:

[0055]

[0056] Optimization goal:

[0057] This application considers heterogeneous computing nodes within a heterogeneous computing cluster. This means that different heterogeneous computing nodes may differ in the quantity and performance of their computing resources. Therefore, the processing capabilities exhibited by the same service function (SF) deployed on different heterogeneous computing nodes will vary. Thus, for a request processing task, when multiple heterogeneous computing nodes exist to satisfy its service request, it will naturally prefer to process the request on the node with the lowest processing latency. However, the computing resources of the heterogeneous computing cluster are also limited. It aims to process more tasks while minimizing the total processing latency. Therefore, this application proposes a resource management and task scheduling method that balances the interests of both the request processing task and the heterogeneous computing cluster to maximize task completion rate and minimize the total processing latency.

[0058] This application defines F1 as the task completion rate, which is the ratio of the number of successfully processed tasks to the total number of tasks requested for processing, as specifically expressed as follows:

[0059]

[0060] This application defines F2 as the total task processing latency, specifically as follows:

[0061]

[0062] Based on equations (9) and (10), a multi-objective optimization problem is formalized as follows:

[0063]

[0064] Problem P1 is a multi-objective optimization problem, and solving it faces two main challenges: First, the two optimization objectives are tightly coupled and influence each other. If only minimizing the F2 value is considered, then in the extreme case, when the heterogeneous computing cluster is not processing any tasks, the F2 value is minimized, i.e., equal to 0. However, this is obviously unreasonable. Heterogeneous computing clusters prefer to have more tasks processed, i.e., the larger the F1 value, the better, which will inevitably lead to an increase in the F2 value. Second, the request processing tasks arrive dynamically, and the management and control node must complete the scheduling of request processing tasks arriving within a time slot. This requires the scheduling algorithm to have low complexity. Currently, most traditional optimization algorithms, such as ant colony optimization, differential evolution, and genetic algorithms, will have their computational complexity and iteration time increase exponentially with the expansion of system scale, making it difficult to meet the efficient scheduling requirements of heterogeneous computing clusters. Currently, machine learning-based algorithms require a large amount of training before they can be used, making them unsuitable for computing cluster systems that do not have the conditions for large-scale training.

[0065] Algorithms based on matching game strategies focus on the mutually beneficial relationships among the parties and offer an efficient and low-complexity solution. This application transforms problem P1 into a three-sided matching game problem, constructs a three-sided matching game framework oriented towards request processing tasks, service functions (SF), and heterogeneous computing nodes, and proposes a three-sided stable matching algorithm that balances the interests of request processing tasks and heterogeneous computing clusters, achieving a relatively optimal solution to problem P1.

[0066] Three-sided matching game framework:

[0067] The following are some definitions related to the three-sided matching game framework constructed in this application:

[0068] Definition 1 (Acceptable Service Function SF): When SF m,q Belongs to task Ω k When requesting a service function type, for task Ω k For SF m,q It is acceptable; definition A k Represents task Ω k The set of acceptable service functions.

[0069] Definition 2 (Task Preferences and Task Preference List): When faced with multiple acceptable service instances (SFs) deployed on different heterogeneous computing nodes, each request processing task desires to obtain service from its most preferred SF. Then, when task Ω... k Facing SF m,q and When two acceptable single-factor (SF) options are available, the preference is given to the single-factor (SF). m,q When, it is represented as Management and control nodes are based on tasks Ω k Preferences for A k Sort the data in descending order to construct a preference list for acceptable space utilization (SF) deployed on different heterogeneous computing nodes, i.e. in, It is a task Ω k My favorite SF It is a task Ω k The last SF in the preference ranking;

[0070] Definition 3 (SF Preferences and SF Preference List): Considering that the computing resources carried by heterogeneous computing nodes are limited, when multiple request processing tasks want to be processed by the same SF deployed on the same heterogeneous computing node, the requested SF will prioritize providing services for its most preferred task. m,q Facing two request processing tasks Ω k and When it prefers task Ω k When, it is represented as The management and control node, based on SF preferences, assigns the currently waiting SF... m,q All request processing tasks are sorted in descending order, and an SF is constructed. m,q The preference list, i.e. in, It's SF m,q The most preferred request processing task at present. It's SF m,q The request processing task at the end of the current preference sort;

[0071] Definition 4 (Heterogeneous Computing Node Preferences and Heterogeneous Computing Node Preference List): Considering that the computing resources carried by heterogeneous computing nodes are limited, when multiple request processing tasks want to be deployed on the same heterogeneous computing node for SF processing, the heterogeneous computing node prioritizes providing services to its most preferred task. m The two request processing tasks Ω k and When it prefers task Ω k When, it is represented as Management and control nodes based on U m Preference, for the current waiting by U m All request processing tasks are sorted in descending order to construct U. m The preference list, i.e. in, It's U m The most preferred request task at present. It's U m The request task at the end of the current preference ranking.

[0072] Definition 5 (Quantity Limit): Based on the constraints of problem P1, at each scheduling time, the number of any number of SF instances is limited. For SF m,q Instance quantity limit; U m The maximum number of single-core CPU SF instances that can be supported is [number]. U m The maximum number of dual-core SF instances (CPU+FPGA and CPU+GPU) that can be supported is [number missing]. and U m The maximum number of SF instances that can be supported is [number]. At each scheduling time, when SF m,q The number of instances is less than, equal to or greater than At that time, SF m,q The current quantity limit status is referred to as incomplete, full, and overflow. When U m The number of dual-core SF instances supported by "CPU+FPGA" is less than, equal to, or greater than At that time, U m The quota status of a "CPU+FPGA" dual-core instance is referred to as incomplete, full, and overflow. m The number of dual-core SF instances supported by CPU+GPU is less than, equal to, or greater than At that time, U m The quota status of a "CPU+GPU" dual-core instance is referred to as incomplete, full, and overflow; when U m The total number of SF instances carried is less than, equal to or greater than At that time, U m The total instance limit status is referred to as incomplete, full, and overflow.

[0073] Definition 6 (Valid Match): This application defines a valid match as... Defined as a set A subset of, in which, Represents the set of SFs deployed in a heterogeneous computing cluster; for any task Ω k If a matching pair exists This indicates task Ω k By SF m,q To handle; if all of the following constraints are met, then matching will occur. It is simply a set of feasible matching pairs:

[0074] 1) For Any matching pair (Ω) k ,SF m,q ), SF m,q Must belong to task Ω k Acceptable SF;

[0075] 2)Ω k It can be scheduled to a maximum of one SF, that is

[0076] 3) For SF m,q In general, its quantity limit cannot exceed Right now

[0077] 4) For U m In terms of each scheduling moment, U m The number of single-core CPU SF instances created cannot exceed [number]. Right now U m The number of "CPU+FPGA" dual-core SF instances created cannot exceed [number missing]. Right now U m The number of dual-core SF instances (CPU+GPU) created cannot exceed [number missing]. Right now

[0078] 5) For U m In terms of each scheduling moment, U m The total number of SF instances created cannot exceed Right now

[0079] use Indicates a match In the middle, Ω k Scheduled to SF m,q Processing; using Indicates scheduling to SF m,q A set of request processing tasks; using Indicates scheduling to U m A set of request processing tasks; using Indicates scheduling to U m The request processing task set of the "CPU+FPGA" dual-core SF; using Indicates scheduling to U m The set of request processing tasks for the dual-core SF with "CPU+GPU".

[0080] Definition 7 (Blocking Pair): When a matching pair Obstruction Matching Stable, then, is called a match. A blocking pair is considered a blocking pair if it simultaneously meets the following three conditions:

[0081] 1) Right now It is a task Ω k Acceptable service features;

[0082] 2) Task Ω k No match was found (i.e.) Or compared to the service functionality currently assigned to it, i.e. More preference

[0083] 3) Only one of the following sub-conditions needs to be met:

[0084] (a) The current service limit is not yet reached. Also: If For single-core CPU SF, The current total instance limit is not yet full; if It is a dual-core SF with "CPU+FPGA". The current total instance limit and the "CPU+FPGA" dual-core SF instance limit are both not yet full; if It is a dual-core CPU+GPU SF. The current total instance quota and the "CPU+GPU" dual-core SF instance quota are both not yet full;

[0085] (b) The current service limit is not yet reached. Also: If For single-core CPU SF, The current total instance quota is full, compared to The middle class prefers to sort the tasks at the end of the list. Prefer Ω k ;if It is a dual-core SF with "CPU+FPGA". The current total instance quota is full, while the current quota for "CPU+FPGA" dual-core SF instances is not full. The middle class prefers to sort the tasks at the end of the list. Prefer Ω k ;if It is a dual-core CPU+GPU SF. The current total instance quota is full, while the current quota for "CPU+GPU" dual-core SF instances is not full. The middle class prefers to sort the tasks at the end of the list. Prefer Ω k ;if For the "CPU+FPGA" dual-core service function, The current quota for "CPU+FPGA" dual-core SF instances is full, and compared to... The preference is to sort the requests at the end of the order. Prefer Ω k ;if It is a dual-core CPU+GPU SF. The current quota for "CPU+GPU" dual-core SF instances is full, and compared to... The preference is to sort the requests at the end of the order. Prefer Ω k ;

[0086] (c) The current service limit is full. Meanwhile, relative to... The middle class prefers to sort the tasks at the end of the list. Prefer Ω k ;

[0087] Definition 8 (Stable Match): If a match is found... If there are no blocking pairs, then It is a stable match, in a stable match In this system, all request processing tasks can be scheduled to the optimal service function (SF) and receive services.

[0088] Definition 9 (Task Preference Criterion): To measure task Ω k For set A k Regarding the preference for service functions in the application, this application proposes a time-delay greedy preference criterion, specifically:

[0089] To measure task Ω k For set A k The service function preferences in the middle adopt As a quantitative task Ω k For SF m,q The utility value of preference, Represents Ω k By SF m,q The latency and utility value generated during instance processing The smaller, Ω k For SF m,q The more preferred; when task Ω k Facing two acceptable service functions SF m,q and At that time, if Then task Ω k Prefer SF m,q , represented as if Then, randomly select one of the two as the preferred service function;

[0090] The task satisfaction is the ranking of the service function that ultimately processes the request processing task in the task preference list. The higher the ranking, the higher the task satisfaction of the request processing task.

[0091] Definition 10 (Dual-Interval Preference Criterion): Service functions (SF) and heterogeneous computing nodes both belong to heterogeneous computing clusters and have the same objective: maximizing task completion rate and minimizing total task processing latency. This application stipulates that service functions (SF) and heterogeneous computing nodes have the same preference criterion and defines a dual-interval preference criterion, as follows:

[0092] 1) When a service function SF or heterogeneous computing node faces multiple request processing tasks simultaneously, the management control node divides these tasks into two preference intervals based on the length of the preference list for each request processing task: the first preference interval contains request processing tasks with a preference list length of 1, and these tasks are given priority in service, which helps to maximize the task completion rate; the second preference interval contains request processing tasks with a preference list length greater than 1, and these tasks can only be processed after the tasks in the first preference interval have been processed; compared to the request tasks in the second preference interval, the request tasks in the first preference interval are more favored.

[0093] 2) When there are multiple request processing tasks in the first preference interval, these request processing tasks are randomly sorted as the preference order of heterogeneous computing nodes and service functions SF.

[0094] 3) When there are multiple request tasks in the second preference interval, adopt... As a quantized heterogeneous computing node U m Service Functions SF m,q For task Ω located in the second preference interval k The preference utility value is specifically expressed as: in, For task Ω k By SF m,q The processing delay caused by the processing For task Ω k Depend on The processing delay caused by the processing, and at the same time, in task Ω k In the preference list and SF m,q Adjacent, and relative to SF m,q More task Ω k Preferences; therefore, when there are two request tasks Ω located in the second interval... k and At that time, if Then U m and SF m,q Prefer Ω k This preference criterion is beneficial for minimizing the total task processing latency; if... Then randomly select one of the two as U. m and SF m,q Preferred tasks.

[0095] Trilateral stable matching algorithm

[0096] The specific steps of the trilateral stable matching algorithm proposed in this application are as follows:

[0097] 1) The management and control node constructs a task preference list for each request processing task arriving in the previous scheduling slot based on the service functions (SF) already deployed on the heterogeneous computing nodes.

[0098] Assume a heterogeneous computing cluster consists of four heterogeneous computing nodes U1 to U3, with service function SF deployed on U1. 1,1 and SF 1,2 U2 deployed the service function SF 2,1 and SF 2,2 U3 deployed the service function SF 3,1There are currently 5 processing tasks, Ω1 to Ω5. Each task has acceptable service functionality on multiple heterogeneous computing nodes. Among them, Ω1 has acceptable service functionality SF. 1,1 and SF 2,1 The processing latency on Ω2 is 500 milliseconds and 800 milliseconds, respectively, and the service function SF is acceptable. 1,2 SF 2,2 and SF 3,1 The processing latency on Ω3 is 300 milliseconds, 400 milliseconds, and 800 milliseconds, respectively, and the service function SF is acceptable. 2,1 and SF 1,1 The processing latency is 200 milliseconds and 300 milliseconds, respectively. Ω4 provides acceptable service functionality SF. 3,1 and SF 2,1 The processing latency is 300 milliseconds and 600 milliseconds, respectively. Ω5 provides acceptable service functionality SF. 3,1 and SF 2,1 The processing latency is 300 milliseconds and 900 milliseconds. Based on the latency greedy preference criterion proposed in this application, the constructed task preference list is shown in Table 1.

[0099] Table 1 Request Task Preference List

[0100] Request task Task Preference List <![CDATA[Ω1]]> <![CDATA[{SF 1，1 ,SF 2，1 }]]> <![CDATA[Ω2]]> <![CDATA[{SF 1,2 ,SF 2,2 ,SF 3，1 }]]> <![CDATA[Ω3]]> <![CDATA[{SF 2，1 ,SF 1，1 }]]> <![CDATA[Ω4]]> <![CDATA[{SF 3,1 ,SF 2,1 }]]> <![CDATA[Ω5]]> <![CDATA[{SF 3,1 ,SF 2，1 }]]>

[0101] 2) The management control node traverses the preference list of each request processing task, constructs a set of tasks that may request services from each service function SF, and then constructs a preference list for each service function SF according to the dual-range preference criterion.

[0102] 3) The management and control node traverses the preference list of each service function SF and merges the preference lists of all service function SFs deployed on the same heterogeneous computing node into a single preference list. The merged preference list stores the set of tasks that may request services from the same heterogeneous computing node. Then, the preference list of each heterogeneous computing node is obtained by reordering the merged preference list.

[0103] 4) The management and control node determines the quantity limit of each heterogeneous computing node and service function SF based on the current idle computing resources of the heterogeneous computing cluster;

[0104] 5) The management and control node runs an iterative matching sub-algorithm based on the request processing task preference list, the service function SF preference list, the heterogeneous computing node preference list, and the quantity limit, and returns the matching results between the request processing task and the service function SF.

[0105] Furthermore, the steps for constructing a preference list for each SF are as follows:

[0106] 1) When the service function SF is at the end of a request processing task preference list, the request processing task is assigned to the first preference range of the service function SF.

[0107] As shown in Table 1, if task Ω1 requests service from SF at the end of its task preference list, it means that other service functions in the task preference list refuse to provide service. In this case, the requesting task has only one service function to choose from. Therefore, according to the above dual-interval preference criterion, the requesting task is located in the first preference interval of the service function.

[0108] 2) When the service function SF is not at the end of a request processing task preference list, the request processing task is assigned to the second preference interval of the SF, and the preference utility value of the request task for the service function SF is calculated.

[0109] 3) Based on the dual-interval preference criterion, construct the preference list for this service function SF.

[0110] Based on Table 1, the set of tasks that can potentially request services from each service function can be obtained. Then, the service function preference list can be constructed following the steps described above. This is to build the SF... 3,1 Taking the preference table as an example, as can be seen from Table 1, SF 3,1 All of these are acceptable service functions for tasks Ω2, Ω4, and Ω5, and all involve SF. 3,1 The possibilities for requesting services can be seen from the preference lists of Ω2, Ω4, and Ω5. When these three tasks are directed to SF... 3,1 When applying for services, if SF 3,1 If Ω2 is rejected, then Ω2 will no longer have any optional service functions, but Ω4 and Ω5 will still have SF. 2,1 Optional, therefore, according to the two-interval preference criterion, SF 3,1 I prefer Ω2. Also, Ω4 and Ω5 are preferred in SF. 2,1 and SF 3,1 The preference utility values ​​for the above processing are 300 milliseconds and 600 milliseconds, respectively. According to the two-interval preference criterion, relative to Ω4, SF 3,1 Preferring Ω5, therefore, SF 3,1 The preference list is {Ω2, Ω5, Ω4}. Similarly, the preference lists for other service functions can be obtained, as shown in Figure 2.

[0111] Table 2 Service Function Preference List

[0112] Service Functions Service feature preference list <![CDATA[SF 1，1 ]]> <![CDATA[{Ω3,Ω1} <!-- 10 -->]]> <![CDATA[SF 1，2 ]]> <![CDATA[{Ω2}]]> <![CDATA[SF 2,1 ]]> <![CDATA[{Ω1,Ω4,Ω5,Ω3}]]> <![CDATA[SF 2,2 ]]> <![CDATA[{Ω2}]]> <![CDATA[SF 3，1 ]]> <![CDATA[{Ω2,Ω5,Ω4}]]>

[0113] Furthermore, the step of reordering the merged preference list to obtain the preference list of heterogeneous computing nodes is as follows:

[0114] 1) Divide the request processing tasks in the merged preference list into two categories: one category is request processing tasks with a preference list length of 1, which are located in the first preference area of ​​the heterogeneous computing node; the other category is request processing tasks with a preference list length greater than 1, which are located in the second preference area of ​​the heterogeneous computing node.

[0115] 2) Based on the dual-interval preference criterion, the preference value of heterogeneous computing nodes for each request processing task located in the second preference interval is calculated;

[0116] 3) Based on the dual-interval preference criterion and the preference values ​​of heterogeneous computing nodes for request processing tasks, the merged preference list is reordered to obtain the preference list of heterogeneous computing nodes.

[0117] The following example, based on Table 2, illustrates the above steps using the construction of U3's preference list as an example. (SF...) 2,1 and SF 2,2 For SF deployed on U2, according to Table 2, their preference lists are merged to obtain a new preference list, namely {Ω1, Ω2, Ω3, Ω4, Ω5}. According to Table 1, tasks Ω1, Ω4, and Ω5 are located in SF respectively. 2,1 and SF 2,2 Therefore, Ω1, Ω4, and Ω5 are also located in the first preference region of U2; tasks Ω2 and Ω3 are located in SF respectively. 2,1 and SF 2,2 Therefore, tasks Ω2 and Ω3 are also located in the second preference region of U2. 2,1 The preference utility for Ω3 is 100 milliseconds, SF 2,2 The preference utility value for Ω2 is 400 milliseconds. Therefore, the preference utility values ​​for Ω3 and Ω2 for U2 are 100 milliseconds and 400 milliseconds, respectively. Thus, U2 prefers Ω2 more than Ω3. In summary, the preference list of U2 is shown in Table 3. Similarly, the preference lists of other heterogeneous computing nodes can be obtained.

[0118] Table 3. List of Heterogeneous Computing Node Preferences

[0119] Heterogeneous computing nodes Heterogeneous computing node preference list <![CDATA[U1]]> <![CDATA[{Ω3,Ω1,Ω2}]]> <![CDATA[U2]]> <![CDATA[{Ω1,Ω4,Ω5,Ω2,Ω3}]]> <![CDATA[U3]]> <![CDATA[{Ω2,Ω5,Ω4}]]>

[0120] Furthermore, the execution process of the iterative matching sub-algorithm is shown in Table 4, and the steps are as follows:

[0121] 1) Iterate through and check each request processing task, and select all tasks that "do not match the service function SF and whose preference list is not empty". If no task that meets the above conditions is selected, go to step 4); otherwise, go to step 2).

[0122] 2) For tasks that "no matching service function SF was found and its preference list is not empty", perform the following operations in sequence:

[0123] (a) Match the request processing task to the first preferred SF in its preference list and the heterogeneous computing node where the first preferred SF is deployed. At the same time, increment the matching task count of the first preferred SF and the matching task count of the heterogeneous computing node where the first preferred SF is deployed.

[0124] (b) Check the limit status of the first preferred SF. If it is overflowing, find the request processing task least preferred by the SF from the tasks currently matched with the first preferred SF according to the preference list of the first preferred SF, and remove its matching relationship with the SF and the heterogeneous computing node that deploys the SF. Decrease the matching task count of the SF and the heterogeneous computing node that deploys the SF by 1. At the same time, delete the SF from the preference list of unmatched tasks. Otherwise, do nothing.

[0125] (c) Check the quota status of the heterogeneous computing node deploying the first preferred SF. If the quota status of the "CPU+FPGA" dual-core instance on the heterogeneous computing node is overflowed and the total instance quota status is not overflowed, then according to the preference list of the heterogeneous computing node, find the least preferred request for the "CPU+FPGA" dual-core SF from the request processing tasks already matched on the heterogeneous computing node, and remove its matching relationship with the heterogeneous computing node. Decrement the matching task count of the "CPU+FPGA" dual-core SF and the heterogeneous computing node by 1 respectively. Then, delete the "CPU+FPGA" dual-core SF from the preference list of the unmatched tasks. If the quota status of the "CPU+GPU" dual-core instance on the heterogeneous computing node is overflowed and the total instance quota status is not overflowed, then according to the preference of the heterogeneous computing node... The system retrieves the least preferred request from the list of request processing tasks already matched on the heterogeneous computing node, identifies the "CPU+GPU dual-core SF" task, removes it from the matching list, decrements the matching count of both the "CPU+GPU dual-core SF" task and the heterogeneous computing node by 1, and then removes the "CPU+GPU dual-core SF" task from the preference list of the unmatched tasks. If the total instance limit of the heterogeneous computing node is overflowing, the system retrieves the least preferred request processing task from the list of request processing tasks already matched on the heterogeneous computing node, removes it from the matching list, and then removes all tasks following the least preferred request processing task from the preference list. Otherwise, no action is taken.

[0126] 3) Return to step 1);

[0127] 4) Returns the matching results of the request processing task and service function.

[0128] Table 4 Iterative Matching Sub-algorithm

[0129]

[0130]

[0131] Algorithm Analysis

[0132] The algorithm was analyzed in terms of stability, complexity, and the effectiveness of the two-interval preference criterion.

[0133] Algorithm stability analysis

[0134] Theorem 1: The resource allocation and task scheduling algorithm proposed in this application can obtain a stable matching solution.

[0135] Proof: In the algorithm proposed in this application, each task first matches itself with the most preferred service function (SF) in its preference list. If rejected, the task removes the SF from its preference list and continues to request services from the next preferred SF until no service is rejected or the preference list is empty. Simultaneously, each requested SF and heterogeneous computing node rejects requests exceeding the limit based on their own preferences and the specified service instance limit. Clearly, after the algorithm in this application finishes running, it outputs a set of matching pairs between each request processing task and the requested service. It meets definition 6 and is a valid match. According to definition 8, if no match exists If there are blocking pairs, then it proves a match. It is a stable matching. Assume (Ω) k ,SF m,q ) is a match One of the matching pairs, namely And there exists a blocking pair of it. According to condition 1) of Definition 7, which satisfies the blocking pair, It must be Ω k Acceptable service functionality. Therefore, blocking pairs must exist among the temporary matching pairs and unmatched pairs deleted during algorithm execution. A temporary matching pair refers to a pair formed by each requesting task and the SFs in its task preference list that refuse to provide service during the algorithm's execution; an unmatched pair refers to a pair formed by a task whose preference list is not empty after the algorithm's execution and each remaining SF in that task's current preference list. We will prove below that neither temporary matching pairs nor unmatched pairs are blocking pairs:

[0136] 1) Assumption This is a temporary match that was deleted, which means that during the algorithm's execution, Refuse to perform the task Ω k Provide services, based on the algorithm execution process, Ω k Reasons for rejection include: a) Service limits have been reached, and compared to Ω k , Prefer b) Prioritize tasks ranked at the end of the list; The service limit has not been reached, but the heterogeneous computing nodes... The total instance limit has been reached, indicating that compared to Ω k , Prefer c) Service limits and The total instance limit has not been reached, but It is a dual-core SF with "CPU+FPGA" and The quota for "CPU+FPGA" dual-core instances on Ω is full. Meanwhile, compared to Ω... m,k , Prefer The request task at the end of the preference sort; d) Service limits and The total instance limit has not been reached, but It is a dual-core SF with "CPU+GPU" and The quota for dual-core "CPU+GPU" instances on Ω is full. Meanwhile, compared to Ω... m,k , Prefer The preference is to sort the requests at the end of the list. Clearly, If any subcondition of condition (3) in definition 7 is not met, it is not a blocking pair.

[0137] 2) Assumption It is a non-matching pair, indicating It is Ω k An unrequested SF in the preference list, during the algorithm's execution, Ω k The system first requests services from the top-ranked service provider in its task preference list. If that is rejected, it then requests services from the next service providers in the list. Once Ω... k If accepted, services will not be requested from subsequent SFs. Therefore, compared to Ω k It prefers the SF that currently accepts its request, i.e. So, It does not meet condition 2) in Definition 7, and is not a blocking pair. If Explanation of Ωk All candidate SFs in the preference list refuse to provide services to it, therefore, when the algorithm finishes running, Ω k The preference list is empty, meaning there are no unmatched pairs, which contradicts the assumption.

[0138] In summary, the algorithm proposed in this application can obtain a stable matching solution, thus proving Theorem 1.

[0139] Complexity Analysis

[0140] Theorem 2: The tri-sided stable matching algorithm converges after a finite number of iterations, and its worst-case time complexity is O(min{M,K}).

[0141] Proof: Consider that the length of the preference list for each request processing task is finite, with a maximum length of M, which is the number of computing nodes in the heterogeneous computing cluster. Also, the number of request processing tasks K in each time slot is finite. Therefore, as shown in Table 4, after a maximum of min{M,K} iterations, the algorithm can obtain the matching result between the request processing tasks and the service functions. Thus, the worst-case time complexity is O(min{M,K}), proving Theorem 2.

[0142] Effectiveness analysis of the two-interval preference criterion

[0143] To balance maximizing objective function F1 and minimizing F2, this application designs a dual-interval preference criterion for heterogeneous computing nodes and service functions (SF) in Definition 10. Clearly, the first interval preference criterion is effective for maximizing objective function F1. This section primarily analyzes the effectiveness of the second interval preference criterion for minimizing F2, specifically, the preference utility value of heterogeneous computing nodes when faced with multiple request processing tasks with preference lists longer than 1. Big task Ω k This is beneficial for minimizing F2. The proof and analysis follow.

[0144] Suppose there are two tasks Ω with preference lists greater than 1. k and Their preferred SF is SF. m,q But U m The current resource can only serve one task; the other task can only obtain service from the second-preference SF. Assume task Ω... k and The second preference SF is SF m',q' and SF m”,q” And task Ω k The time delays processed on its first preference and second preference SF are respectively and Task The time delays processed on its first preference and second preference SF are respectively and According to definition 10, at this time, SF m,q For task Ω k and The preference utility value is expressed as:

[0145]

[0146]

[0147] Based on the dual-interval preference criterion proposed in this application, it is assumed that... SF m,q Select as task Ω k Provide services, tasks Only the second preferred SF can be selected m”,q” The above processing. So, task Ω k and The sum of processing delays is expressed as:

[0148]

[0149] Conversely, if the preference criteria proposed in this application are not followed, namely SF m,q For the task Provide services, tasks Ω k In its second preference SF m',q' The above processing is underway. At this point, task Ω... m,k and The sum of processing delays is expressed as:

[0150]

[0151] According to formulas (12) to (15), the processing delay difference under the two preference criteria can be obtained, expressed as:

[0152]

[0153] Based on the above Based on the assumptions, we can conclude that Δ < 0. This indicates that the preference criterion proposed in this application makes the sum of the processing delays of the two tasks smaller, which is beneficial to minimizing F2. In particular, the greater the difference between heterogeneous computing nodes, the larger the difference in |Δ|, and the more obvious the effectiveness will be.

[0154] Simulation Result Analysis

[0155] To evaluate the performance of this system, this application conducted a simulation comparison analysis with four comparative algorithms.

[0156] Comparison Algorithm

[0157] For ease of description, the method proposed in this application is called the RT2SM method, and the two comparison methods are called RanS and MiWeGS. The comparison methods are described in detail below:

[0158] 1) RanS method: Random service algorithm, that is, the management control node randomly selects a SF from the list of request processing task preferences for each request and sends a request to that SF. If it is rejected, it continues to randomly select a SF that has never been rejected and continues to send a request until the request is accepted or there is no SF to choose from.

[0159] 2) MiWeGS method: Greedy service algorithm, in which the management control node selects the most preferred SF from the preference list of the task and sends a request to the SF. If it is rejected, it continues to select the next most preferred SF from the SFs that have never been rejected and continues to send requests until the request is accepted or there are no SFs available.

[0160] Comparison indicators

[0161] This application conducted simulation analysis on three aspects: task completion rate, the ratio of total task processing latency, and the task satisfaction ratio. The specific meanings of these indicators are as follows:

[0162] 1) Task completion rate: The ratio of the number of successfully processed tasks to the total number of tasks requested for processing;

[0163] 2) Ratio of total task processing latency: In order to more clearly compare the performance differences of different methods in terms of total task processing latency, this application uses the total task processing latency of the MiWeGS method as the benchmark, and divides the total task processing latency of other methods by it to obtain the ratio of total task processing latency. Obviously, the ratio of the MiWeGS method is equal to 1.

[0164] 3) Task satisfaction ratio: The task satisfaction is the ranking of the service function that ultimately processes the request processing task in the task preference list. The higher the ranking, the higher the task satisfaction of the request processing task. The same request processing task will have different task satisfaction when processed on different SFs. This application uses the task satisfaction of each task in the MiWeGS algorithm as the benchmark and compares the task satisfaction of other methods with it.

[0165] Simulation Result Analysis

[0166] Figure 4 The task completion rates under different methods are shown. The results indicate that the RT2SM method proposed in this application has the highest task completion rate, especially as the number of tasks gradually increases, it still maintains a high completion rate. This is mainly because in the dual-interval preference criterion proposed in this application, only one task with an acceptable free choice (SF) is prioritized for service, thus effectively improving the task completion rate.

[0167] Figure 5 The total task processing latency of different methods is shown. We can see that the ratio of the total task processing latency in RT2SM and MiWeGS is significantly lower than that in the RanS algorithm. This is mainly because both algorithms strive to request the most preferred SF for each task, while the RanS algorithm is random in selecting the requested SF for each task. In addition, we can also see that the total task processing latency of RT2SM is smaller than that of MiWeGS, and this trend becomes more obvious as the number of tasks increases. This is mainly because RT2SM adopts the dual-interval preference criterion proposed in this application, which prioritizes tasks with large differences in task processing latency due to different preferred SF selections.

[0168] Figure 6 The task satisfaction ratios of different methods are shown. The results show that the task satisfaction of the proposed algorithm RT2SM consistently maintains a 20% improvement compared to the MiWeGS algorithm. This is mainly because RT2SM adopts a matching game algorithm and achieves stable matching, allowing all tasks to simultaneously obtain the best possible SF.

Claims

1. A method for resource management and task scheduling of heterogeneous computing clusters oriented towards reconfigurable hardware accelerators, characterized in that... Includes the following steps: 1) The management and control node divides time into equally spaced scheduling time slots; 2) During the scheduling time, the management and control node collects the request processing tasks that arrived in the previous scheduling time slot and the currently idle computing resources of the heterogeneous computing cluster. The scheduling time refers to the end time of each scheduling time slot. 3) The management and control node establishes a three-sided matching game framework oriented towards request processing tasks, service functions (SF), and heterogeneous computing nodes; 4) Management and control nodes are based on the optimization objectives and the preferences of all parties. 5) The management and control node runs a trilateration stable matching algorithm to match tasks with service functions; 6) The management and control node will offload the request processing task to the heterogeneous computing node where the matching service function is located based on the matching result; 7) Wait for the next scheduling time slot to arrive, and then repeat steps 2) to 6) to schedule the request processing tasks that arrive in each scheduling time slot; The heterogeneous computing cluster comprises several heterogeneous computing nodes with deployed service functions (SF) and a management and control node, all interconnected via high-speed Ethernet; (Definition) This is represented as a heterogeneous computing resource group. Indicates the first Heterogeneous computing nodes , This indicates the number of heterogeneous computing nodes within the heterogeneous computing cluster. Service functions (SFs) deployed on heterogeneous computing nodes handle computing tasks by creating instances. Based on the computing resources consumed in creating instances, service function SFs are divided into three categories: CPU single-core SFs, "CPU+FPGA" dual-core SFs, and "CPU+GPU" dual-core SFs. Among them, the CPU single-core SF instance only occupies the CPU core and is used to handle some low-complexity computing tasks; the "CPU+FPGA" or "CPU+GPU" dual-core SF instance not only needs to occupy the CPU core, but also requires the FPGA or GPU to assist in running complex algorithms and is used to handle some computationally intensive computing tasks. Furthermore, based on the ability of Service Functions (SFs) to handle different types of tasks, each of the above-mentioned Service Functions (SFs) is further divided into several different types, defined as follows: Represents heterogeneous computing clusters Deployed in China A single-core CPU SF, defined Represents heterogeneous computing clusters Deployed in China A type of "CPU+FPGA" dual-core SF, defined Represents heterogeneous computing clusters Deployed in China Finally, the definition of a dual-core CPU+GPU SF is as follows: Represents heterogeneous computing clusters All deployed service functions are of SF type, i.e., equation Always true; The heterogeneous computing nodes support CPU, GPU, and FPGA computing resources and deploy several types of service functions (SFs); [Definition] The idle computing resources available at the scheduling time include One CPU core, FPGA and One GPU, defined express The service functions deployed on the SF set, among which, Always true express The first deployment SF types of service functions, totaling Types; The management and control node monitors the resource usage of all heterogeneous computing nodes in real time via Ethernet and offloads request processing tasks to the optimal heterogeneous computing point for processing.

2. The method for resource management and task scheduling of heterogeneous computing clusters for reconfigurable hardware accelerators as described in claim 1, characterized in that, The management and control node continuously receives request processing tasks and monitors the idle resource status within the heterogeneous computing cluster in each scheduling time slot; within each scheduling time slot, the received request processing tasks are represented as a set. ,in, Indicates the first Each request processing task , This indicates the number of request processing tasks received.

3. The method for resource management and task scheduling of heterogeneous computing clusters for reconfigurable hardware accelerators as described in claim 1, characterized in that, The three-sided matching game framework constructed by the management and control nodes includes the following definitions: Acceptable service features SF: When It belongs to the task When requesting a service function type, for a task In other words, It is acceptable, defined. Indicates task The set of acceptable service functions (SF); Request processing task preferences and request processing task preference list: When faced with multiple acceptable service functions (SFs) deployed on different heterogeneous computing nodes, each request processing task wants to obtain service from its most preferred service function SF. face and When two acceptable service features are available (SF), the preference is higher. When, it is represented as Management and control nodes are based on tasks Preferences Sort the data in descending order to construct a preference list for acceptable service functions (SFs) deployed on different heterogeneous computing nodes. ,in, It is a task Most preferred service features SF It is a task The last SF in the preference ranking; Service Function SF Preferences and Service Function SF Preference List: When multiple request processing tasks want to be processed by the same SF, the requested service function SF prioritizes providing services to the task it most prefers. Facing two request processing tasks and When they prefer tasks When, it is represented as The management and control node, based on the service function (SF) preference, assigns the currently waiting [service] to [the appropriate service]. All request processing tasks are sorted in descending order and then built. The preference list, i.e. ,in, yes The most preferred request processing task at present. yes The request processing task at the end of the current preference sort; Heterogeneous compute node preferences and a list of heterogeneous compute node preferences: When multiple request processing tasks want to be handled by the service function SF deployed on the same heterogeneous compute node, the heterogeneous compute node prioritizes providing services to the task it most prefers. The two request processing tasks and When they prefer tasks When, it is represented as Management and control nodes are based on Preference, for the current waiting by All request processing tasks are sorted in descending order and then built. The preference list, i.e. ,in, yes The most preferred request task at present. yes The request task at the end of the current preference ranking; Quantity Limit: At each scheduling time, there is a limit to the number of instances of any service function (SF). for There is a limit to the number of instances; additionally, at each scheduling time, the number of service instances that each heterogeneous computing node can support is also limited, i.e. The maximum number of single-core CPU SF instances that can be supported is [number]. , The number of dual-core SF instances (CPU+FPGA) and dual-core SF instances that can be supported are respectively... and , The maximum number of SF instances that can support all service functions is [number]. At each scheduling time, when The number of instances is less than, equal to or greater than hour, The current quantity limit status is called incomplete, full, and overflow. The number of dual-core SF instances supported by "CPU+FPGA" is less than, equal to, or greater than hour, The quota status of a "CPU+FPGA" dual-core SF instance is called incomplete, full, and overflow. The number of dual-core SF instances supported by "CPU+GPU" is less than, equal to, or greater than hour, The quota status of a "CPU+GPU" dual-core SF instance is called incomplete, full, and overflow; when The total number of SF instances supporting the service functions is less than, equal to, or greater than hour, The total instance limit status is called incomplete, full, and overflow; Valid match: A valid match Defined as a set A subset of, for any task If a matching pair exists This indicates the task. Depend on To handle this, if all of the following constraints are met, then matching will occur. It is simply a set of feasible matching pairs: 1) For Any matching pair in , Must belong to the task Acceptable SF; 2) It can be scheduled to a maximum of one service function (SF), that is ; 3) For In general, its quantity limit cannot exceed ,Right now ; 4) For In terms of each scheduling moment, The number of single-core CPU SF instances created cannot exceed [number]. ,Right now ; The number of "CPU+FPGA" dual-core SF instances created cannot exceed [number missing]. ,Right now ; The number of dual-core SF instances (CPU+GPU) created cannot exceed [number missing]. ,Right now ; 5) For In terms of each scheduling moment, The total number of SF instances created cannot exceed [number]. ,Right now ; use Indicates a match middle, Scheduled to Processing; using Indicates scheduling to A set of request processing tasks; using Indicates scheduling to A set of request processing tasks; using Indicates scheduling to The request processing task set of the "CPU+FPGA" dual-core SF; using Indicates scheduling to The set of request processing tasks for dual-core SF with "CPU+GPU"; Blocking pair: When a matching pair Obstructing Matching Stable, then, is called a match. A blocking pair is considered a blocking pair if it simultaneously meets the following three conditions: 1) ,Right now It is a task Acceptable service features; 2) Task No match was found at this time. Or compared to the current match More preference ; 3) Only one of the following sub-conditions needs to be met: (a) The current service limit is not yet reached. Also: If For single-core CPU SF, The current total instance limit is not yet full; if It is a dual-core SF with "CPU+FPGA". The current total instance limit and the "CPU+FPGA" dual-core SF instance limit are both not yet full; if It is a dual-core CPU+GPU SF. The current total instance quota and the "CPU+GPU" dual-core SF instance quota are both not yet full. (b) The current service limit is not yet reached. Also: If For single-core CPU SF, The current total instance quota is full, compared to The middle class prefers to sort the tasks at the end of the list. Prefer ;if It is a dual-core SF with "CPU+FPGA". The current total instance quota is full, while the current "CPU+FPGA" dual-core SF instance quota is not full. The middle class prefers to sort the tasks at the end of the list. Prefer ;if It is a dual-core CPU+GPU SF. The current total instance quota is full, while the current "CPU+GPU" dual-core SF instance quota is not full. The middle class prefers to sort the tasks at the end of the list. Prefer ;if It is a dual-core SF with "CPU+FPGA". The current quota for "CPU+FPGA" dual-core SF instances is full, and compared to... The preference is to sort the requests at the end of the order. Prefer ;if It is a dual-core CPU+GPU SF. The current quota for "CPU+GPU" dual-core SF instances is full, and compared to... The preference is to sort the requests at the end of the order. Prefer ; (c) The current service limit is full. Meanwhile, relative to... The middle class prefers to sort the tasks at the end of the list. Prefer ; Stable matching: If a match is found If there are no blocking pairs, then It is a stable match.

4. The method for resource management and task scheduling of heterogeneous computing clusters for reconfigurable hardware accelerators as described in claim 1, characterized in that, The preference criteria for each party include a latency-greedy preference criterion for request processing tasks and a dual-interval preference criterion for heterogeneous computing nodes and service functions (SF). The specific delay-based greedy preference criterion is as follows: To measure the task For sets The service function preferences in the middle adopt As a quantitative task right The utility value of preference, express Depend on The latency and utility value generated during instance processing The smaller, right The more preferred; when the task Facing two acceptable service functions and At that time, if Then the task Prefer , represented as ;if Then, randomly select one of the two as the preferred service function; Task satisfaction is the ranking of the service function SF that ultimately processes the request processing task in the task preference list. The higher the ranking, the higher the task satisfaction of the request processing task. The specific dual-interval preference criterion is as follows: 1) When a service function SF or heterogeneous computing node faces multiple request processing tasks simultaneously, the management control node divides these tasks into two preference intervals based on the length of the preference list for each request processing task: the first preference interval contains request processing tasks with a preference list length of 1, and these tasks are given priority in service, which helps to maximize the task completion rate; the second preference interval contains request processing tasks with a preference list length greater than 1, and these tasks can only be processed after the tasks in the first preference interval have been processed; compared to the request tasks in the second preference interval, the request tasks in the first preference interval are more favored. 2) When there are multiple request processing tasks in the first preference interval, these request processing tasks are randomly sorted as the preference order of heterogeneous computing nodes and service functions SF. 3) When there are multiple request tasks in the second preference interval, adopt... As a quantization heterogeneous computing node Service Functions For tasks located in the second preference interval The preference utility value is specifically expressed as: ,in, For the task Depend on The processing delay caused by the processing For the task Depend on The processing delay caused by the processing, and at the same time, in the task In the preference list and Adjacent, and relative to , More task Preferences; therefore, when there are two request tasks located in the second interval... and At that time, if ,but and Prefer This preference criterion helps to minimize the total task processing latency; If it appears Then, randomly select one of the two as... and Preferred tasks.

5. The method for resource management and task scheduling of heterogeneous computing clusters for reconfigurable hardware accelerators as described in claim 1, characterized in that, The optimization objectives include maximizing the task completion rate and minimizing the total task processing latency.

6. The method for resource management and task scheduling of heterogeneous computing clusters for reconfigurable hardware accelerators as described in claim 1, characterized in that, The trilateral stable matching algorithm specifically includes the following steps: 1) The management and control node constructs a task preference list for each request processing task arriving in the previous scheduling slot based on the service functions (SF) already deployed on the heterogeneous computing nodes. 2) The management control node traverses the preference list of each request processing task, constructs a set of tasks that may request services from each service function SF, and then constructs a preference list for each service function SF according to the dual-range preference criterion. 3) The management and control node traverses the preference list of each service function SF and merges the preference lists of all service function SFs deployed on the same heterogeneous computing node into a single preference list. The merged preference list stores the set of tasks that may request services from the same heterogeneous computing node. Then, the preference list of each heterogeneous computing node is obtained by reordering the merged preference list. 4) The management and control node determines the quantity limit of each heterogeneous computing node and service function SF based on the current idle computing resources of the heterogeneous computing cluster; 5) The management and control node runs an iterative matching sub-algorithm based on the request processing task preference list, the service function SF preference list, the heterogeneous computing node preference list, and the quantity limit, and returns the matching results between the request processing task and the service function SF.

7. The method for resource management and task scheduling of heterogeneous computing clusters for reconfigurable hardware accelerators as described in claim 6, characterized in that, Build a preference list for each service function SF, including the following steps: 1) When the service function SF is at the end of a request processing task preference list, the request processing task is assigned to the first preference range of the service function SF. 2) When the service function SF is not at the end of a request processing task preference list, the request processing task is assigned to the second preference interval of the service function SF, and the preference utility value of the request processing task for the service function SF is calculated. 3) Based on the dual-interval preference criterion, construct the preference list for this service function SF.

8. The method for resource management and task scheduling of heterogeneous computing clusters for reconfigurable hardware accelerators as described in claim 6, characterized in that, The preference list for heterogeneous computing nodes is obtained by reordering the merged preference list, specifically including the following steps: 1) Divide the request processing tasks in the merged preference list into two categories: one category is request processing tasks with a preference list length of 1, which are located in the first preference area of ​​the heterogeneous computing node; the other category is request processing tasks with a preference list length greater than 1, which are located in the second preference area of ​​the heterogeneous computing node. 2) Based on the dual-interval preference criterion, the preference value of heterogeneous computing nodes for each request processing task located in the second preference interval is calculated; 3) Based on the dual-interval preference criterion and the preference values ​​of heterogeneous computing nodes for request processing tasks, the merged preference list is reordered to obtain the preference list of heterogeneous computing nodes.

9. The method for resource management and task scheduling of heterogeneous computing clusters for reconfigurable hardware accelerators as described in claim 6, characterized in that, The iterative matching sub-algorithm specifically includes the following steps: 1) Iterate through and examine each request processing task, selecting all tasks that "do not match the service function SF and whose preference list is not empty". If no task matching the above condition is selected, proceed to step 4); otherwise, proceed to step 2). 2) For tasks that "no matching service function SF was found and its preference list is not empty", perform the following operations in sequence: (a) Match the request processing task to the first preferred SF in its preference list and the heterogeneous computing node where the first preferred SF is deployed. At the same time, increment the matching task count of the first preferred SF and the matching task count of the heterogeneous computing node where the first preferred SF is deployed. (b) Check the limit status of the first preference SF. If it is overflowing, find the request processing task least favored by the first preference SF from the tasks currently matched with the first preference SF according to the preference list of the first preference SF, and remove its matching relationship with the first preference SF and the heterogeneous computing node that deploys the first preference SF. Decrease the matching task count of the first preference SF and the heterogeneous computing node that deploys the first preference SF by 1. At the same time, delete the first preference SF from the preference list of unmatched tasks. Otherwise, do nothing. (c) Check the quota status of the heterogeneous computing node deploying the first preferred SF. If the quota status of the "CPU+FPGA" dual-core instance of the heterogeneous computing node is overflowed and the total instance quota status is not overflowed, then according to the preference list of the heterogeneous computing node, find the least preferred request for the "CPU+FPGA" dual-core SF from the request processing tasks that have been matched to the heterogeneous computing node, and remove its matching relationship with the heterogeneous computing node. Decrement the matching task count of the "CPU+FPGA" dual-core SF and the heterogeneous computing node by 1 respectively. Then, delete the "CPU+FPGA" dual-core SF from the preference list of the unmatched tasks. If the quota status of the "CPU+GPU" dual-core instance of the heterogeneous computing node is overflowed and the total instance quota status is not overflowed, then according to the preference of the heterogeneous computing node... The system retrieves the least preferred request "CPU+GPU dual-core SF" task from the list of request processing tasks already matched on the heterogeneous computing node, removes its matching relationship with the heterogeneous computing node, decrements the matching task count of both the "CPU+GPU dual-core SF" task and the heterogeneous computing node by 1, and then removes the "CPU+GPU dual-core SF" task from the preference list of the unmatched tasks. If the total instance limit status of the heterogeneous computing node is overflowing, the system retrieves the least preferred request processing task from the list of request processing tasks already matched on the heterogeneous computing node, removes its matching relationship with the heterogeneous computing node, and then removes all tasks following the least preferred request processing task from the preference list of the heterogeneous computing node. Otherwise, no operation is performed. 3) Return to step 1); 4) Return the matching results of the request processing task and service function SF.

Images