Hierarchical resource management system and method for computing tasks in parallel computing processors

Abstract

The application discloses a layered resource management system and method for computing tasks in a parallel computing processor, and relates to the technical field of processors and resource management. The system is designed by a layered architecture of a cluster-level first resource manager and a processing unit-level second resource manager. The first resource manager maintains first execution state information of computing task dimensions, the second resource manager maintains second execution state information of processing unit internal subtask dimensions and the final available credit value of the processing unit. After the upstream scheduler combines the multi-dimensional state information fed back by the two-level managers to uniformly complete the task execution condition judgment and then issues the target resource request, the global computing task state management and the single processing unit internal subtask resource control can be decoupled, the phenomenon of task scheduling failure or resource over-allocation caused by resource information loss can be reduced, and the reliability and resource utilization efficiency of the overall task scheduling of the parallel computing processor can be improved.

Description

Technical Field

[0001] This invention relates to the fields of processor and resource management technology, and in particular to a hierarchical resource management system and method for computing tasks in a parallel computing processor. Background Technology

[0002] During the task scheduling and execution of a parallel computing processor, a centralized task scheduling system can break down a complete computational task from upstream input into several independent computational blocks, and distribute the execution threads corresponding to each computational block to multiple processing units for parallel execution. The normal operation of a computational block relies on block-level shared synchronization resources to complete the synchronous communication and cooperative computation of threads within the block. For example, the block has built-in barrier resources. After the entire execution process of a single computational block is completed, the corresponding synchronization resources need to be released and reclaimed in a timely manner to ensure that subsequent new computational blocks can successfully reuse this part of the hardware resources. This supports the parallel computing processor in continuously, efficiently, and iteratively scheduling and running multiple batches of computational tasks.

[0003] Existing parallel computing processors generally adopt a single centralized resource management architecture for resource management and task scheduling, without setting up a hierarchical and refined resource management mechanism. All core tasks, such as global task tracking and statistics, processing unit resource status query, multi-task resource management, and synchronous resource reclamation verification, are all completed by a single module. At the same time, the real-time subtask running status and idle resource balance of the processing unit cannot be maintained independently and refined. Scheduling decisions mainly rely on the round-trip response of passive resource query messages, lacking proactive, real-time, and multi-dimensional resource capability feedback channels. The synchronous resource reclamation process is highly coupled with the task table release process. The overall resource management model is hierarchical and highly coupled.

[0004] Limited by a single centralized resource management architecture, existing technologies suffer from several technical shortcomings that urgently need to be addressed. First, the synchronous resource invalidation operation is strongly bound to the release of block tracking entries. The entry can only be released after all remote processing units have returned invalidation responses. The round-trip latency of the interconnection network continuously occupies block tracking entries, causing the synchronous resource invalidation delay to block resource release, significantly reducing tracking table utilization and computational block scheduling throughput. Second, the scheduler relies on passively querying messages to obtain the resource status of processing units. The round-trip latency of these queries leads to delayed resource availability assessment results, failing to meet the efficient scheduling requirements of quickly starting the first batch of threads in idle processing units, resulting in poor real-time scheduling decisions. Third, when multiple computational tasks share the same processing unit, the lack of a task-granular flight thread counting and tracking mechanism prevents fine-grained task-level resource throttling and isolation, easily leading to situations where a single task excessively preempts hardware resources, resulting in insufficient resource management precision and reliability of multi-task parallel scheduling. Summary of the Invention

[0005] This invention provides a hierarchical resource management system and method for computing tasks in a parallel computing processor, in order to solve the problems of delayed release of synchronous resources, lagging resource availability assessment, poor resource isolation effect in multi-task scenarios, high processing pressure of a single management module, insufficient accuracy of resource scheduling, and high degree of hierarchical coupling.

[0006] According to one aspect of the present invention, a hierarchical resource management system for computing tasks in a parallel computing processor is provided, comprising: a plurality of first-level resource managers disposed at a cluster level and a plurality of second-level resource managers disposed at a processing unit level; the processing unit level is configured with a plurality of processing units, each second-level resource manager is configured with one processing unit, and each second-level resource manager is used to manage the corresponding configured processing unit; each first-level resource manager establishes a communication connection with a matched second-level resource manager through a standardized request-response interface; each first-level resource manager determines a matched second-level resource manager through a processing unit mask;

[0007] The first execution status information of each computing task currently in execution is maintained in real time in the first-level resource manager, and the second execution status information of each type of subtask currently in execution in the managed processing unit, as well as the final available credit value of the managed processing unit, are maintained in real time in the second-level resource manager.

[0008] The first-level resource manager is used to receive resource requests for target computing tasks sent by the upstream scheduler, return first execution status information to the upstream scheduler, and initialize the first execution status information corresponding to the target computing task when receiving the target resource request sent by the upstream scheduler; and update the matching first execution status information according to the execution completion information of each target subtask fed back by the target processing unit to the first-level resource manager.

[0009] The second-level resource manager is used to receive resource requests for target computing tasks sent by the upstream scheduler, return second execution status information and the final available credit value of the target processing unit matching the target computing task to the upstream scheduler, and, based on the received target resource requests sent by the upstream scheduler, instruct the target processing unit to allocate target execution resources to the target computing task and then execute various types of target subtasks in the target computing task based on the target execution resources; and, based on the execution completion information of each target subtask fed back by the target processing unit to the second-level resource manager, update the matching second execution status information and the final available credit value; wherein, the target resource request is sent by the upstream scheduler when it determines that the target computing task meets the execution conditions based on the first execution status information, the second execution status information and the final available credit value of each target processing unit;

[0010] The first-level resource manager is further configured to, after determining that all target subtasks in the target computing task have been executed based on the currently maintained first execution status information, notify the upstream scheduler of the task completion status of the target computing task, and issue instructions to the target processing unit according to the processing unit mask to trigger the target processing unit to perform a local shared synchronization resource invalidation operation on the target execution resources, and, after determining that the task completion status notification has been completed and all target processing units have successfully completed the synchronization resource invalidation operation, determine that the target computing task has been executed.

[0011] According to another aspect of the present invention, a hierarchical resource management method for computing tasks in a parallel computing processor is provided, executed by a first-level resource manager in a hierarchical resource management system for computing tasks in a parallel computing processor as described in any embodiment of the present invention, the method comprising:

[0012] Maintain the first execution status information of each computing task currently in execution in real time;

[0013] When receiving a resource request for a target computing task sent by the upstream scheduler, the system returns first execution status information to the upstream scheduler, and when receiving a target resource request sent by the upstream scheduler, it completes the initialization of the first execution status information corresponding to the target computing task; wherein, the target resource request is sent by the upstream scheduler when it determines that the target computing task meets the execution conditions based on the first execution status information, the second execution status information and the final available credit value of each target processing unit;

[0014] Upon receiving the execution completion information of each target subtask from the target processing unit, the matching first execution status information is updated based on the execution completion information;

[0015] After determining that all target subtasks in the target computing task have been executed based on the currently maintained first execution status information, the upstream scheduler is notified of the task completion status of the target computing task, and an instruction is issued to the target processing unit according to the processing unit mask to trigger the target processing unit to perform a local shared synchronization resource invalidation operation on the target execution resources.

[0016] The execution of the target computation task is considered complete after the notification confirms the completion of the task and all target processing units have successfully completed the synchronization resource invalidation operation.

[0017] According to another aspect of the present invention, a hierarchical resource management method for computing tasks in a parallel computing processor is provided, executed by a second-level resource manager in a hierarchical resource management system for computing tasks in a parallel computing processor as described in any embodiment of the present invention, the method comprising:

[0018] Maintain in real time the second execution status information of each type of subtask currently in execution in the managed processing unit, as well as the final available credit value of the managed processing unit;

[0019] Receive the resource request for the target computing task sent by the upstream scheduler, and return the second execution status information and the final available credit value of the target processing unit that matches the target computing task to the upstream scheduler;

[0020] After receiving a target resource request sent by the upstream scheduler, the target processing unit is instructed to allocate target execution resources to the target computing task, and then executes various types of target subtasks in the target computing task based on the target execution resources; wherein, the target resource request is sent by the upstream scheduler when it determines that the target computing task meets the execution conditions based on the first execution status information, the second execution status information and the final available credit value of each target processing unit;

[0021] The second execution status information and the final available credit value are updated based on the execution completion information of each target subtask fed back by each target processing unit.

[0022] The system of this invention employs a layered architecture design with a first-level resource manager at the cluster level and a second-level resource manager at the processing unit level. The first-level resource manager maintains the first execution status information of the computational task dimension, while the second-level resource manager maintains the second execution status information of the sub-task dimension within the processing unit, as well as the final available credit value of the processing unit. The upstream scheduler combines the multi-dimensional status information fed back by the two levels of managers to uniformly determine the task execution conditions before issuing the target resource request. This decouples global computational task status management from the resource management of sub-tasks within a single processing unit, avoiding the excessive processing pressure caused by a single manager simultaneously handling global task scheduling and fine-grained sub-task statistics. Furthermore, the two levels of resource managers respectively report the actual running status of their corresponding dimensions to the upstream scheduler, relying on the real-time output of the second-level resource manager. The final available credit value eliminates the need for additional queries from the scheduler, overcoming the lag in resource availability assessment. This allows the upstream scheduler to obtain a more complete and accurate profile of cluster resources, reducing task scheduling failures or resource over-allocation caused by missing resource information. Simultaneously, the first-level resource manager triggers the synchronous resource invalidation operation only after all subtasks have been completed, and waits for the task completion notification and the successful execution of all synchronous resource invalidation operations in all processing units before determining the computation task's completion. This ensures reliable reclamation of shared synchronous resources, preventing data inconsistencies and resource pollution caused by releasing resources before tasks are fully completed. The standardized request-response interface facilitates interaction between the two-level managers, also aiding in decoupling and integration between different modules, thus improving the overall reliability and resource utilization efficiency of parallel computing processor task scheduling.

[0023] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0025] Figure 1 This is a schematic diagram of a hierarchical resource management system for computing tasks in a parallel computing processor according to Embodiment 1 of the present invention;

[0026] Figure 2 This is an overall architecture diagram applicable to an embodiment of the present invention;

[0027] Figure 3 This is a flowchart of a hierarchical resource management method for computing tasks in a parallel computing processor according to Embodiment 2 of the present invention;

[0028] Figure 4 This is a flowchart of another hierarchical resource management method for computing tasks in a parallel computing processor according to Embodiment 3 of the present invention. Detailed Implementation

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

[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] Example 1

[0032] Figure 1 This is a schematic diagram of a hierarchical resource management system for computing tasks in a parallel computing processor, provided in Embodiment 1 of the present invention. Figure 1 As shown, the hierarchical resource management system 110 for computing tasks in a parallel computing processor includes:

[0033] Multiple first-level resource managers 120 are configured at the cluster level (i.e., Figure 1 The first-level resource manager 1, first-level resource manager 2, ..., first-level resource manager N) and multiple second-level resource managers 130 set at the processing unit level (that is, Figure 1 The processing unit hierarchy includes second-level resource managers 1, 2, ..., N; and multiple processing units are configured in the hierarchy. Figure 1 (not shown in the image), each second-level resource manager 130 is configured with a corresponding processing unit, and each second-level resource manager 130 is used to manage the corresponding configured processing unit; each first-level resource manager 120 establishes a communication connection with the matched second-level resource manager 130 through a standardized request-response interface; each first-level resource manager 120 determines the matched second-level resource manager 130 through a processing unit mask;

[0034] The first execution status information of each computing task currently in execution is maintained in real time in the first-level resource manager 120, and the second execution status information of each type of subtask currently in execution in the managed processing unit, as well as the final available credit value of the managed processing unit, are maintained in real time in the second-level resource manager 130.

[0035] The first-level resource manager 120 is used to receive resource requests for target computing tasks sent by the upstream scheduler, return first execution status information to the upstream scheduler, and initialize the first execution status information corresponding to the target computing task when receiving the target resource request sent by the upstream scheduler; and update the matching first execution status information according to the execution completion information of each target subtask fed back by the target processing unit to the first-level resource manager 120.

[0036] The second-level resource manager 130 is used to receive resource requests for target computing tasks sent by the upstream scheduler, return second execution status information and the final available credit value of the target processing unit matching the target computing task to the upstream scheduler, and, based on the received target resource requests sent by the upstream scheduler, instruct the target processing unit to allocate target execution resources for the target computing task and then execute various types of target subtasks in the target computing task based on the target execution resources; and, based on the execution completion information of each target subtask fed back by the target processing unit to the second-level resource manager 130, update the matching second execution status information and the final available credit value; wherein, the target resource request is sent by the upstream scheduler when it determines that the target computing task meets the execution conditions based on the first execution status information, the second execution status information and the final available credit value of each target processing unit;

[0037] The first-level resource manager 120 is further configured to, after determining that all target subtasks in the target computing task have been executed according to the currently maintained first execution status information, notify the upstream scheduler of the task completion status of the target computing task, and issue an instruction to the target processing unit according to the processing unit mask to trigger the target processing unit to perform a local shared synchronization resource invalidation operation on the target execution resource, and, after determining that the task completion status notification has been completed and all target processing units have successfully completed the synchronization resource invalidation operation, determine that the target computing task has been executed.

[0038] In this embodiment, the hierarchical resource management system for computing tasks in the parallel computing processor refers to a hardware management system deployed inside the parallel computing processor, consisting of two levels of hierarchical resource managers, which realizes hierarchical task control and resource collaborative scheduling. The first-level resource manager is a cluster resource management hardware module deployed at the cluster level, responsible for global computing task lifecycle management and block-level state maintenance. The second-level resource manager is a local resource management hardware module deployed at the processing unit level, managing corresponding processing units one-to-one, and responsible for subtask status statistics and real-time updates of resource credit values. The standardized request-response interface refers to the hardware communication interface with a unified protocol and standardized interaction between the two levels of resource managers. The cluster level refers to the management level covering multiple processing units and performing global task control for the entire parallel computing processor cluster. The processing unit level refers to the management level corresponding to a single processing unit, where subtask and hardware resource control are completed locally within the processing unit.

[0039] The first execution status information refers to the global runtime status data maintained by the first-level resource manager, oriented towards the overall computing task dimension. The second execution status information refers to the fine-grained runtime status data maintained by the second-level resource manager, oriented towards the various sub-task dimensions within the processing unit. The final available credit value refers to the quantitative resource indicator, obtained in real-time by the second-level resource manager, representing the remaining sub-task capacity of the corresponding processing unit. The target resource request refers to the scheduling instruction issued by the upstream scheduler after verifying that resource conditions have been met, used to formally initiate task resource initialization and allocation. The invalidation operation of local shared synchronous resources refers to the hardware resource reset operation of clearing, invalidating, and reclaiming block-level shared synchronous resources after the processing unit task has been completed.

[0040] Specifically, the hierarchical resource management system 110 constructs a two-layer hierarchical control architecture through a first-level resource manager 120 at the cluster level and a second-level resource manager 130 at the processing unit level. The second-level resource manager 130 manages the corresponding processing unit one-to-one. The two managers achieve stable communication and interaction based on a standardized request-response interface. The first-level resource manager 120 maintains the first execution status information of the global computing task dimension throughout the process, while the second-level resource manager 130 maintains the second execution status information of the sub-task dimension within the processing unit and the final available credit value of the processing unit in real time.

[0041] Each first-level resource manager 120 completes the matching and positioning with the second-level resource manager 130 based on the processing unit mask. The mask is data in the form of a bit map, with different bits inside the mask corresponding to different processing units. The processing unit is also associated with the second-level resource manager 130. When a bit position is valid, it means that the second-level resource manager 130 corresponding to that bit position is selected by the current first-level resource manager 120 to participate in the target computing task. This supports a one-to-many matching relationship, that is, the same first-level resource manager 120 can match multiple corresponding second-level resource managers 130 through multiple valid bits in the mask. Of course, depending on the actual scale of the computing task, the mask can also be set with only a single valid bit to achieve the matching of the first-level resource manager 120 with a single second-level resource manager. The matching relationship is dynamically configured according to the target computing task rather than being fixed in hardware. After the first-level resource manager 120 selects the corresponding second-level resource manager 130 based on the mask, it can complete the interactive transmission of instructions and status information through the standardized request and response interface.

[0042] The upstream scheduler obtains complete resource status data at both levels through resource status queries. It combines the remaining resource balance in the cluster table of the first-level resource manager 120 with the processing unit resource capacity of the second-level resource manager 130 to determine task execution conditions. Upon successful verification, it issues the target resource request. The first-level resource manager 120 completes global task status initialization, while the second-level resource manager 130 dynamically allocates resources and manages multi-task operation based on sub-task type granularity. After a sub-task is completed, the target processing unit reports execution information to both resource managers. The second-level resource manager 130 updates the matching second execution status information and final available credit value based on the completion information of each target sub-task reported by the target processing unit, continuously refreshing the real-time resource capacity of the processing unit. Simultaneously, the reported execution information drives real-time updates of the status data at both levels. The first-level resource manager 120 updates the matching first execution status information based on the completion information of each target sub-task reported by the target processing unit and tracks the overall task execution progress throughout the process.

[0043] After all subtasks have been completed, the first-level resource manager reports the task completion status and reads the processing unit mask. It parses the valid bits in the mask to locate all target processing units participating in the current target computation task. It then directly issues invalidation instructions to these selected target processing units, triggering each unit to invalidate its local shared synchronization resources, thus clearing and reclaiming these resources. The number of valid bits in the processing unit mask dynamically changes with the task size. Instructions can be issued to multiple target processing units in parallel or to a single target processing unit. After issuance, the first-level resource manager waits for invalidation operation completion responses from each target processing unit, which are then used to update the first execution status information.

[0044] After the system confirms the completion of the task and all target processing units have successfully completed the synchronization resource invalidation operation, it determines that the target computing task has ended, ensuring the complete reclamation of synchronization resources and the complete termination of the task. This achieves decoupling and coordination between global task lifecycle management and local fine-grained resource management, effectively improving the standardization, resource isolation, and resource reclamation reliability of multi-task concurrent scheduling of parallel computing processors.

[0045] Optionally, based on the above embodiments, the first-level resource manager includes a block tracking table, which includes multiple computation block lifecycle records. Each computation block lifecycle record stores the first execution status information of a computation task that is currently in the execution state.

[0046] The second-level resource manager specifically includes a task slot table corresponding to the managed processing unit. The task slot table includes multiple task slots. Each task slot stores the running thread count value corresponding to a subtask of a certain type, which serves as the second execution status information. Different subtask operations correspond to different types.

[0047] In this embodiment, the block tracking table refers to a data record table configured within the first-level resource manager, used to store the global state of each computing task within the cluster and record the full lifecycle information of computing blocks. A computing block lifecycle record is a single entry in the block tracking table; one record corresponds to a complete computing task currently being executed, saving the task's first execution state information. The task slot table is a local state record table configured within the second-level resource manager, corresponding to the managed processing unit. A task slot is a single entry in the task slot table; one slot record corresponds to a type of subtask. The running thread count value refers to the number of threads corresponding to that type of subtask currently running but not yet completed within the processing unit.

[0048] Specifically, the first-level resource manager sets up a block tracking table, which contains multiple computation block lifecycle records. The block tracking table is task-based, and each computation block lifecycle record corresponds to a complete computation task issued by an upstream. A complete computation task contains multiple subtasks, and the record stores the first execution status information of the computation task currently in execution.

[0049] The second-level resource manager configures the task slot table corresponding to the managed processing unit. The task slot table is granular with task type. Each task slot corresponds to a subtask type. All subtasks of the same type within the same processing unit share the same slot record. A task slot stores the running thread count value of the corresponding subtask type as the second execution status information. Different subtask operations correspond to different subtask types.

[0050] The first-level resource manager uses a block tracking table to record the first execution status information of each executing computation task at the granularity of computation tasks. It can independently track the full lifecycle running status of a single complete computation task at the cluster global level. The second-level resource manager relies on a task slot table to divide different subtask types according to the subtask operation type. It uses the task slot to store the running thread count value of the corresponding type of subtask as the second execution status information. It can count the number of concurrent threads by subtask type locally in the processing unit. It separates the global task-level status control from the local subtask-type level resource statistics. This allows the cluster side to clearly grasp the overall execution progress of each complete computation task, and the processing unit side to uniformly manage the thread count of the same type of subtask. This facilitates real-time statistics of the processing unit's resource load and supports resource isolation in multi-task concurrent scenarios. At the same time, the two-level tables store different dimensions of status data, reducing the management overhead caused by mixed status information and improving the clarity of task status maintenance and the real-time performance of resource statistics in the hierarchical resource management system.

[0051] Furthermore, based on the above embodiments, the first-level resource manager also includes multiple first-in-first-out resource response tracking queues, with one resource response tracking queue corresponding to one processing unit;

[0052] The first-level resource manager is further configured to, after triggering the target processing unit to perform a local shared synchronous resource invalidation operation on the target execution resource, obtain the block identifier of the target computing block matching the target computing task, and push the block identifier of the target computing block into the resource response tracking queue of the target processing unit; and whenever a response to the invalidation operation matching the current processing unit is received, pop the head block identifier from the resource response tracking queue matching the current processing unit, and perform recycling processing on the current processing unit according to the head block identifier, and update the first execution status information.

[0053] In this embodiment, the resource response tracking queue refers to a first-in-first-out (FIFO) queue configured in the first-level resource manager, corresponding to the processing unit. It stores the identifiers of computational blocks awaiting recycling and tracks the asynchronous responses of each processing unit to synchronously invalidate resources. FIFO ensures that the invalidation requests and responses from the same processing unit are in the same order. A block identifier is an identification number used to identify a target computational block.

[0054] Specifically, the first-level resource manager is configured with multiple first-in-first-out resource response tracking queues. Each resource response tracking queue corresponds to a processing unit, which is used to realize the asynchronous response recycling of synchronous resources. The queue depth can match the maximum number of thread slots of a single processing unit.

[0055] Asynchronous response recycling refers to a working mechanism in which, after the first-level resource manager sends an invalidation request, it does not need to block and wait for the response from the processing unit, but relies on independent queue logic to process subsequent recycling responses.

[0056] After the target processing unit is triggered to perform the invalidation operation of the local shared synchronous resources on the target execution resources, the first-level resource manager obtains the block identifier of the target computing block, pushes the block identifier into the resource response tracking queue corresponding to the target processing unit, and initializes the count of responses to be reclaimed in the block tracking table to the number of processing units participating in the current computing block.

[0057] The pending response count is a counter field in the block trace table, used to record the number of target processing units that have not yet received an invalidation completion response. Whenever an invalidation completion response is received from a processing unit, the block trace table entry corresponding to that block identifier is looked up, and the pending response count is decremented. The first-level resource manager continuously monitors this count. Only when the pending response count decreases to zero, and the other two conditions are met—a pending thread count of zero and process termination—is it determined that all processing units participating in this computation block have completed the invalidation and reclamation of local shared synchronous resources. The corresponding block trace table entry is then released, and the block identifier is reclaimed for reuse by subsequent new computation tasks.

[0058] After the processing unit completes the local synchronization resource invalidation operation, it returns a completion response carrying the processing unit identifier. The response decoder locates the corresponding resource response tracking queue based on the processing unit identifier and pops the first block of the queue identifier.

[0059] After popping the first block identifier, the first-level resource manager uses this identifier to retrieve the block tracking table, finds the corresponding compute block lifecycle record, and executes the recycling process corresponding to the current processing unit. This involves registering the invalidation response corresponding to the processing unit, decrementing the count of responses to be recycled in the record, and confirming the shared synchronous resource recycling status of the processing unit. The first execution status information stored in the block tracking table is updated to mark that the invalidation recycling action of the processing unit has been completed. The updated status is used for subsequent multi-condition joint judgment to determine whether the table entry corresponding to the compute block can be released.

[0060] Invalidation requests and responses within the same processing unit maintain a first-in-first-out (FIFO) order. Response recycling from different processing units is executed independently and in parallel. The task completion notification process and response recycling process are decoupled. The completion process can continue processing the next task completion process immediately after sending an invalidation request and enqueuing the completion block identifier, without waiting for a response. Response recycling is executed asynchronously by an independent queue logic. Releasing a block resource manager entry requires simultaneously satisfying three conditions: the count of threads to be completed is zero, the completion process is complete, and the count of responses to be recycled is zero. Once all conditions are met, the entry is automatically released, and the block identifier can be directly allocated to a new computation block.

[0061] The first-level resource manager configures corresponding first-in-first-out (FIFO) resource response tracking queues for each processing unit. When a local shared synchronous resource invalidation command is issued, the block identifier of the target computation block is pushed into the queue of the corresponding processing unit. Upon receiving the invalidation completion response, the block identifier at the head of the queue is retrieved to perform recycling and update the first execution status information. The FIFO queue characteristic ensures that the invalidation request and response timing of the same processing unit matches. By separating the response streams of different processing units through queues, the resource recycling process of each processing unit does not block each other, achieving asynchronous processing of invalidation responses. The first-level resource manager does not need to send invalidation requests... After requesting, the system blocks and waits for a response. The task completion process and resource reclamation response processing are decoupled. At the same time, the life cycle record of the corresponding computing block can be quickly located by the head block identifier, simplifying the hardware-level request and response matching logic. It can promptly register the invalidation completion status of each processing unit and accurately maintain the first execution status information. The entry corresponding to the computing block will only be released after all relevant processing units have completed invalidation and reclamation, ensuring the integrity of block-level shared synchronous resource reclamation, reducing the blocking waiting time in the task end-stage, and improving the reuse efficiency of block tracking table entries and the overall task scheduling throughput of the parallel computing processor.

[0062] Furthermore, based on the above embodiments, the second-level resource manager also includes resource credit value calculation hardware;

[0063] The resource credit value calculation hardware is used to calculate the final available credit value of the processing unit managed by the second-level resource manager in real time based on the running thread count values ​​of each type of subtask recorded in the task slot table of the processing unit managed by the second-level resource manager.

[0064] In this embodiment, the resource credit value calculation hardware is a hardware calculation module located inside the second-level resource manager, used for calculating the resource carrying capacity index of the hardware real-time computing unit.

[0065] Specifically, the second-level resource manager is configured with hardware for calculating resource credit values. This hardware reads the running thread count values ​​corresponding to various subtasks in the task slot table of the managed processing unit. When the thread count changes, it calculates the final available credit value of the processing unit in real time. When the upstream scheduler queries the resource status, the second-level resource manager can directly output the final available credit value updated in real time, providing a quantitative basis for the upstream scheduler to evaluate whether the processing unit has the resource capacity to take on new subtasks.

[0066] For example, the thread occupancy of each type of subtask is transformed into a final available credit value that represents the remaining resource carrying capacity of the processing unit. When the upstream scheduler initiates a resource request query, it directly outputs the final available credit value calculated in real time by the hardware for resource feasibility judgment.

[0067] By utilizing the built-in resource credit value calculation hardware in the second-level resource manager, and relying on the thread count values ​​of various subtasks recorded in the task slot table, the final available credit value of the processing unit is calculated in real time. This allows the thread occupancy of various subtasks to be converted into a unified and quantified resource capability indicator in real time through hardware circuitry, without occupying the computing resources of a general-purpose processor. When the thread count value changes due to the start or completion of a subtask, the available resource evaluation result can be updated immediately, providing the upstream scheduler with accurate and low-latency processing unit resource status. This facilitates the upstream scheduler to quickly determine whether the processing unit can accept new subtasks, enabling resource access control for multiple types of subtasks within a single processing unit. It supports multi-task coexistence and isolation on the processing unit side, improves the real-time performance of resource status feedback in the entire hierarchical resource management system, and reduces scheduling latency caused by software computation.

[0068] In a specific example, the hierarchical resource management system for computing tasks in a parallel computing processor includes a first-level resource manager at the cluster level and a second-level resource manager at the processing unit level. The first-level resource manager, acting as the cluster resource manager, manages the lifecycle of computing blocks within the cluster and blocks-level shared synchronization resources. The second-level resource manager, acting as the processing unit resource manager, manages the availability of execution resources for the corresponding processing unit, enabling multi-task coexistence control.

[0069] The first-level resource manager is configured with a block tracking table and a set of synchronous resource response tracking queues; the second-level resource manager is configured with a task slot table and a resource credit value calculation module. The first-level and second-level resource managers communicate with each other through a standardized request-response interface.

[0070] Figure 2 This is an overall architecture diagram applicable to embodiments of the present invention. The top-level architecture includes an upstream scheduler, which connects to a hierarchical resource management system for computational tasks within the parallel computing processor. The hierarchical resource management system is divided into a cluster level and a processing unit level. The cluster level deploys multiple first-level resource managers (cluster resource managers). Each first-level resource manager has a built-in block tracking table and multiple resource response tracking queues. The block tracking table stores lifecycle records of multiple computational blocks, including their first execution status information.

[0071] The block tracking table uses a single complete upstream computation task as one row entry, with each row representing a computation block lifecycle record. Each record stores the first execution status information of a computation task currently in execution. The table can contain fields such as: task identifier, subtask type, subtask mask, count of threads yet to complete, count of responses yet to be recycled, end notification enable bit, and synchronization resource invalidation enable bit. Each row corresponds to one computation task, which can be broken down into multiple subtasks. This table is used to maintain the global lifecycle status of the computation task at the cluster level. The first-level resource manager relies on this table to track task execution progress and determines whether to release the entry after all subtasks are completed and all invalidation / recycling is finished.

[0072] Multiple second-level resource managers (processing unit resource managers) are deployed at the processing unit level. Each second-level resource manager is configured with one processing unit. The second-level resource manager has a built-in task slot table and resource credit value calculation hardware. The task slot table contains multiple task slots, which are used to store the running thread count values ​​corresponding to various types of subtasks as the second execution status information. The resource credit value calculation hardware calculates the final available credit value of the processing unit in real time based on the task slot table data.

[0073] The task slot table uses a row for each type of subtask, with each row representing a task slot. Each task slot stores the running thread count corresponding to a specific type of subtask. This count serves as secondary execution status information, with different subtask operations corresponding to different types. The table can contain fields such as: valid bit, subtask type, and number of threads in transit. Within the same processing unit, all subtasks belonging to the same subtask type share the same row of slots. Whenever a subtask of that type starts, the corresponding running thread count is incremented; when the subtask completes, the running thread count is decremented. The second-level resource manager reads the running thread count from this table and sends it to the resource credit value calculation hardware to obtain the final available credit value for the processing unit in real time.

[0074] Each first-level resource manager establishes a communication connection with its matching second-level resource manager through a standardized request-response interface. The upstream scheduler issues resource requests for the target computing task to the first-level and second-level resource managers, and the two-level resource managers report the corresponding status information back to the upstream scheduler, realizing hierarchical collaboration between global task lifecycle management and local subtask resource management of the processing unit.

[0075] This embodiment employs a two-tiered resource granularity differentiated management architecture at the cluster and processing unit levels. The two resource managers oversee resources at different dimensions, enabling multi-task coexistence and resource isolation. The first-level resource manager, the cluster resource manager, manages complete computational tasks. Each entry in the block tracking table corresponds to an upstream computational task. A computational task contains multiple subtasks, and the subtasks are assigned to the respective second-level resource managers via a target processing unit mask. The second-level resource manager, the processing unit resource manager, manages subtask types. Each entry in the task slot table corresponds to a type of subtask, and subtasks of the same type within the same processing unit share the same slot record. The two resource managers achieve decoupled communication through a standardized request-response interface. The first-level resource manager is responsible for upstream task lifecycle management and cross-processing unit synchronous resource reclamation, while the second-level resource manager is responsible for processing unit execution resource availability management and multi-task coexistence control.

[0076] The first-level resource manager contains a block tracking table. Each entry records the lifecycle status of a compute block. Fields may include: valid bit, task identifier, count of threads to be completed, end notification enable bit, synchronized resource invalidation enable bit, target processing unit mask, state machine ready flag, and count of responses to be reclaimed.

[0077] The second-level resource manager relies on a task slot table to achieve independent tracking of multi-task resources within a single processing unit. Each processing unit is configured with K task slots, where K is an integer greater than 1. Each slot is bound to a task identifier and independently tracks the in-flight thread count of that task (the sum of the running thread counts from all task slots). Slots support an automatic allocation mechanism: when a new task request arrives, it prioritizes matching existing slots with the same task identifier; if no match is found, it allocates an available slot based on the smallest identifier. Slots also support an automatic release mechanism: when the in-flight thread count of a slot decreases to zero, the slot is automatically cleared without needing an explicit release command. A query locking mechanism is also set up to maintain the task identifiers currently being interacted with by the processing unit. If the queried task is inconsistent with the currently connected task, and the previous query result has not yet been returned, a lock signal is output to avoid erroneous scheduling decisions based on expired resource information.

[0078] The second-level resource manager has built-in hardware for calculating resource credit values. It maintains real-time intermediate credit values ​​for the managed processing units, dynamically calculating them each period: Intermediate Credit Value = Number of Idle Threads + Number of Hardware Running Threads - Running Thread Count Value obtained by summing all task slots. The number of idle threads and hardware running threads are obtained from resource status messages reported by the processing units; the running thread count value is taken from the running thread count values ​​corresponding to each type of subtask recorded in the task slot table, and this running thread count value serves as the second execution status information.

[0079] The system employs a multi-dimensional pre-configured constraint mode. Firstly, there's a maximum thread limit per task, configured by the upstream scheduler or software, supporting both global and task-level throttling mechanisms: global mode sums the running thread counts for all tasks within the processing unit, achieving global throttling; task mode only counts the running thread count for the current target task, achieving task-level fine-grained flow. Secondly, there's an idle slot limit, determined by the processing unit's hardware resources, such as the SIMD (Single Instruction, Multiple Data) width and the number of register sets. Thirdly, there's idle thread information, with the processing unit providing real-time feedback on the physical thread availability status.

[0080] The resource credit value calculation hardware takes the minimum value of multiple constraints, including intermediate credit value, maximum thread limit for tasks, idle slot limit, and idle thread information, to obtain the final available credit value of the processing unit, ensuring the conservatism of resource evaluation. If any dimension reaches the resource bottleneck, the processing unit is determined to be unavailable, preventing over-commitment of resources. When the processing unit is in an idle state, the intermediate credit value is directly initialized to the pre-configured number of idle adaptation threads, eliminating the resource query round-trip latency and enabling rapid startup of idle processing units.

[0081] The hierarchical resource management system divides the lifecycle of computing blocks into the application phase, execution tracking phase, and waiting-to-release phase, which are completed collaboratively by the first-level resource manager and the second-level resource manager through a standardized request-response interface.

[0082] The application phase is initiated by the upstream scheduler. The scheduler queries the resource status of the two-level resource managers: it checks the number of available rows in the block trace table of the first-level resource manager to determine if it can handle the new task; it checks the output of the resource credit value calculation hardware of the second-level resource manager to determine if the downstream processing unit can handle the new subtask. Once both levels of resources meet the requirements, the task application process begins. First, the first-level resource manager allocates entries in the block trace table, recording task information and the target processing unit mask. The first-level resource manager then sends resource requests to each target processing unit based on the mask. The second-level resource manager allocates resources at the task type level through the task slot table: if a slot of the same type exists, the in-transit count is incremented; otherwise, a new slot is allocated, and the allocation result is returned to the first-level resource manager through a standardized request-response interface.

[0083] The execution tracking phase is jointly performed by the resource management module and downstream processing units. After a subtask is completed, the downstream processing unit reports the completion information. Upon receiving the information, the first-level resource manager decrements the count of pending threads for the corresponding task line in the block tracking table, continuously monitoring until all subtasks of the computation task have been completed.

[0084] The waiting-to-release phase is triggered upon completion of any subtask, executing three processing logics in parallel. The first route is executed by the second-level resource manager, decrementing the in-transit count of the corresponding row in the task slot table. The updated slot can immediately receive new subtasks of the same type, achieving multi-task coexistence and isolation within the processing unit at the subtask granularity. The second route is executed by the first-level resource manager, reporting the final task status to the upstream scheduler after all subtasks are completed, releasing the task row in the block tracking table, and reclaiming task identifiers for reuse by new tasks, achieving upstream task status synchronization at the task row granularity. The third route is executed by the downstream processing unit, completing the invalidation of local shared synchronization resources, releasing shared synchronization resources in advance, and accelerating the execution of subsequent new tasks.

[0085] This process decouples task status synchronization and resource early release. The first-level resource manager is responsible for task-level status synchronization, table entry release, and early release of shared synchronized resources. The second-level resource manager is responsible for task-type-level local resource tracking. While releasing block tracking table entries, it simultaneously completes upstream task status updates and downstream shared resource release, improving block tracking table utilization and task scheduling throughput.

[0086] This embodiment sets up a two-layer isolation to achieve early task termination and early release of shared synchronous resources: The first layer of isolation is the isolation between the task completion notification and the release of table entries in the first-level resource manager. The task is considered to be completed when all subtasks are completed, and the release of table entries needs to wait for the subsequent recycling operation to be completed; The second layer of isolation is the isolation between the invalidation request sent to the downstream processing unit and the invalidation response recycling.

[0087] In other words, the first layer of isolation is the isolation between the task completion notification on the first-level resource manager side and the release of the block trace table entry row. Once all subtasks have been executed, a task completion notification can be sent out to determine the task's completion. However, the corresponding entry row in the block trace table is not released immediately. The entry release still needs to wait for the downstream processing unit to complete all subsequent operations of synchronous resource reclamation. This decouples the task completion notification process from the entry reclamation process, preventing the output of the task completion notification from being blocked due to resource reclamation waiting. The second layer of isolation is the isolation between the invalidation request command issued to the downstream processing unit and the invalidation response reclamation. After the first-level resource manager issues the invalidation request command to the processing unit, it can continue to execute subsequent processing logic without blocking and suspending to wait for the invalidation responses from each processing unit. The invalidation responses are subsequently processed by an independent asynchronous reclamation mechanism, thereby eliminating the process blockage caused by the round-trip delay of the interconnection network. With the help of the above two independent isolation designs, while ensuring the complete and reliable reclamation of shared synchronous resources, tasks can be terminated early and shared synchronous resources can be released early, improving the reuse efficiency of block trace table entries and the overall task scheduling throughput of the system.

[0088] This embodiment configures an asynchronous response recycling mechanism. The first-level resource manager configures an independent first-in-first-out resource response tracking queue for each processing unit. The queue depth can be equal to the maximum number of thread slots in a single processing unit. The workflow is as follows:

[0089] Enqueue operation: When sending a synchronization resource invalidation request to the target processing unit, the block identifier of the current computation block is pushed into the resource response tracking queue corresponding to the processing unit; at the same time, the count of responses to be reclaimed in the block tracking table is initialized to the number of valid bits in the target processing unit mask, that is, the number of processing units participating in the current computation block.

[0090] Dequeue operation: After the processing unit completes the local synchronization resource invalidation operation, it returns a response carrying the processing unit identifier; the response decoder locates the corresponding resource response tracking queue based on the identifier, pops the first block identifier from the queue, retrieves the matching block tracking table entry, and decrements the count of responses to be reclaimed.

[0091] Order guarantee: Invalidation requests and responses corresponding to the same processing unit maintain a strict first-in-first-out order; each processing unit has an independent queue, and the recycling processes of different processing units do not interfere with each other, realizing parallel response recycling.

[0092] Process decoupling: The first-level resource manager executes the end process, only completing the task end notification, sending the invalidation request and enqueuing the block identifier. Once the sending is completed, the end process of the next table entry can be started without waiting for a response. Response recycling is executed asynchronously by independent queue logic.

[0093] Releasing a block tracking table entry requires three conditions to be met simultaneously: the count of threads awaiting completion is zero, the termination process has finished executing, and the count of responses awaiting recycling is zero. When all conditions are met, the entry is automatically released, and the block identifier can be allocated to a new computation block. This asynchronous recycling mechanism decouples the task termination process from response recycling, eliminating the impact of network round-trip latency on task finalization and accelerating the next round of task scheduling.

[0094] In this embodiment, entries in the block tracking table can enter the release preparation state immediately after the end process state machine completes, without being constrained by cross-module communication delays, reducing block tracking table occupancy delays and improving the effective utilization rate of the block tracking table. Relying on a real-time resource credit value calculation mechanism avoids round-trip delays in resource queries, and combined with a fast start mechanism for idle processing units, the first batch of thread scheduling can be completed immediately, effectively accelerating scheduling decisions and reducing scheduling start delays. A task slot mechanism enables resource isolation tracking at the task granularity, coupled with a global and task-based dual-mode throttling mechanism, adapting to diverse scheduling strategy requirements and providing flexible multi-task parallel support. Based on a standardized request-response interface, it supports flexible switching of scheduling strategies between all-hardware scheduling and all-firmware scheduling, possessing software and hardware co-operation flexibility and adapting to various application scenarios.

[0095] The system of this invention employs a layered architecture design with a first-level resource manager at the cluster level and a second-level resource manager at the processing unit level. The first-level resource manager maintains the first execution status information of the computational task dimension, while the second-level resource manager maintains the second execution status information of the sub-task dimension within the processing unit, as well as the final available credit value of the processing unit. The upstream scheduler combines the multi-dimensional status information fed back by the two levels of managers to uniformly determine the task execution conditions before issuing the target resource request. This decouples global computational task status management from the resource management of sub-tasks within a single processing unit, avoiding the excessive processing pressure caused by a single manager simultaneously handling global task scheduling and fine-grained sub-task statistics. Furthermore, the two levels of resource managers respectively report the actual running status of their corresponding dimensions to the upstream scheduler, relying on the real-time output of the second-level resource manager. The final available credit value eliminates the need for additional queries from the scheduler, overcoming the lag in resource availability assessment. This allows the upstream scheduler to obtain a more complete and accurate profile of cluster resources, reducing task scheduling failures or resource over-allocation caused by missing resource information. Simultaneously, the first-level resource manager triggers the synchronous resource invalidation operation only after all subtasks have been completed, and waits for the task completion notification and the successful execution of all synchronous resource invalidation operations in all processing units before determining the computation task's completion. This ensures reliable reclamation of shared synchronous resources, preventing data inconsistencies and resource pollution caused by releasing resources before tasks are fully completed. The standardized request-response interface facilitates interaction between the two-level managers, also aiding in decoupling and integration between different modules, thus improving the overall reliability and resource utilization efficiency of parallel computing processor task scheduling.

[0096] Example 2

[0097] Figure 3 This is a flowchart illustrating a hierarchical resource management method for computing tasks in a parallel computing processor according to Embodiment 2 of the present invention. This embodiment is applicable to scenarios where multiple computing tasks are executed concurrently within a parallel computing processor, and involves hierarchical resource management of computing tasks. This method can be executed by the first-level resource manager in the hierarchical resource management system for computing tasks in the parallel computing processor described in any embodiment of the present invention. Figure 3 As shown, the method includes:

[0098] S310. Maintain the first execution status information of each computing task currently in execution in real time.

[0099] S320. When receiving a resource request for a target computing task sent by the upstream scheduler, return the first execution status information to the upstream scheduler, and when receiving a target resource request sent by the upstream scheduler, complete the initialization of the first execution status information corresponding to the target computing task.

[0100] The target resource request is sent by the upstream scheduler when it determines that the target computing task meets the execution conditions based on the first execution status information, the second execution status information, and the final available credit value of each target processing unit.

[0101] In this embodiment, the upstream scheduler is located upstream of the hierarchical resource management system. It is responsible for issuing resource requests for computing tasks, determining the task execution conditions based on the combined resource status of the two levels, and issuing target resource requests when the resources are sufficient. The resource request for the target computing task is a request message sent by the upstream scheduler to the first-level resource manager to query the resource status related to the target computing task.

[0102] A target processing unit is a hardware execution unit that executes the various target subtasks derived from the breakdown of a target computation task. A target subtask is a subtask that, after the target computation task has been broken down, can be run in a single processing unit.

[0103] S330. When receiving the execution completion information of each target subtask from the target processing unit, update the matching first execution status information according to the execution completion information.

[0104] In this embodiment, the execution completion information is a feedback message reported by the target processing unit to the first-level resource manager after completing the target subtask calculation, which is used to notify that the subtask has been completed.

[0105] Specifically, the first-level resource manager maintains the first execution status information of each computing task currently in execution in real time; when receiving a resource request for a target computing task sent by the upstream scheduler, it returns the first execution status information to the upstream scheduler; and when receiving a target resource request sent by the upstream scheduler, it initializes the first execution status information corresponding to the target computing task. The target resource request is sent by the upstream scheduler when it determines that the target computing task meets the execution conditions based on the first execution status information, the second execution status information, and the final available credit value of each target processing unit; when receiving the execution completion information of each target subtask fed back by the target processing unit, it updates the matching first execution status information according to the execution completion information.

[0106] For example, the first-level resource manager continuously reads and writes the block trace table to maintain the first execution status information of each computing task in real time. After receiving a resource request message from the upstream scheduler, it reads the task status information stored in the block trace table, encapsulates the message, and sends it back to the upstream scheduler. The upstream scheduler combines the resource status of the two levels to determine that the resource is available and then issues a target resource request. When the first-level resource manager receives the target resource request, it selects an idle entry in the block trace table, writes the corresponding status fields of the target computing task, and completes the initialization. After the processing unit completes the subtask operation, it sends execution completion information carrying the task identifier upwards. When the first-level resource manager receives this information, it retrieves the matching entry in the block trace table, modifies the pending thread count field in the entry, and completes the update of the first execution status information.

[0107] Optionally, based on the above embodiments, the first-level resource manager includes a block tracking table, which includes multiple computation block lifecycle records. Each computation block lifecycle record stores the first execution status information of a computation task that is currently in the execution state.

[0108] The first execution status information includes: a valid bit, a computation task identifier, a count of threads to be completed, an end notification enable bit, a synchronization resource invalidation enable bit, a processing unit mask, a state machine ready flag, and a count of responses to be recycled.

[0109] Accordingly, based on the above embodiments, the initialization of the first execution state information corresponding to the target computation task is completed, including:

[0110] Create a new lifecycle record for a computation block that matches the target computation task. Initialize the valid bits, computation task identifier, and processing unit mask in the record. Also initialize the count of threads to be completed, the end notification enable bit, the synchronization resource invalidation enable bit, the state machine ready flag, and the count of responses to be reclaimed.

[0111] Based on the above embodiments, the matching first execution status information is updated according to the execution completion information, including:

[0112] Based on the execution completion information, update the count of pending threads in the lifecycle record of the computation block that matches the computation task to which the target subtask belongs;

[0113] Based on the above embodiments, the first execution state information of each computing task currently in execution is maintained in real time, including:

[0114] When the conditions for the end of a task are met, update the end notification enable bit and the synchronization resource invalidation enable bit of the lifecycle record of the computing block that matches the corresponding computing task, and trigger the notification of the end of the task and the synchronization resource invalidation operation.

[0115] During the execution of a computation task, the state machine readiness flag in the lifecycle record of the corresponding computation block is updated to mark the running readiness state of the state machine corresponding to the computation task.

[0116] When a completion response for the synchronization resource invalidation operation is received from the target processing unit, the count of responses to be reclaimed in the lifecycle record of the computing block that matches the corresponding computing task is updated.

[0117] When a computing task meets the release conditions, the valid position of the computing block lifecycle record that matches the corresponding computing task identifier will be invalidated, and the computing block lifecycle record will be released for reuse by a new computing task.

[0118] In this embodiment, the valid bit is a flag bit within the first execution status information, used to mark whether the current computation block lifecycle record is valid. A valid bit indicates that the entry is occupied and corresponds to a computation task currently being executed, while an invalid bit indicates that the entry is idle and can be reused. The computation task identifier is a number that identifies the target computation task and is used to retrieve the corresponding computation block lifecycle record in the matching block tracking table.

[0119] The pending thread count is a count field within the first execution status information, recording the number of subtask threads that have not yet completed the current computation task. The end notification enable bit is a flag bit within the first execution status information; setting it triggers the sending of a task end notification to the upstream scheduler. The synchronization resource invalidation enable bit is a flag bit within the first execution status information; setting it triggers the issuance of an invalidation operation instruction for locally shared synchronization resources to the target processing unit.

[0120] The processing unit mask is a mask field within the first execution state information, used to mark all target processing units participating in the execution of the current computation task. The state machine ready flag is a flag bit within the first execution state information, used to indicate whether the state machine corresponding to the current computation task is in a ready state for normal execution transition. The synchronization resource invalidation operation completion response is a response message returned by the target processing unit to the first-level resource manager after completing the local shared synchronization resource invalidation operation, carrying the processing unit identifier.

[0121] Specifically, the first-level resource manager includes a block tracking table, which contains multiple computation block lifecycle records. Each computation block lifecycle record stores the first execution status information of a computation task currently in execution. The first execution status information includes: a valid bit, a computation task identifier, a count of threads to be completed, an end notification enable bit, a synchronization resource invalidation enable bit, a processing unit mask, a state machine ready flag, and a count of responses to be reclaimed.

[0122] When initializing the first execution state information corresponding to the target computing task, a new computing block lifecycle record matching the target computing task is created. The valid bits, computing task identifier and processing unit mask in the record are initialized and assigned values. The count of threads to be completed, the end notification enable bit, the synchronization resource invalidation enable bit, the state machine ready flag and the count of responses to be reclaimed are also initialized.

[0123] For example, the first-level resource manager selects the lifecycle record of an idle computing block in the block tracking table, sets the valid bit to a valid flag, writes the computing task identifier issued by the upstream scheduler, configures the processing unit mask according to the set of processing units participating in the execution of the computing task, sets the count of threads to be completed to the total number of threads of the subtasks obtained by splitting the computing task, initializes the end notification enable bit and the synchronization resource invalidation enable bit to the disabled state, sets the state machine ready flag to ready, and assigns a value to the count of responses to be reclaimed for the record according to the number of valid bits in the processing unit mask (the total number of processing units participating in the task).

[0124] When updating the first execution status information matching the execution completion information, the count of pending threads in the lifecycle record of the computation block to which the target subtask belongs is updated based on the execution completion information. For example, the first-level resource manager receives the subtask execution completion information carrying the computation task identifier reported by the target processing unit, searches the block tracking table based on the computation task identifier, locates the corresponding computation block lifecycle record, and decrements the count of pending threads in that record to update the number of remaining uncompleted threads for the computation task.

[0125] When maintaining the first execution status information of each computation task currently in execution, if the task termination condition is met, the end notification enable bit and synchronization resource invalidation enable bit of the computation block lifecycle record matching the corresponding computation task are updated, triggering the task termination status notification and synchronization resource invalidation operation. For example, the first-level resource manager continuously monitors the number of pending threads in the computation block lifecycle record. When the number of pending threads drops to zero, it determines that the task termination condition is met, and enables the end notification enable bit and synchronization resource invalidation enable bit corresponding to the record. On the one hand, it sends a task termination notification to the upstream scheduler, and on the other hand, it triggers the issuance of a local shared synchronization resource invalidation operation instruction to the target processing unit.

[0126] During the execution of a computation task, the state machine readiness flag in the corresponding computation block lifecycle record is updated to mark the state machine corresponding to the computation task as running ready. When a completion response for the synchronization resource invalidation operation is received from the target processing unit, the count of responses to be reclaimed in the computation block lifecycle record matching the corresponding computation task is updated. When the computation task meets the release conditions, the valid position of the computation block lifecycle record matching the corresponding computation task identifier is invalidated, and the computation block lifecycle record is released for reuse by new computation tasks.

[0127] For example, the first-level resource manager modifies the state machine ready flag in the corresponding computing block lifecycle record by following the flow nodes of the computing task state machine. When the state machine can receive various state transition instructions, the flag is set to ready; when the state machine is performing a critical operation and cannot receive instructions, the flag is set to not ready. After each processing unit completes the local synchronization resource invalidation operation, it returns a write response via the interconnection network. The response carries the processing unit identifier. The response decoder of the distribution path locates the corresponding response tracking queue based on the identifier, pops the block identifier at the head of the queue, retrieves the matching computing block lifecycle record based on the block identifier, and performs a decrement operation on the count of responses to be reclaimed in the record.

[0128] The first-level resource manager continuously monitors the count of threads to be completed and the count of responses to be recycled in this record. When the count of threads to be completed reaches zero, it is determined that all target subtasks have been completed. A task completion notification for the target computing task is sent to the upstream scheduler, and the target second-level resource manager is triggered to control the target processing unit to perform the invalidation operation of the local shared synchronization resources. When the count of responses to be recycled also reaches zero, it means that each target processing unit has successfully completed the invalidation operation of the synchronization resources. At this time, it is determined that the task release condition is met, the valid bit of the life cycle record of the computing block is modified to the invalid state, and the entry is released for subsequent new computing tasks to allocate and reuse.

[0129] By setting up a block trace table within the first-level resource manager, and relying on the first execution state information stored in the block trace table, including valid bits, computation task identifiers, counts of threads yet to complete, end notification enable bits, synchronization resource invalidation enable bits, processing unit masks, state machine ready flags, and counts of responses yet to be recycled, the corresponding computation block lifecycle records are initialized during the task creation phase. During subtask execution, the count of threads yet to complete is updated in real time based on the reported execution completion information. When the task meets the end-of-task condition, the corresponding enable bit is set to trigger task end notification and synchronization resource invalidation operations. This process is continuously maintained during task execution. The state machine is ready, and the count of responses to be recycled is updated after receiving the invalidation completion response from the processing unit. The entry is then marked as invalidated and recycled for reuse until the task meets the release conditions. This allows for centralized management of the entire lifecycle state of a single computing task, achieving orderly decoupling of task completion notification, synchronous resource invalidation, response collection, and entry recycling. This avoids blocking the task state machine flow during resource recycling, reduces the waiting overhead of synchronous resource recycling across processing units, and distinguishes the state of different stages of the task with independent fields, ensuring the accuracy of state updates in multi-task concurrent scenarios and improving the reuse efficiency of block tracking table entries.

[0130] S340. After determining that all target subtasks in the target computing task have been executed based on the currently maintained first execution status information, notify the upstream scheduler of the task completion status of the target computing task, and issue an instruction to the target processing unit according to the processing unit mask to trigger the target processing unit to perform a local shared synchronization resource invalidation operation on the target execution resources.

[0131] Specifically, after determining that all target subtasks in the target computing task have been executed based on the currently maintained first execution status information, the first-level resource manager notifies the upstream scheduler of the task completion status of the target computing task and triggers the target processing unit to perform a local shared synchronization resource invalidation operation on the target execution resources.

[0132] For example, the first-level resource manager continuously reads the count of pending threads recorded in the lifecycle of the corresponding computation block in the block tracking table. When the count of pending threads decreases to zero, it determines that all target subtasks of the target computation task have been completed, assembles a task completion notification message carrying the computation task identifier, and sends it to the upstream scheduler. The first-level resource manager then directly issues an invalidation request instruction to the target processing unit, triggering the target processing unit to perform a local shared synchronization resource invalidation operation on the target execution resources.

[0133] Furthermore, based on the above embodiments, after the target processing unit performs the invalidation operation of the local shared synchronization resource on the target execution resource, it further includes:

[0134] Obtain the block identifier of the target computing block that matches the target computing task, and push the block identifier of the target computing block into the resource response tracking queue of the target processing unit;

[0135] Based on the processing unit mask in the target computing block lifecycle record, determine the number of target processing units that will execute the target computing task, and update the count of responses to be recycled in the target computing block lifecycle record based on the number of target processing units.

[0136] Whenever an invalidation operation completion response matching the current processing unit is received, the head block identifier is popped from the resource response tracking queue matching the current processing unit. Based on the head block identifier, the current processing unit is reclaimed, and the count of responses to be reclaimed in the lifecycle record of the compute block matching the head block identifier in the block tracking table is updated.

[0137] In this embodiment, the target computation block is a management object bound to the target computation task and corresponding to a computation block lifecycle record in the block tracking table. The invalidation operation completion response is a response message returned by the target processing unit to the first-level resource manager via the Internet after completing the invalidation operation of the local shared synchronous resources.

[0138] Specifically, the first-level resource manager obtains the block identifier of the target computing block that matches the target computing task and pushes the block identifier of the target computing block to the tail of the resource response tracking queue of the target processing unit.

[0139] Based on the processing unit mask in the target computing block lifecycle record, the total number of valid bits in the mask is counted to determine the number of target processing units to execute the target computing task. Then, based on the number of target processing units, the count of responses to be recycled in the target computing block lifecycle record is updated to complete the initialization.

[0140] In the processing unit mask, each bit corresponds to a processing unit. Setting a bit to valid indicates that the processing unit participates in the current target computation task. By counting all valid bits, the total number of processing units participating in the task can be obtained.

[0141] After the target processing unit completes the invalidation operation, it sends back a response message through the Internet. The response decoder locates the corresponding resource response tracking queue based on the processing unit identifier carried in the message, retrieves the block identifier stored at the head of the queue, searches the block tracking table based on the block identifier to find the corresponding computation block lifecycle record, and performs a decrement operation on the count of responses to be reclaimed in the record, thus completing the reclamation process on the current processing unit side.

[0142] Among them, the Internet is the underlying hardware transmission path for transmitting messages between hardware modules inside the parallel computing processor, and the standardized request-response interface is the upper-level communication interface established between the first-level resource manager and the second-level resource manager based on the Internet and defining the message interaction format.

[0143] After triggering the local shared synchronous resource invalidation operation of the target processing unit, the block identifier of the target computation block is pushed into the resource response tracking queue dedicated to the corresponding target processing unit. The number of target processing units obtained by counting the processing unit mask is used to initialize the count of responses to be recycled. When the invalidation operation completion response is received, the block identifier of the head of the queue is popped from the resource response tracking queue and the count of responses to be recycled is updated synchronously. The asynchronous recycling of invalidation responses is achieved by using the resource response tracking queue. This means that the process of issuing invalidation requests after the task ends does not need to block and wait for responses from each processing unit. The task end process and the response recycling process are decoupled. Multiple invalidation requests within the same processing unit can maintain the first-in-first-out execution order. The response recycling of different processing units does not interfere with each other and can be carried out in parallel. This avoids the overall task end process from stalling due to the response delay of individual processing units, reduces the waiting latency of the task recycling phase in multi-task concurrent scenarios, and establishes the association between queue messages and block tracking table entries by relying on block identifiers. This ensures that response messages can accurately match the corresponding computation tasks and improves the reliability of the resource recycling process.

[0144] S350. After confirming the completion status of the task and that each target processing unit has successfully completed the synchronization resource invalidation operation, the execution of the target computing task is determined to be completed.

[0145] In this embodiment, the task completion status notification is a message sent by the first-level resource manager to the upstream scheduler after determining that all subtasks have been executed, informing the target computing task that the subtasks have completed their computation. The synchronization resource invalidation operation is an operation performed by the target processing unit to clean up local shared synchronization resources and clear expired cached data.

[0146] Specifically, the first-level resource manager continuously monitors the count of pending responses in the lifecycle record of the computing blocks. When it confirms that a task completion notification has been sent to the upstream scheduler and the count of pending responses has decreased to zero, it means that all target processing units have returned invalidation operation completion responses. When both conditions are met, the first-level resource manager determines that the target computing task has been completed and then enters the subsequent entry release process.

[0147] Furthermore, based on the above embodiments, the method further includes:

[0148] The upstream scheduler determines whether there are available table entries for resources by using the valid bits of the lifecycle records of each compute block in the block tracking table.

[0149] The upstream scheduler determines whether each target processing unit has the resource capacity to carry the sub-tasks corresponding to the target computing task based on the final available credit value corresponding to each target processing unit and the second execution status information.

[0150] When the first-level resource manager has available table entries and the resource capabilities of all target processing units meet the resource requirements of the target computing task, the upstream scheduler determines that the target computing task meets the execution conditions.

[0151] In this embodiment, available table entries are records of the lifecycles of idle computing blocks in the block tracking table that are invalid in the valid bit and can be allocated to new computing tasks. Execution conditions are the resource prerequisites that the target computing task must meet to start and execute normally.

[0152] Specifically, the upstream scheduler determines whether there are available table entries in the first-level resource manager based on the valid bits of the lifecycle records of each computing block in the block tracking table; the upstream scheduler determines whether each target processing unit has the resource capacity to carry the subtasks corresponding to the target computing task based on the final available credit value corresponding to each target processing unit and the second execution status information; when there are available table entries in the first-level resource manager and the resource capacity of all target processing units meets the resource requirements of the target computing task, the upstream scheduler determines that the target computing task meets the execution conditions.

[0153] For example, the upstream scheduler initiates a status query to the first-level resource manager to obtain the valid bit information of all computation block lifecycle records in the block tracking table, and counts the free entries to determine whether the first-level resource manager can accept new tasks. The upstream scheduler obtains the final available credit value of the corresponding processing unit and the second execution status information in the task slot table from each second-level resource manager, and compares the resources required by the target computation task subtasks to determine whether the load of each processing unit meets the standard. When there are free entries in the block tracking table and the resource capabilities of all target processing units meet the standard, the upstream scheduler determines that the execution conditions are met, and then initiates a resource request. The first-level resource manager allocates a free entry in the block tracking table and writes the task-related information, and then sends a resource request to the corresponding target second-level resource manager according to the processing unit mask.

[0154] By having the upstream scheduler uniformly check the free entries in the first-level resource manager's table based on the valid bits of the computation block lifecycle records in the block tracking table, and by combining the final available credit value of each target processing unit with the second execution status information, the processing unit's capacity to handle subtasks is comprehensively evaluated. Only when there are available entries in the first level and the resource capacity of all target processing units meets the requirements is the target computation task deemed ready for execution. The cluster-side table entry resource verification and the processing unit-side load capacity verification are uniformly handled by the upstream scheduler for centralized decision-making, which identifies resource bottlenecks in both levels of resources in advance. This avoids task execution failures caused by the lack of free entries in the first level or the downstream processing unit's overload, reduces invalid resource request interactions, reasonably controls the timing of task admission, balances the task load of each processing unit, and improves the success rate of task scheduling and resource utilization efficiency of the entire hierarchical resource management system.

[0155] Furthermore, based on the above embodiments, the method further includes:

[0156] When a target resource request is received from the upstream scheduler, the target computing task is bound to the block identifier of the target computing block, and a new lifecycle record of the target computing block matching the target computing task is created in the block tracking table.

[0157] The valid bits in the lifecycle record of the target computing block are set to valid, the bound computing task identifier and processing unit mask are written, and the count of threads to be completed, the end notification enable bit, the synchronization resource invalidation enable bit, the state machine ready flag, and the count of responses to be reclaimed are initialized; wherein, the count of responses to be reclaimed is assigned a value according to the number of valid bits in the target processing unit mask;

[0158] Furthermore, after determining that the target computation task has been completed, the method further includes:

[0159] In the block tracking table, the lifecycle record of the target computing block is released, and the block identifier of the target computing block is reclaimed.

[0160] In this embodiment, the target computing block lifecycle record is a newly created entry in the block tracking table, used to record the running status of the target computing task on the cluster side throughout its entire process.

[0161] Specifically, when the first-level resource manager receives a target resource request from the upstream scheduler, it binds the target computing task with the block identifier of the target computing block and selects an idle entry in the block tracking table as the lifecycle record of the target computing block.

[0162] Set the valid bits in the lifecycle record of the target computation block to be valid, write the bound computation task identifier and the processing unit mask of the task processing unit to be marked, and perform initial assignment of the count of threads to be completed, the end notification enable bit, the synchronization resource invalidation enable bit, the state machine ready flag, and the number of valid bits of the processing unit mask to be traversed and assigned to the count of responses to be recycled.

[0163] The system continuously monitors the number of threads to be completed, the completion status of the process, and the number of responses to be recycled. Once all three conditions are met, the target computation task is deemed to have ended. In the block tracking table, the lifecycle record of the target computation block is released, and the block identifier of the target computation block is recycled for binding by subsequent new computation tasks.

[0164] Upon receiving a target resource request from the upstream scheduler, the first-level resource manager binds the target computation task to the block identifier of the target computation block and creates a corresponding computation block lifecycle record. It uniformly initializes the valid bits, computation task identifier, processing unit mask, and various counting fields and flags. Furthermore, it accurately assigns values ​​to the count of responses to be recycled based on the number of valid bits in the processing unit mask. After the task execution is complete, the corresponding table entry is released and the block identifier is recycled. A stable association is established between the computation task and the block tracking table entry based on the block identifier. Standardized initialization operations ensure consistency in the initial state of each status field, accurately recording the set of processing units participating in the task. This provides a reliable data foundation for subsequent subtask completion statistics and collection of synchronized resource invalidation responses. Simultaneously, the unified recycling of table entries and block identifiers after the task lifecycle ends enables the cyclical reuse of block tracking table resources, reducing the overhead of frequent creation and destruction of management resources and ensuring the integrity and accuracy of task status tracking in scenarios with multiple concurrent computation tasks.

[0165] Furthermore, based on the above embodiments, the method further includes:

[0166] Receive credit value information reported by the second-level resource manager; wherein, the credit value information is generated by the second-level resource manager when it detects that the managed processing unit is in an idle state, and initializes the thread credit value of the processing unit to the pre-configured number of idle adaptation threads;

[0167] When the initialized credit value information corresponding to the idle processing unit is received, the credit value prompt information of the idle processing unit is pushed to the upstream scheduler so that the upstream scheduler can send a new resource request to the processing unit according to the credit value prompt information.

[0168] In this embodiment, the credit value information is a status message generated and reported to the first-level resource manager after the second-level resource manager detects that a processing unit under its management has become idle and completes the thread credit value initialization. The thread credit value is an indicator that quantifies the number of subtask threads a processing unit can handle. The number of idle adaptable threads is a pre-configured value representing the maximum number of threads that a processing unit can support running in parallel when it is completely idle. An idle processing unit is a processing unit that currently has no subtasks running and its resources are idle. The credit value prompt information is a notification message pushed by the first-level resource manager to the upstream scheduler after receiving the initialized credit value information, informing the scheduler that the processing unit has returned to idle and is ready to take on new tasks.

[0169] Specifically, the first-level resource manager receives the credit value information reported by the second-level resource manager. This credit value information is generated by the second-level resource manager after it detects that the processing unit it manages has entered an idle state and initializes the thread credit value of the processing unit to the pre-configured number of idle adaptable threads. When the first-level resource manager receives the credit value information after the idle processing unit has been initialized, it pushes the corresponding credit value prompt information to the upstream scheduler.

[0170] Once the upstream scheduler receives the notification, it will know that the processing unit has become idle and has resource capabilities. It can then directly send a resource request for a new task to the processing unit without having to initiate additional resource query interactions.

[0171] In addition to actively initializing the credit value when the processing unit changes from busy to idle, the second-level resource manager can also respond to the query commands of the first-level resource manager to update the credit value as needed. The active reporting mode and the passive query mode can work together.

[0172] The first-level resource manager receives credit value information generated and reported by the second-level resource manager after the processing unit becomes idle and initializes the thread credit value to the pre-configured number of idle adaptable threads. The first-level resource manager then pushes the corresponding credit value prompt information to the upstream scheduler, enabling the upstream scheduler to obtain the idle status and resource capabilities of the processing unit in a timely manner. This eliminates the need to repeatedly initiate resource query requests and avoids the round-trip interaction delay caused by queries. Once the idle processing unit completes credit value initialization, it can be quickly detected by the scheduler and accept new resource requests, shortening the scheduling startup latency of new tasks and improving the resource reuse efficiency of the processing unit and the task scheduling throughput of the entire hierarchical resource management architecture.

[0173] The technical solution of this invention involves a first-level resource manager handling the global state maintenance of computing tasks. Upon receiving a resource request from the upstream scheduler, it feeds back the first execution status information. It waits for the upstream scheduler to comprehensively consider both levels of resource information to determine if the execution conditions are met and then issues the target resource request before initializing the corresponding computing task's state. This independent implementation of global task-level state control by the first-level resource manager avoids excessive processing load caused by the mixing of global task management and fine-grained resource statistics within the processing unit. The first-level resource manager continuously receives subtask completion information reported by the processing unit and updates the first execution status information, enabling complete tracking of the entire computing task's lifecycle. When all subtasks are identified as completed... Only after reporting the task completion status to the upstream scheduler and triggering the synchronization resource invalidation operation can the completion of the target computing task be determined. This allows for global overall management and control of the synchronization resource reclamation process. By leveraging the global perspective of the first-level resource manager, it avoids data inconsistencies and resource pollution caused by ending the task process before it is fully completed. At the same time, it works in conjunction with the upstream scheduler to integrate resource information from both levels for scheduling decisions, reducing scheduling errors caused by incomplete status information. This improves the reliability of task status management during the execution of parallel computing tasks, ensures the orderly reclamation of block-level shared synchronization resources, and improves the overall task scheduling performance.

[0174] Example 3

[0175] Figure 4 This is a flowchart of another hierarchical resource management method for computing tasks in a parallel computing processor, provided in Embodiment 3 of the present invention. This embodiment is applicable to the hierarchical resource management of computing tasks in scenarios where multiple computing tasks are executed concurrently within a parallel computing processor. This method can be executed by the second-level resource manager in the hierarchical resource management system for computing tasks in a parallel computing processor as described in any embodiment of the present invention. Figure 4 As shown, the method includes:

[0176] S410. Maintain in real time the second execution status information of each type of subtask currently in execution state in the managed processing unit, as well as the final available credit value of the managed processing unit.

[0177] Optionally, based on the above embodiments, the second-level resource manager specifically includes a task slot table corresponding to the managed processing unit and resource credit value calculation hardware. The task slot table includes multiple task slots, and each task slot stores the running thread count value corresponding to a subtask of a certain type, which serves as the second execution status information. Different subtask operations correspond to different types. The resource credit value calculation hardware is used to calculate the final available credit value of the processing unit managed by the second-level resource manager in real time.

[0178] Correspondingly, the system maintains in real time the second execution status information of each type of subtask currently in execution within the managed processing unit, as well as the final available credit value of the managed processing unit, specifically including:

[0179] When a target resource request is received from the upstream scheduler, the task slot table is searched. If a task slot that matches the subtask type of the target resource request already exists, the running thread count value of that task slot is incremented and updated. Otherwise, an idle task slot is allocated, and the running thread count value of the corresponding subtask type is written into the newly allocated task slot.

[0180] When the subtask completion information is received from the managed processing unit, the running thread count value of the corresponding subtask type task slot is decremented and updated.

[0181] When the thread count of a task slot decreases to zero, the task slot is released.

[0182] When a resource status message is received from the managed processing unit, the final available credit value of the processing unit is obtained by real-time hardware calculation based on the running thread count value of each task slot in the task slot table and the resource credit value.

[0183] When the managed processing unit is detected to be in an idle state, the thread credit value is directly initialized to the pre-configured number of idle adaptable threads to obtain the corresponding final available credit value.

[0184] Specifically, the second-level resource manager configures the task slot table and resource credit value calculation hardware corresponding to the processing unit. Each task slot in the task slot table stores the running thread count value corresponding to a type of subtask as the second execution status information. The resource credit value calculation hardware calculates the final available credit value of the processing unit in real time.

[0185] When maintaining the second execution status information and the final available credit value, after receiving the target resource request issued by the upstream scheduler, the task slot table is searched. If a slot with a matching subtask type exists, the running thread count is incremented. If no matching slot exists, an idle task slot is allocated and the corresponding count value is written.

[0186] When the processing unit reports that a subtask has been completed, the running thread count for the corresponding slot is decremented and updated. The task slot is automatically released when the count drops to zero.

[0187] After receiving the resource status message actively reported by the processing unit, the final available credit value is obtained by combining the running thread count values ​​of all task slots and relying on the resource credit value to calculate the hardware in real time.

[0188] When a processing unit is detected to be in an idle state, the thread credit value is directly initialized to the pre-configured number of idle adaptable threads, which is used as the current final available credit value.

[0189] Task slots support automatic allocation based on minimum identifier priority and automatic release when the count reaches zero. A query locking mechanism can also be added to avoid scheduling errors caused by expired information. That is, it maintains the task identifier that the current processing unit is interacting with. When the current connected task is different from the query task and the last query result has not been returned, a locking signal is output to prevent incorrect scheduling decisions based on expired resource information.

[0190] Credit score calculation supports global throttling and task-mode fine-grained flow. The final usable credit score is the minimum value of multiple resource constraint dimensions, ensuring that resource assessment is conservative and reliable and preventing over-allocation of resources.

[0191] For example, based on real-time credit calculation, the resource availability assessment of processing units is implemented. The second-level resource manager maintains a real-time thread credit value for each processing unit and dynamically completes the calculation periodically. The thread credit value is jointly determined by the number of idle threads, the number of hardware running threads, and the running thread count obtained by summing all task slots. The calculation logic is: Intermediate Credit Value = Number of Idle Threads + Number of Hardware Running Threads - Running Thread Count Obtained by Summing All Task Slots. The number of idle threads and the number of hardware running threads are derived from resource status messages actively reported by the processing units, and the running thread count obtained by summing all task slots is obtained by accumulating the in-flight thread counts within the local task slots.

[0192] The number of running threads in the hardware refers to the number of threads currently physically executing at the processing unit hardware level. It is a real-time hardware operation statistic, directly collected by the processing unit hardware and reported to the second-level resource manager through resource status messages. For example, it includes threads occupying computing paths and executing instructions on the chip hardware.

[0193] The total number of running threads (in-flight) obtained by summing all task slots is a statistical count maintained by the second-level resource manager or hardware management side and exists in the task slot table. It is incremented when a task resource request is received and decremented when a subtask is completed; it represents threads that have been issued and scheduled, but are not necessarily currently executing on hardware. For example, it includes all subtask threads that have been initiated but not yet completed, including threads that are currently executing and those that have been scheduled and queued for hardware resources.

[0194] The system supports multiple resource constraint pre-allocation modes and features a dual-mode throttling mechanism. The maximum number of threads per task is configured by the upstream scheduler or software, limiting the maximum number of threads a single task can utilize. The throttling mechanism has two modes: global and task-specific. In global mode, the count of running threads for all tasks within the processing unit is statistically analyzed to achieve global resource throttling control. In task mode, only the count of running threads for the current task is analyzed, enabling fine-grained flow control at the task level. Resource constraints also include idle slot limitations determined by the processing unit's hardware resources, such as SIMD width and the number of register sets, as well as idle thread information provided by the processing unit in real time.

[0195] Ultimately, the available credit value is selected as the minimum value among the calculation results of multiple resource constraint dimensions. This ensures the conservatism and accuracy of resource assessment. If any resource dimension reaches a bottleneck, the overall resource is deemed unavailable, avoiding the problem of over-commitment of resources. When a processing unit is idle, the thread credit value is directly initialized to the pre-configured number of idle adaptable threads, without waiting for the round-trip delay caused by resource queries, thus enabling the rapid startup of idle processing units.

[0196] In a specific example, the resource availability result calculation process can be as follows:

[0197] Using task type as the query input, the throttling mode is first determined. Selecting global mode yields the global mode result, while selecting task mode yields the task mode result. Next, it checks if the processing unit is idle. If idle, it starts quickly and assigns the thread credit value to the pre-configured number of idle threads. If not idle, the hardware output result is calculated based on the resource credit value. The resource credit value calculation hardware uses the number of locally maintained task slots and processing unit resource messages (idle / running tasks) to perform the calculation according to the formula: Real-time Credit Value = Idle Count + Running Count - In-Transit Count. Then, it considers the idle thread information, idle slot limit, and maximum thread limit, taking the minimum value of the three to obtain the credit value. Finally, the resource availability result is output uniformly.

[0198] By configuring a task slot table and resource credit value calculation hardware within the second-level resource manager, the thread count values ​​of different types of subtasks are finely managed with independent task slots. This enables independent maintenance of second execution status information at the subtask type level. For new resource requests, existing slots are reused or idle slots are allocated to accumulate the count. The count is decremented in real time based on the feedback of subtask completion, and the slot is automatically released when the count reaches zero. This achieves accurate tracking of multi-type subtask load and cyclical reuse of slot resources. At the same time, combined with the hardware resource status messages actively reported by the processing unit and the thread counts summarized by each slot, the final available credit value is generated in real time by dedicated hardware. When the processing unit is idle, the pre-configured number of idle adaptation threads is directly initialized to quickly refresh the credit status without additional resource query interaction delay. This enables comprehensive and low-latency accurate assessment of the real-time resource load and availability of the processing unit, effectively avoiding resource over-provisioning and task backlog problems in multi-task concurrent scenarios. It provides reliable data support for the resource scheduling decisions of the upstream scheduler, significantly improving the resource utilization of the processing unit and the overall system's task scheduling stability, efficiency, and accuracy.

[0199] S420: Receive the resource request for the target computing task sent by the upstream scheduler, and return the second execution status information and the final available credit value of the target processing unit that matches the target computing task to the upstream scheduler.

[0200] S430: Receive the target resource request sent by the upstream scheduler, instruct the target processing unit to allocate target execution resources for the target computing task, and then execute the target sub-tasks of various types in the target computing task based on the target execution resources.

[0201] The target resource request is sent by the upstream scheduler when it determines that the target computing task meets the execution conditions based on the first execution status information, the second execution status information, and the final available credit value of each target processing unit.

[0202] S440. Update the matching second execution status information and the final available credit value based on the execution completion information of each target subtask fed back by each target processing unit.

[0203] Specifically, the second-level resource manager maintains in real time the second execution status information of each type of subtask within the corresponding processing unit and the final available credit value of the processing unit. When it receives a target computing task resource request from the upstream scheduler, it feeds back the second execution status information and the final available credit value of the target processing unit to the upstream scheduler. It receives the target resource request sent by the upstream scheduler, instructs the target processing unit to allocate target execution resources and run the target subtask. The target resource request is issued by the upstream scheduler after completing a feasibility assessment based on the two-level status information and credit value. The second-level resource manager receives the subtask execution completion information returned by each target processing unit and updates the corresponding second execution status information and final available credit value based on the execution completion information. The two-level resource managers carry out resource management at different granularities. The first level is for complete computing tasks, and the second level is for subtask types. Relying on the standardized request and response interface, they collaboratively complete the entire process of application, execution tracking, and waiting for release. After the subtask is completed, the three processes proceed in parallel, respectively realizing the second-level slot count update, the first-level task status notification, and the early invalidation of local shared synchronous resources.

[0204] In a specific example, the overall lifecycle management process can be:

[0205] Starting with the upstream scheduler initiating the task, the process proceeds in three phases: the application phase, the execution tracking phase, and the waiting-for-release phase. In the application phase, the first-level resource manager first queries the number of available rows in the block tracking table, and then the second-level resource manager queries the resource credit value. The process continues only if resources at both levels are available. Subsequently, the first-level block tracking table occupies one row to record the task dimension and target processing unit mask. After reading this mask, resource allocation is initiated to each second-level resource manager according to the task type. If a slot for the same type of task already exists, the in-flight thread count is incremented by one; otherwise, a new slot is allocated, and the in-flight thread count is initialized to one, completing the application. After entering the execution tracking phase, the task is sent to the downstream processing unit for execution. Whenever the i-th subtask is completed, the second-level resource manager decrements the number of in-flight threads in the corresponding slot by one. After entering the waiting release phase, three parallel processing paths are used: the first path releases the corresponding task slot in the second level when the subtask is completed, so that it can immediately take on new subtasks of the same type; the second path notifies the upstream scheduler of the task completion status and reclaims the task line when the first level determines that all subtasks are completed and the synchronization process is completed; the third path completes the invalidation processing of local shared synchronization resources by each processing unit and releases the shared resources in advance. Finally, the task ends after all three paths are completed.

[0206] The technical solution of this invention continuously maintains the second execution status information of the subtask dimension and the final available credit value of the processing unit locally through a second-level resource manager. When a resource request is received from the upstream scheduler, the local real-time statistical status and credit value data are directly returned to the scheduler without the scheduler initiating additional query interaction. This eliminates the round-trip transmission delay caused by resource status queries and provides the upstream scheduler with timely and accurate information on processing unit resources, facilitating reliable execution condition judgment by the scheduler. After receiving the target resource request, the second-level resource manager controls the processing unit to complete resource allocation and subtask execution. It also updates the second execution status information and the final available credit value in real time based on the subtask execution completion information reported by the processing unit, continuously refreshing the subtask operation statistics and resource capabilities within the processing unit. Relying on local tracking and statistics of subtask granular operation data, it can realize resource management within the processing unit in multi-task concurrent scenarios, enabling fine-grained perception of the operation status of various subtasks, preventing the situation where a single task excessively occupies the hardware resources of the processing unit, thereby improving the real-time performance and resource isolation capabilities of the processing unit-side resource statistics, and assisting the efficient and stable operation of the entire parallel computing processor hierarchical scheduling system.

[0207] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0208] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0209] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A hierarchical resource management system for computing tasks in a parallel computing processor, characterized in that, include: Multiple first-level resource managers are set at the cluster level and multiple second-level resource managers are set at the processing unit level; The processing unit is configured with multiple processing units in a hierarchical manner. Each second-level resource manager is configured with one processing unit, and each second-level resource manager is used to manage the corresponding configured processing unit. Each first-level resource manager and the matched second-level resource manager establish a communication connection through a standardized request-response interface. Each first-level resource manager determines the matched second-level resource manager through a processing unit mask. The first execution status information of each computing task currently in execution is maintained in real time in the first-level resource manager, and the second execution status information of each type of subtask currently in execution in the managed processing unit, as well as the final available credit value of the managed processing unit, are maintained in real time in the second-level resource manager. The first-level resource manager is used to receive resource requests for target computing tasks sent by the upstream scheduler, return first execution status information to the upstream scheduler, and initialize the first execution status information corresponding to the target computing task when receiving the target resource request sent by the upstream scheduler; and update the matching first execution status information according to the execution completion information of each target subtask fed back by the target processing unit to the first-level resource manager. The second-level resource manager is used to receive resource requests for target computing tasks sent by the upstream scheduler, return second execution status information and the final available credit value of the target processing unit matching the target computing task to the upstream scheduler, and, based on the target resource requests sent by the upstream scheduler, instruct the target processing unit to allocate target execution resources for the target computing task, and then execute various types of target subtasks in the target computing task based on the target execution resources. In addition, based on the execution completion information of each target subtask fed back by the target processing unit to the second-level resource manager, the matching second execution status information and the final available credit value are updated; wherein, the target resource request is sent by the upstream scheduler when it determines that the target computing task meets the execution conditions based on the first execution status information, the second execution status information and the final available credit value of each target processing unit; The first-level resource manager is further configured to, after determining that all target subtasks in the target computing task have been executed based on the currently maintained first execution status information, notify the upstream scheduler of the task completion status of the target computing task, and issue instructions to the target processing unit according to the processing unit mask to trigger the target processing unit to perform a local shared synchronization resource invalidation operation on the target execution resources, and, after determining that the task completion status notification has been completed and all target processing units have successfully completed the synchronization resource invalidation operation, determine that the target computing task has been executed.

2. The system according to claim 1, characterized in that, The first-level resource manager includes a block tracking table, which includes multiple compute block lifecycle records. Each compute block lifecycle record stores the first execution status information of a compute task that is currently in the execution state. The second-level resource manager specifically includes a task slot table corresponding to the managed processing unit. The task slot table includes multiple task slots. Each task slot stores the running thread count value corresponding to a subtask of a certain type, which serves as the second execution status information. Different subtask operations correspond to different types.

3. The system according to claim 1 or 2, characterized in that, The first-level resource manager also includes multiple first-in-first-out resource response tracking queues, with one resource response tracking queue corresponding to one processing unit; The first-level resource manager is also used to obtain the block identifier of the target computing block that matches the target computing task after the target processing unit performs the invalidation operation of the local shared synchronous resource on the target execution resource, and push the block identifier of the target computing block into the resource response tracking queue of the target processing unit. In addition, whenever an invalidation operation completion response matching the current processing unit is received, the head block identifier is popped from the resource response tracking queue matching the current processing unit, and the current processing unit is reclaimed according to the head block identifier, and the first execution status information is updated.

4. The system according to claim 1 or 2, characterized in that, The second-level resource manager also includes hardware for calculating resource credit values; The resource credit value calculation hardware is used to calculate the final available credit value of the processing unit managed by the second-level resource manager in real time based on the running thread count values ​​of each type of subtask recorded in the task slot table of the processing unit managed by the second-level resource manager.

5. A hierarchical resource management method for computing tasks in a parallel computing processor, characterized in that, Executed by a first-level resource manager in a hierarchical resource management system for computational tasks in a parallel computing processor as described in any one of claims 1-4, the method comprises: Maintain the first execution status information of each computing task currently in execution in real time; When receiving a resource request for a target computing task sent by the upstream scheduler, the system returns first execution status information to the upstream scheduler, and when receiving a target resource request sent by the upstream scheduler, it completes the initialization of the first execution status information corresponding to the target computing task; wherein, the target resource request is sent by the upstream scheduler when it determines that the target computing task meets the execution conditions based on the first execution status information, the second execution status information and the final available credit value of each target processing unit; Upon receiving the execution completion information of each target subtask from the target processing unit, the matching first execution status information is updated based on the execution completion information; After determining that all target subtasks in the target computing task have been executed based on the currently maintained first execution status information, the upstream scheduler is notified of the task completion status of the target computing task, and an instruction is issued to the target processing unit according to the processing unit mask to trigger the target processing unit to perform a local shared synchronization resource invalidation operation on the target execution resources. The execution of the target computation task is considered complete after the notification confirms the completion of the task and all target processing units have successfully completed the synchronization resource invalidation operation.

6. The method according to claim 5, characterized in that, The first-level resource manager includes a block tracking table, which includes multiple compute block lifecycle records. Each compute block lifecycle record stores the first execution status information of a compute task that is currently in the execution state. The first execution status information includes: a valid bit, a computation task identifier, a count of threads to be completed, an end notification enable bit, a synchronization resource invalidation enable bit, a processing unit mask, a state machine ready flag, and a count of responses to be recycled. Accordingly, the initialization of the first execution state information corresponding to the completion of the target computation task includes: Create a new lifecycle record for a computation block that matches the target computation task. Initialize the valid bits, computation task identifier, and processing unit mask in the record. Also initialize the count of threads to be completed, the end notification enable bit, the synchronization resource invalidation enable bit, the state machine ready flag, and the count of responses to be reclaimed. Based on the execution completion information, update the first matching execution status information, including: Based on the execution completion information, update the count of pending threads in the lifecycle record of the computation block that matches the computation task to which the target subtask belongs; Maintain in real-time the first execution status information of each computational task currently in execution, including: When the conditions for the end of a task are met, update the end notification enable bit and the synchronization resource invalidation enable bit of the lifecycle record of the computing block that matches the corresponding computing task, and trigger the notification of the end of the task and the synchronization resource invalidation operation. During the execution of a computation task, the state machine readiness flag in the lifecycle record of the corresponding computation block is updated to mark the running readiness state of the state machine corresponding to the computation task. When a completion response for the synchronization resource invalidation operation is received from the target processing unit, the count of responses to be reclaimed in the lifecycle record of the computing block that matches the corresponding computing task is updated. When a computing task meets the release conditions, the valid position of the computing block lifecycle record that matches the corresponding computing task identifier will be invalidated, and the computing block lifecycle record will be released for reuse by a new computing task.

7. The method according to claim 6, characterized in that, The method further includes: The upstream scheduler determines whether there are available table entries for resources by using the valid bits of the lifecycle records of each compute block in the block tracking table. The upstream scheduler determines whether each target processing unit has the resource capacity to carry the sub-tasks corresponding to the target computing task based on the final available credit value corresponding to each target processing unit and the second execution status information. When the first-level resource manager has available table entries and the resource capabilities of all target processing units meet the resource requirements of the target computing task, the upstream scheduler determines that the target computing task meets the execution conditions.

8. The method according to claim 7, characterized in that, The method further includes: When a target resource request is received from the upstream scheduler, the target computing task is bound to the block identifier of the target computing block, and a new lifecycle record of the target computing block matching the target computing task is created in the block tracking table. The valid bits in the lifecycle record of the target computing block are set to valid, the bound computing task identifier and processing unit mask are written, and the count of threads to be completed, the end notification enable bit, the synchronization resource invalidation enable bit, the state machine ready flag, and the count of responses to be reclaimed are initialized; wherein, the count of responses to be reclaimed is assigned a value according to the number of valid bits in the target processing unit mask; Furthermore, after determining that the target computation task has been completed, the method further includes: In the block tracking table, the lifecycle record of the target computing block is released, and the block identifier of the target computing block is reclaimed.

9. The method according to claim 8, further comprising, after triggering the target processing unit to perform a local shared synchronization resource invalidation operation on the target execution resource, the method further comprising: Obtain the block identifier of the target computing block that matches the target computing task, and push the block identifier of the target computing block into the resource response tracking queue of the target processing unit; Based on the processing unit mask in the target computing block lifecycle record, determine the number of target processing units to execute the target computing task, and update the count of responses to be recycled in the target computing block lifecycle record according to the number of target processing units. Whenever an invalidation operation completion response matching the current processing unit is received, the head block identifier is popped from the resource response tracking queue matching the current processing unit. Based on the head block identifier, the current processing unit is reclaimed, and the count of responses to be reclaimed in the lifecycle record of the compute block matching the head block identifier in the block tracking table is updated.

10. The method according to claim 9, characterized in that, The method further includes: Receive credit value information reported by the second-level resource manager; wherein, the credit value information is generated by the second-level resource manager when it detects that the managed processing unit is in an idle state, and initializes the thread credit value of the processing unit to the pre-configured number of idle adaptation threads; When the initialized credit value information corresponding to the idle processing unit is received, the credit value prompt information of the idle processing unit is pushed to the upstream scheduler so that the upstream scheduler can send a new resource request to the processing unit according to the credit value prompt information.

11. A hierarchical resource management method for computing tasks in a parallel computing processor, characterized in that, Executed by a second-level resource manager in a hierarchical resource management system for computational tasks in a parallel computing processor as described in any one of claims 1-4, the method comprises: Maintain in real time the second execution status information of each type of subtask currently in execution in the managed processing unit, as well as the final available credit value of the managed processing unit; Receive the resource request for the target computing task sent by the upstream scheduler, and return the second execution status information and the final available credit value of the target processing unit that matches the target computing task to the upstream scheduler; After receiving a target resource request sent by the upstream scheduler, the target processing unit is instructed to allocate target execution resources to the target computing task, and then executes various types of target subtasks in the target computing task based on the target execution resources; wherein, the target resource request is sent by the upstream scheduler when it determines that the target computing task meets the execution conditions based on the first execution status information, the second execution status information and the final available credit value of each target processing unit; The second execution status information and the final available credit value are updated based on the execution completion information of each target subtask fed back by each target processing unit.

12. The method according to claim 11, characterized in that, The second-level resource manager specifically includes a task slot table corresponding to the managed processing unit and resource credit value calculation hardware. The task slot table includes multiple task slots, and each task slot stores the running thread count value corresponding to a type of subtask as the second execution status information. Different subtask operations correspond to different types. The resource credit value calculation hardware is used to calculate the final available credit value of the processing unit managed by the second-level resource manager in real time. Correspondingly, the system maintains in real time the second execution status information of each type of subtask currently in execution within the managed processing unit, as well as the final available credit value of the managed processing unit, specifically including: When a target resource request is received from the upstream scheduler, the task slot table is searched. If a task slot that matches the subtask type of the target resource request already exists, the running thread count value of that task slot is incremented and updated. Otherwise, an idle task slot is allocated, and the running thread count value of the corresponding subtask type is written into the newly allocated task slot. When the subtask completion information is received from the managed processing unit, the running thread count value of the corresponding subtask type task slot is decremented and updated. When the thread count of a task slot decreases to zero, the task slot is released. When a resource status message is received from the managed processing unit, the final available credit value of the processing unit is obtained by real-time hardware calculation based on the running thread count value of each task slot in the task slot table and the resource credit value. When the managed processing unit is detected to be in an idle state, the thread credit value is directly initialized to the pre-configured number of idle adaptable threads to obtain the corresponding final available credit value.

Images