A method, module, system, device and program product for cooperative processing of a multi-core asymmetric multiprocess architecture

Abstract

The application provides a cooperative processing method, module, system, device and program product of a multi-core asymmetric multiprocessor architecture, relates to the technical field of asymmetric multi-core systems, and determines the running load of each processor core, schedules a to-be-migrated service task from a source core to a target core when the load is unbalanced, and provides connection execution information to the target core by using a task pool shared by each processor core, so that the target core can continue to execute the to-be-migrated service task according to the connection execution information. The application can dynamically adjust the distribution of service tasks among processor cores according to the running load, alleviate the problem that some cores are overloaded while other cores are idle, and at the same time, without migrating the hardware execution context of the source core, the transmission amount and recovery overhead of the execution state in the cross-core migration process are reduced, so that the resource utilization rate and task processing efficiency of the multi-core processor are improved.

Description

Technical Field

[0001] This application relates to the field of asymmetric multi-core system technology, and in particular to a collaborative processing method, module, system, device and program product of a multi-core asymmetric multiprocessing architecture. Background Technology

[0002] With the increasing workload of embedded systems, multi-core processors are widely used to execute business tasks in parallel. In asymmetric multiprocessing (AMP) architecture, each processor core typically has a relatively independent operating environment, and business tasks are assigned to the corresponding processor core for execution during system initialization or task creation.

[0003] However, the number and processing load of business tasks can change depending on the system's operating status. When using a fixed task allocation method, some processor cores may be carrying a large number of tasks, while other processor cores may be idle or under low load, resulting in an imbalance in load among the processor cores and affecting the resource utilization and business processing efficiency of the multi-core processor.

[0004] To adjust task distribution, business tasks are typically migrated from one processor core to another. For ongoing business tasks, existing migration methods usually require saving and restoring processor execution states such as the program counter and general-purpose register states, and may involve copying and synchronizing the operating system task stack and related runtime data. Since different processor cores have their own runtime contexts, the above migration process is quite complex and incurs significant data transfer and state restoration overhead. Summary of the Invention

[0005] The technical problem solved by this application is to provide a collaborative processing method, module, system, device and program product for a multi-core asymmetric multiprocessing architecture, so as to overcome the defects of existing migration processes that generate large data transmission and state recovery overhead.

[0006] Firstly, this application proposes a collaborative processing method for a multi-core asymmetric multiprocessor architecture, applicable to multi-core processors; the multi-core processor includes multiple processor cores and a task pool shared by the multiple processor cores; the method includes: Obtain business tasks and assign the business tasks to at least one of the plurality of processor cores for execution; Determine the operating load of each processor core, and determine the load distribution state based on each operating load; When the load distribution status indicates that there is an unbalanced load, the service tasks to be migrated and the source cores and target cores used for migration and continued execution of the service tasks to be migrated are determined according to the load distribution status. The continuation execution information of the business task to be migrated is stored in the task pool, and the business task to be migrated is scheduled to the target core, so that the target core obtains the continuation execution information from the task pool and continues to execute the business task to be migrated according to the continuation execution information without migrating the hardware execution context on the source core.

[0007] In one embodiment, the plurality of processor cores includes a master core and at least one slave core; The step of determining the operating load of each processor core and determining the load distribution state based on each operating load includes: The main control core and each of the subordinate cores are used to determine their own operating load; Using the main control core, the load distribution state is determined based on its own operating load and the operating load of each of the subordinate cores; The main control core and each of the subordinate cores run operating system instances based on the same operating system image, load the same business code, and execute the assigned business tasks through task executors with the same structure.

[0008] In one embodiment, the step of using the main control core and each of the subordinate cores to determine their own operating load includes: Using the main control core and each of the subordinate cores, the number of business tasks assigned to each core is counted, and the preset task weight of each business task is obtained. Using the main control core and each of the subordinate cores, the sum of the preset task weights of all current business tasks is calculated based on the number of business tasks and the preset task weights, and the sum of the preset task weights is determined as its own operating load.

[0009] In one embodiment, when the load distribution state indicates a load imbalance, determining the service task to be migrated and the source core and target core for migrating out and continuing execution of the service task to be migrated, respectively, based on the load distribution state, includes: Using the main control core, the operating loads are compared to determine the maximum and minimum operating loads, and the load difference between the two is calculated. If the load difference exceeds a preset threshold, it is determined that there is a load imbalance. The processor core corresponding to the maximum operating load is determined as the source core, and the processor core corresponding to the minimum operating load is determined as the target core. For each business task currently assigned to the source core, the predicted load difference for migrating each business task to the target core is calculated based on the corresponding preset task weight, and the business task to be migrated is determined based on the predicted load difference.

[0010] In one embodiment, assigning the business task to at least one of the plurality of processor cores for execution includes: The business tasks are organized into task queues consisting of multiple business processing units; Each of the processor cores executes the corresponding business processing unit sequentially according to the task queue, and updates the task progress information used to indicate the execution position of the business task.

[0011] In one embodiment, the continuation execution information includes task progress information and business status information; The step of storing the continuation execution information of the business task to be migrated into the task pool includes: Using the source core, during the execution of the business task to be migrated, business status information is generated and updated; the business status information includes at least one of the task parameters, business data, and resource dependency information required to continue executing the next business processing unit to be executed. When the current business processing unit is completed and the next business processing unit has not yet been executed, the task progress information is updated to indicate the next business processing unit to be executed; According to the preset task data structure, the updated task progress information and the business status information are combined into the follow-up execution information, and the follow-up execution information is written into the task pool.

[0012] In one embodiment, the step of continuing to execute the service task to be migrated according to the continuation execution information includes: Using the target core, the next business processing unit to be executed is determined in the task queue based on the task progress information; Based on the business status information, restore the business data required to execute the next pending business processing unit; The task executor of the target core is used to call the business code loaded in the target core to execute the business task to be migrated starting from the next business processing unit to be executed, and to update the task progress information and the business status information after the business processing unit is completed.

[0013] In one embodiment, scheduling the service task to be migrated to the target core includes: Obtain the core identifier of the target core; write the core identifier into the task scheduling attribute corresponding to the business task to be migrated, so as to specify the target core to execute the business task to be migrated.

[0014] Using the target core, the corresponding continuation execution information is extracted from the task pool according to its own core identifier, and the business task to be migrated is added to the task queue of the target core.

[0015] In one embodiment, the target core obtains the continuation execution information from the task pool, including: The target core's task executor accesses the task pool and matches its own core identifier with the task scheduling attribute. If the match is successful, it obtains the corresponding continuation execution information from the task pool and adds the business task to be migrated to the target core's task queue according to the continuation execution information.

[0016] Secondly, this application proposes a collaborative processing module suitable for multi-core processors; the multi-core processor includes multiple processor cores and a task pool shared by the multiple processor cores; the module includes: An acquisition unit is used to acquire business tasks and allocate the business tasks to at least one of the plurality of processor cores for execution. A determining unit is configured to determine the operating load of each processor core and determine the load distribution state based on the operating load; if the load distribution state indicates that there is a load imbalance, the unit determines the service task to be migrated and the source core and target core to be migrated and executed respectively, based on the load distribution state. The succession unit is used to store the succession execution information of the business task to be migrated into the task pool, and schedule the business task to be migrated to the target core, so that the target core obtains the succession execution information from the task pool and continues to execute the business task to be migrated according to the succession execution information without migrating the hardware execution context on the source core.

[0017] Thirdly, this application also provides a collaborative processing system, the system comprising: A multi-core processor, comprising multiple processor cores and a task pool shared by the multiple processor cores; The collaborative processing module described in the second aspect is used to determine the business tasks to be migrated based on the operating load of each processor core; to schedule the business tasks to be migrated from the source core to the target core using the task pool; and to enable the target core to continue executing the business tasks to be migrated based on the succession execution information stored in the task pool.

[0018] Fourthly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method of the first aspect.

[0019] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the method in the first aspect.

[0020] The aforementioned collaborative processing methods, modules, systems, devices, and program products based on multi-core asymmetric multiprocessing architectures have at least the following advantages: This application determines the operating load of each processor core and schedules the business tasks to be migrated from the source core to the target core when the load is unbalanced. It also utilizes a task pool shared by all processor cores to provide the target core with continuation execution information, enabling the target core to continue executing the business tasks to be migrated based on this information. This application can dynamically adjust the distribution of business tasks among processor cores according to the operating load, alleviating the problem of some cores being overloaded while others are idle. Simultaneously, it eliminates the need to migrate the hardware execution context of the source core, reducing the amount of execution state transfer and recovery overhead during cross-core migration, thereby improving the resource utilization and task processing efficiency of multi-core processors. Attached Figure Description

[0021] Figure 1 This is a block diagram of the collaborative processing system in one embodiment; Figure 2 This is a flowchart illustrating a collaborative processing method for a multi-core asymmetric multiprocessing architecture in one embodiment. Figure 3 This is a structural block diagram of the collaborative processing module in one embodiment; Figure 4 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0022] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0023] Some exemplary embodiments of this application have been described for illustrative purposes. It should be understood that this application may be implemented in other ways not specifically shown in the accompanying drawings.

[0024] Please see Figure 1 In one exemplary embodiment, this application provides a collaborative processing system, including a multi-core processor and a collaborative processing module. The multi-core processor serves as the hardware execution platform of the collaborative processing system, and the collaborative processing module serves as a logical functional module running on the multi-core processor, used to coordinate the execution of business tasks within the multi-core processor.

[0025] A multi-core processor consists of multiple processor cores and a task pool that is shared by the multiple processor cores.

[0026] For example, a multi-core processor can be a multi-core microcontroller, a multi-core system-on-a-chip, or other processor with multiple independent instruction execution units. Multiple processor cores can access a pool of tasks in a shared memory area via an on-chip bus, internal interconnect network, or other data transfer structures.

[0027] A processor core is a processing unit in a multi-core processor capable of independently executing program instructions. Each processor core has its own hardware execution context, including a program counter, general-purpose registers, and an operating system task stack, and can independently run a corresponding operating system instance. In one implementation, each processor core runs an operating system instance built on the same operating system image and loads the same business logic code, enabling business tasks to be executed by different processor cores. Here, the operating system image is the program and configuration data used to build the operating system instance on the processor core; the business logic code is the program code used to implement the business task processing logic.

[0028] Each processor core runs a task executor, which acquires the business tasks assigned to its corresponding processor core, executes those tasks, and updates their execution status. The task executors of multiple processor cores can employ the same program structure, enabling any processor core to execute business tasks and continue executing business tasks migrated from other processor cores. Different processor cores can be designated as master or slave cores based on their control roles, and both master and slave cores can execute business tasks.

[0029] A task pool is a logical data structure located in a shared memory area, used to store and transfer information related to business tasks among multiple processor cores. The task pool can be implemented using a task queue, task list, circular buffer, or other data structures that can be queried and read / written by multiple processor cores. The task pool can store the task identifier, scheduling target, and continuation execution information of business tasks; the continuation execution information is used to enable one processor core to continue executing business tasks that have been moved out by another processor core.

[0030] The collaborative processing module is used to determine the business tasks to be migrated based on the operating load of each processor core; it uses a task pool to schedule the business tasks to be migrated from the source core to the target core, and the target core continues to execute the business tasks to be migrated according to the continuation execution information stored in the task pool. Specifically, the collaborative processing module obtains the business tasks and allocates them to at least one of the multiple processor cores for execution; it determines the operating load of each processor core and determines the load distribution state based on the operating load; if the load distribution state indicates an unbalanced load, it determines the business tasks to be migrated and the source core and target core, respectively, for migrating out and continuing to execute the business tasks to be migrated; it stores the continuation execution information of the business tasks to be migrated in the task pool, and schedules the business tasks to be migrated to the target core, so that the target core obtains the continuation execution information from the task pool and continues to execute the business tasks to be migrated according to the continuation execution information without migrating the hardware execution context on the source core.

[0031] In the aforementioned collaborative processing system, multi-core processors provide the execution capability for business tasks, with each processor core acting as the specific task execution entity. A task pool is used to carry business tasks and their sequential execution information across multiple processor cores. The collaborative processing module utilizes the task pool to coordinate the allocation and sequential execution of business tasks across different processor cores. This dynamically adjusts the distribution of business tasks across processor cores based on the workload, alleviating the problem of some cores being overloaded while others are idle. Furthermore, each processor core establishes an operating system instance based on the same operating system image, loads the same business code, and uses a task executor with the same structure. This provides a foundation for consistent parsing and recovery of sequential execution information across different cores, reducing the risk of context incompatibility during cross-core sequential execution. Using unified business code across cores also reduces code duplication, improving the maintainability and readability of the project code. By adjusting task distribution promptly when the load changes, the possibility of unexpected processing delays in a single business task can be reduced, improving task response performance. Adding or removing processor cores does not require changing the description method and execution model of business tasks, thereby improving the scalability of the multi-core processing architecture.

[0032] Please see Figure 2 In one exemplary embodiment, this application provides a collaborative processing method for a multi-core asymmetric multiprocessor architecture, applicable to the multi-core processors provided in the above embodiments; specifically, it includes the following steps: Step 202: Obtain the business task and assign the business task to at least one of the multiple processor cores for execution.

[0033] Specifically, a business task refers to a data processing task that needs to be completed by a multi-core processor according to a preset business processing flow. After obtaining a business task, at least one processor core is determined from multiple processor cores to initially execute the business task according to preset task allocation rules, and an execution correspondence is established between the business task and the determined processor core, so that the determined processor core obtains and executes the business task.

[0034] Step 204: Determine the operating load of each processor core and determine the load distribution status based on the operating load; if the load distribution status indicates that there is an imbalance in the load, determine the business tasks to be migrated and the source core and target core used for migration and continued execution of the business tasks to be migrated, respectively, based on the load distribution status.

[0035] Specifically, workload refers to the amount of business processing currently undertaken by a processor core, which can be determined based on the business tasks that the processor core is executing and waiting to be executed. By comparing the workload of each processor core, the distribution of business tasks among multiple processor cores can be determined.

[0036] Load imbalance refers to a situation where at least one processor core has unfinished processing capacity that meets the task migration criteria, while at least another processor core has the available execution capacity to take over the tasks. Once load imbalance is identified, based on the tasks currently being handled by each processor core, a task to be migrated is selected from the tasks being executed by the processor cores that meet the migration criteria. The processor core currently executing the task to be migrated is designated as the source core, and the other processor core capable of taking over the task to be migrated is designated as the target core.

[0037] Step 206: Store the continuation execution information of the business tasks to be migrated into the task pool, and schedule the business tasks to be migrated to the target core, so that the target core can obtain the continuation execution information from the task pool and continue to execute the business tasks to be migrated according to the continuation execution information without migrating the hardware execution context on the source core.

[0038] Specifically, continuation execution information refers to the business layer information required by the target core to continue executing the business tasks to be migrated. It indicates the current position of the business tasks and the business status required for continued execution. This business status originates from task data generated or updated during the execution of the business tasks by the source core.

[0039] After identifying the business task to be migrated, the source core generates follow-up execution information based on the current execution status of the task and writes this information into the task pool. Subsequently, the subsequent execution entity of the business task to be migrated is changed from the source core to the target core, enabling the target core to obtain the corresponding follow-up execution information from the task pool and continue executing the business task to be migrated according to the execution position indicated by the follow-up execution information.

[0040] The hardware execution context is the processor context information generated when the source core executes the business task to be migrated, typically including the program counter and register states. Since each processor core loads the same business code and executes the business task through a task executor with the same structure, when the target core continues execution, it does not need to copy or restore the hardware execution context on the source core. Instead, it utilizes the target core's own hardware execution environment and continues to complete the business task to be migrated based on the execution continuation information.

[0041] It should be noted that, in other embodiments, in addition to load imbalance, business task migration can also be triggered when the available resources of the processor core change or the priority of the business task changes. Responding to the corresponding migration triggering conditions, the business task to be migrated and the target core are redefined, and the processing procedures of task gap encapsulation, task scheduling attribute updating, and target core continuation execution are reused, thereby adapting to dynamic changes in runtime resources and task scheduling requirements.

[0042] The aforementioned collaborative processing method for a multi-core asymmetric multiprocessing architecture determines the operating load of each processor core. When the load is unbalanced, the business tasks to be migrated are scheduled from the source core to the target core. Furthermore, it utilizes a task pool shared by all processor cores to provide continuation execution information to the target core, enabling the target core to continue executing the business tasks to be migrated based on this information. This application can dynamically adjust the distribution of business tasks among the processor cores according to the operating load, alleviating the problem of some cores being overloaded while others are idle. Simultaneously, it eliminates the need to migrate the hardware execution context of the source core, reducing the amount of execution state transfer and recovery overhead during cross-core migration, thereby improving the resource utilization and task processing efficiency of the multi-core processor.

[0043] Optionally, the multiple processor cores include a master core and at least one slave core; the operating load of each processor core is determined, and the load distribution state is determined based on the operating load, including: The system employs a master control core and several slave cores, each with its own operating load. The master control core determines the load distribution based on its own operating load and the operating loads of the slave cores. The master control core and each slave core run operating system instances built on the same operating system image, load the same business code, and execute the assigned business tasks through task executors with the same structure.

[0044] Specifically, the master core and slave cores represent different responsibilities of processor cores in the task scheduling process. In addition to executing the business tasks assigned to it, the master core is responsible for handling control affairs such as configuration management and resource scheduling, and aggregating the workload of each processor core. Each slave core primarily executes the business tasks assigned to it and provides its own determined workload to the master core. Both the master core and each slave core can execute ordinary business tasks.

[0045] For example, a multi-core processor provides a unified control interface, which is divided into a control interface and a business interface. The control interface is used for configuration management and resource scheduling, and is handled uniformly by the main control core; the business interface is used to execute specific business processes, and is handled separately by the task executors of the main control core and each subordinate core. The collaborative processing module runs on the independent operating system instance of each processor core, and coordinates the execution of tasks in each operating system instance through a unified task description method, task pool access interface, and scheduling rules, thereby forming a cross-operating system scheduling layer and decoupling control decisions from business execution.

[0046] The main control core and each slave core load the same operating system image and establish independent operating system instances on their respective processor cores. Therefore, each processor core has its own operating system running state, but they all have the same task scheduling interface and memory access method.

[0047] Each processor core loads the same business code, enabling the same business task to be executed on different processor cores according to the same processing logic.

[0048] The task executor is a task execution module running on each operating system instance. It retrieves business tasks assigned to the corresponding processor core, adds these tasks to the execution queue of that core, calls the corresponding business code to execute the task, and updates the execution status of the task during execution. Task executors with identical structures share the same task retrieval interface, task description method, and business code invocation method, enabling each processor core to recognize and execute business tasks described using a unified data structure.

[0049] During multi-core processor operation, the master core and each slave core determine their own workload based on the tasks currently assigned to them. After determining their workload, each slave core provides the master core with the workload and its corresponding core identifier. The master core determines its own workload and receives the workloads provided by each slave core.

[0050] The master control core organizes its own operating load and the operating load of each subordinate core according to the core identifier, forming a correspondence between each processor core and its corresponding operating load. This correspondence constitutes the load distribution state. Based on this load distribution state, the master control core determines whether there are processor cores that meet the task migration conditions and processor cores that meet the task acceptance conditions simultaneously. If both exist, it determines that there is currently a load imbalance among multiple processor cores, thereby triggering subsequent business task migration.

[0051] By adopting the above scheme, each processor core determines its own operating load, and the main control core aggregates the operating loads. This can form a unified load judgment result while preserving the independent operating capabilities of each processor core, thus avoiding conflicting task scheduling decisions made by different processor cores.

[0052] Optionally, a master control core and several slave cores are used, each determining its own operating load, including: Using a master control core and each slave core, the number of business tasks assigned to each core is counted, and the preset task weight of each business task is obtained. Using a master control core and each slave core, the sum of the preset task weights of all current business tasks is calculated based on the number of business tasks and the preset task weights, and the sum of the preset task weights is determined as the operating load of the core.

[0053] Specifically, the number of business tasks refers to the number of business tasks that have been allocated to the corresponding processor cores but have not yet been completed during this load balancing period.

[0054] The preset task weight is used to characterize the contribution of the business task to the processor core's operating load. Its value can be set by the user or predetermined according to the priority of the business task.

[0055] For example, the task information of a business task records a task identifier and a task priority. The processor core can directly obtain the preset task weight associated with the business task based on the task identifier, or it can query the preset task weight of the business task based on the task priority and the pre-established correspondence between priority and task weight.

[0056] After receiving the operating load of each slave core, the master control core determines the load distribution status based on its own operating load.

[0057] It should be noted that as business tasks are assigned, completed, or migrated, the sum of the number of business tasks and the preset task weights corresponding to each processor core also changes. Therefore, each processor core can recalculate the operating load during multi-core processor operation, allowing the main control core to determine the current task distribution based on the updated operating load.

[0058] By employing the above scheme and accumulating the preset task weights of each business task allocated to the processor core, both the number of business tasks and the differences in their contribution to the operating load can be considered simultaneously. This avoids misjudging corresponding processor cores as having the same operating load when the number of business tasks is the same but their priorities or processing volumes differ. After each processor core completes task statistics and weight accumulation locally, it only provides the calculated operating load to the main control core. This reduces the amount of data transferred between processor cores and continuously updates the load distribution status with minimal overhead, thereby improving the accuracy of load imbalance judgment.

[0059] Optionally, when the load distribution status indicates an unbalanced load, the service tasks to be migrated, as well as the source and target cores used for migration and continuation of execution of the service tasks to be migrated, are determined based on the load distribution status, including: Using the main control core, the system compares the various operating loads to determine the maximum and minimum operating loads and calculates the load difference between them. If the load difference exceeds a preset threshold, a load imbalance is identified, and the processor core corresponding to the maximum operating load is designated as the source core, while the processor core corresponding to the minimum operating load is designated as the target core. For each business task currently allocated to the source core, the system calculates the predicted load difference for migrating each business task to the target core based on the corresponding preset task weight, and determines the business tasks to be migrated based on the predicted load difference.

[0060] Specifically, the preset threshold is used to define the permissible load differences between multiple processor cores, and can be configured by the user based on the processing power of the multi-core processors and the permissible task processing latency. When the load difference does not exceed the preset threshold, it indicates that the current load difference between the processor cores has not reached the point where business tasks need to be migrated. When the load difference exceeds the preset threshold, it indicates that the business processing load borne by at least one processor core needs to be transferred to other processor cores, and the master control core determines that there is currently a load imbalance.

[0061] After determining the source and target cores, the main control core obtains all business tasks currently assigned to the source core that have not yet been completed, and designates each business task as a candidate migration task. For each candidate migration task, the main control core obtains its preset task weight and, before actually migrating the candidate migration task, predicts the operating load of the source and target cores after the migration, and calculates the predicted load difference. The predicted load difference characterizes the expected load difference between the source and target cores after the migration task is executed.

[0062] Furthermore, the main control core calculates the predicted load difference for each candidate migration task in the manner described above, and selects the candidate migration task with the smallest predicted load difference from the candidate migration tasks whose predicted load difference is less than the load difference before migration as the service task to be migrated. This ensures that the operating load between the source core and the target core is as close as possible after the migration of the service task to be migrated.

[0063] By employing the above scheme, comparing the load difference with a preset threshold, frequent task migration triggered by short-term load fluctuations between processor cores can be avoided, reducing unnecessary scheduling overhead. Furthermore, transferring business processing volume from the source core where tasks need to be migrated to the target core with the capacity to handle it improves the resource utilization of multi-core processors. Moreover, before actually migrating business tasks, calculating the predicted load difference after migration for different business tasks and selecting the business task that reduces the predicted load difference can prevent arbitrary selection of tasks to be migrated, which could lead to excessive load transfer or renewed load imbalance. This improves the accuracy of task selection and gradually balances the operating load between the source and target cores.

[0064] Optionally, task priorities and quality of service constraints such as latency and bandwidth can be pre-set in the task information. When determining the business tasks to be migrated and the target core, the main control core comprehensively considers the operating load, task priority, and quality of service constraints, so that business tasks with higher priority or close to the time limit can obtain execution resources first, thereby ensuring the processing stability of critical business.

[0065] Optionally, assigning business tasks to at least one of multiple processor cores for execution includes: Business tasks are organized into task queues consisting of multiple business processing units; each processor core executes the corresponding business processing unit in sequence according to the task queue and updates the task progress information used to indicate the execution position of the business task.

[0066] Specifically, a business processing unit is a processing step within a business task that can be invoked and completed by the task executor. Each business processing unit corresponds to a specific business code, and different business processing units are executed in the order specified by the task queue.

[0067] A task queue is a data structure organized according to the execution order of business processing units. A task queue address identifies the corresponding task queue, and the execution order of business processing units is determined by their position within the task queue. Task progress information records the current execution position of a business task. For example, task progress information can be represented by a task queue read pointer, the sequence number of the business processing unit, or the identifier of the business processing unit. After a business task is assigned to a processor core, the task executor of that processor core obtains the task queue corresponding to the business task and retrieves the currently pending business processing unit from the task queue based on the task progress information. The task executor calls the corresponding business code to execute the business processing unit, and after the business processing unit completes its execution, updates the task progress information to indicate the next pending business processing unit. The processor core executes the business processing units in the task queue sequentially in the above manner until the task progress information indicates that all business processing units in the task queue have been executed. In the case of a business task being migrated, the migrated processor core determines the position the business task has reached based on the updated task progress information.

[0068] Optionally, a business task can be broken down into multiple independently schedulable subtasks, with task progress and business status information recorded for each subtask. The main control core selects the subtasks to be migrated from among the multiple subtasks based on the operating load of each processor core and schedules them to the target core. By adopting this approach and reducing the migration granularity, task scheduling accuracy and load balancing effectiveness can be improved.

[0069] Optionally, the continuation execution information includes task progress information and business status information; the continuation execution information of the business tasks to be migrated is stored in the task pool, including: Using the source core, during the execution of the business task to be migrated, business status information is generated and updated. The business status information includes at least one of the task parameters, business data and resource dependency information required to continue the execution of the next business processing unit. When the current business processing unit is completed and the next business processing unit has not yet been executed, the task progress information is updated to indicate the next business processing unit to be executed. According to the preset task data structure, the updated task progress information and business status information are combined into the continuation execution information and written into the task pool.

[0070] Specifically, after each business processing unit is completed, the source core updates the corresponding business status information based on the processing result of that business processing unit. Once a business task to be migrated is identified, the source core continues to execute the current business processing unit, and enters a task gap for migrating the business task to be migrated when the current business processing unit is completed and the next business processing unit has not yet started.

[0071] During the task interval, the source core first writes the processing result generated by the current business processing unit into the business status information, so that the business status information is in a state consistent with the currently completed business processing process; then, it updates the task progress information to indicate the next business processing unit to be executed in the task queue, so that the execution position indicated by the task progress information is consistent with the business processing result reflected by the business status information.

[0072] The pre-defined task data structure is a unified data structure that can be recognized by both the main control core and each subordinate core. It specifies the data items included in the sequential execution information and the storage method for each data item. For example, the pre-defined task data structure may include a task queue address, a task queue read pointer indicating the task queue execution progress, task parameter addresses and task parameter lengths, task information including task identifiers and task priorities, and a target core identifier for recording scheduling targets. Business data in the business status information can be represented by data pointers to shared data areas or data snapshots, and can further record resource dependency information required by the next business processing unit to be executed. Through this unified data structure, the execution progress and business status of business tasks can be structured, serialized, and recovered by the target core, providing a data foundation for cross-core and cross-operating system instance migration.

[0073] The source core combines the updated task progress information and business status information into a continuation execution message according to a preset task data structure. The continuation execution message refers to the business layer state description of the business task, typically excluding hardware execution context such as the program counter, general-purpose register state, and operating system task stack generated when the source core executes the business task. After combining the continuation execution message, the source core writes it to a task pool shared by multiple processor cores for the target core to access.

[0074] By adopting the above scheme and generating continuation execution information between tasks, issues such as incomplete current business processing units or incomplete business status updates during migration can be avoided, ensuring consistency between task progress information and business status information. Encapsulating task progress and business status information using a unified data structure allows different processor cores to parse the continuation execution status of the business tasks to be migrated in the same way. Furthermore, the continuation execution information only stores the business-level status description, eliminating the need to store the source core's program counter, register state, and operating system task stack, thus reducing the amount of data that needs to be saved and transferred, and lowering the overhead of cross-core task migration.

[0075] Optionally, the business tasks to be migrated are executed according to the continuation execution information, including: Using the target core, the next business processing unit to be executed is determined in the task queue based on the task progress information; based on the business status information, the business data required to execute the next business processing unit to be executed is restored; using the target core's task executor, the business code loaded in the target core is called to execute the business task to be migrated starting from the next business processing unit to be executed, and the task progress information and business status information are updated after the business processing unit is completed.

[0076] Specifically, the target core determines the successor execution position of the business tasks to be migrated based on the task progress information, and restores the business state required for the next business processing unit to be executed based on the business status information. After the target core completes the business status restoration, the task executor adds the business tasks to be migrated to its own execution queue, calls the business code corresponding to the next business processing unit to be executed, and starts executing the business tasks to be migrated from that business processing unit.

[0077] The target core executes the corresponding business code using its own program counter, registers, and operating system task stack, without needing to copy or restore the source core's hardware execution context. Each time the target core completes a business processing unit, it updates the task progress information to indicate the next pending business processing unit and updates the business status information based on the processing result, until all business processing units in the task queue have been completed. The updated task progress and business status information can also be used to generate new continuation execution information when the business task subsequently undergoes cross-core migration.

[0078] By adopting the above scheme, the target core locates the next business processing unit to be executed based on the task progress information, and restores the task parameters, business data, and resource dependencies required for that business processing unit based on the business status information. This allows the target core to continue executing the business tasks to be migrated from where the source core stopped, avoiding the duplication of processing already completed business processing units. Simultaneously, the target core calls the locally loaded business code through its own task executor, without needing to copy or restore the hardware execution context of the source core, reducing the amount of data transfer and recovery complexity during task migration. Furthermore, updating the task progress and business status information after the target core executes each business processing unit ensures that the business tasks remain in a migrateable state, supporting continuous load balancing during operation.

[0079] Optionally, the business tasks to be migrated can be scheduled to the target core, including: Obtain the core identifier of the target core; write the core identifier into the task scheduling attribute corresponding to the business task to be migrated, so as to specify the target core to execute the business task to be migrated. Using the target core, extract the corresponding continuation execution information from the task pool according to its own core identifier, and add the business task to be migrated to the task queue of the target core.

[0080] Specifically, each processor core is equipped with a task executor and a core identifier that uniquely identifies the processor core. The target core's task executor obtains its own core identifier during initialization and accesses the task pool through a unified task pool access interface during multi-core processor operation.

[0081] The task pool stores the sequential execution information corresponding to one or more business tasks. The task scheduling attribute corresponding to each sequential execution information records the core identifier of the processor core designated to execute the business task.

[0082] Task scheduling attributes are properties used to indicate which processor core a business task should be executed by. For example, task scheduling attributes can be used as the target core identifier field in a predefined task data structure. Each successive execution entry in the task pool corresponds to the task scheduling attribute of the relevant business task.

[0083] The main control core writes the core identifier of the target core into the task scheduling attribute corresponding to the business task to be migrated, thus designating the target core as the subsequent execution core for the business task to be migrated. After writing the core identifier, a correspondence is established between the succession execution information in the task pool and the target core, and the task execution subject changes from the source core to the target core.

[0084] The target core obtains its own core identifier and accesses the task pool shared by multiple processor cores. Based on its own core identifier, the target core searches the task pool for successor execution information with the same core identifier recorded in the task scheduling attributes. After finding the corresponding successor execution information, the target core extracts the successor execution information and creates a task item to be executed corresponding to the business task to be migrated based on the successor execution information.

[0085] The target core adds the tasks to be executed to the task queue managed by the task executor, and starts executing the business tasks to be migrated from the next business processing unit to be executed as indicated by the task progress information.

[0086] By employing the above scheme, the core identifier of the target core is written into the task scheduling attribute of the business task to be migrated. This explicitly specifies the subsequent execution entity of the business task to be migrated, and enables the target core to obtain the corresponding successor execution information from the shared task pool based on the core identifier. This achieves targeted scheduling of the business task to be migrated from the source core to the target core. This method eliminates the need to directly transfer complete task data between the source and target cores, reduces direct communication between processor cores, and prevents the business task to be migrated from being scheduled to a non-target core.

[0087] Optionally, the target core obtains execution continuation information from the task pool, including: The target core's task executor accesses the task pool and matches its own core identifier with the task scheduling attributes. If a match is successful, it retrieves the corresponding continuation execution information from the task pool and adds the business tasks to be migrated to the target core's task queue based on the continuation execution information.

[0088] Specifically, after the target core's task executor accesses the task pool, it reads the task scheduling attributes corresponding to the continuation execution information and compares the core identifier recorded in the task scheduling attributes with the target core's own core identifier. If they are different, the match is considered unsuccessful, indicating that the corresponding business task has been scheduled to another processor core, and the target core's task executor does not retrieve the continuation execution information. If they are the same, the match is considered successful, indicating that the corresponding business task has been designated to be executed by the target core, and the target core's task executor retrieves the continuation execution information corresponding to the business task from the task pool.

[0089] Furthermore, the target core's task executor parses the continuation execution information to obtain the task identifier, task progress information, and business status information of the business task to be migrated, and generates the corresponding task items to be executed based on the above information. Subsequently, the task items to be executed are added to the target core's task queue, awaiting execution.

[0090] By employing the above scheme, and enabling each processor core's task executor to match its own core identifier with task scheduling attributes, each processor core can extract only the sequential execution information designated for its own execution, avoiding erroneous execution of tasks to be migrated. Furthermore, each processor core proactively extracts its own tasks from the task pool through a unified interface, eliminating the need for the main control core to transmit task content to the target core separately, thus reducing the task distribution burden on the main control core and inter-core communication overhead. Simultaneously, by adding the tasks to be migrated to the target core's task queue after extraction, the business tasks migrated across cores can be integrated into the target core's original task scheduling process, improving the efficiency of the connection between task migration and the target core's local execution process.

[0091] Optionally, the above-mentioned collaborative processing method for multi-core asymmetric multiprocessing architecture further includes: Each processor core is used to determine its own operating load according to a preset sampling period, and the correspondence between each operating load and the corresponding sampling time is recorded to obtain the historical load sequence of each processor core. Using a main control core, based on the historical load sequence of each processor core, the predicted operating load of each processor core in subsequent periods is predicted, and the predicted load distribution status is determined based on each predicted operating load. When the predicted load distribution status indicates that there will be an imbalance in the load of each processor core, the business tasks to be migrated, the source core, and the target core are determined based on the predicted load distribution status, and the business tasks to be migrated are scheduled from the source core to the target core in advance.

[0092] In the above process, the main control core is used to perform global business task allocation and cross-core migration decisions based on the operating load of all processor cores; the task executor of each processor core is used to locally schedule the business tasks allocated to its own task queue, including determining the execution order of business tasks, extracting the business processing units to be executed, and calling the corresponding business code. Therefore, the main control core does not need to control the specific execution process of each business processing unit, and each processor core does not need to perform global load judgment separately.

[0093] By adopting the above scheme, task migration can be performed in advance based on historical load changes, reducing processing latency and performance fluctuations caused by load mutations. At the same time, by handling global migration decisions and core local task scheduling in a layered manner, the scheduling burden of the main control core can be reduced, and the scalability of the multi-core processing architecture can be improved.

[0094] Optionally, the above-mentioned collaborative processing method for multi-core asymmetric multiprocessing architecture further includes: The task pool is configured as a distributed task pool accessible by multiple on-chip systems or multiple computing nodes. When the source core and target core of the business task to be migrated are located on different on-chip systems or different computing nodes, the continuation execution information of the business task to be migrated is serialized according to a preset task data structure, and the system identifier and core identifier corresponding to the target core are written into the continuation execution information. The serialized continuation execution information is stored in the distributed task pool accessible by the target core through communication links between on-chip systems or communication networks between computing nodes. Using the target core, the corresponding continuation execution information is retrieved from the distributed task pool based on the system identifier and core identifier. The continuation execution information is deserialized, and the business task to be migrated is executed continuationally based on the task progress information and business status information obtained from the deserialization.

[0095] Specifically, a distributed task pool can include multiple task pool storage areas located on different on-chip systems or different computing nodes. Task data is synchronized between these storage areas via inter-chip communication links or inter-node communication networks. The system identifier indicates the on-chip system or computing node executing the business task, and the core identifier specifies the target core within the corresponding on-chip system or computing node.

[0096] The source core serializes data such as task identifier, task progress information, business status information, system identifier, and core identifier into data that can be transmitted through the communication link, according to a unified preset task data structure. After the remote target core obtains and parses the corresponding data, it uses its own task executor and the already loaded business code to continue executing the business task to be migrated, starting from the business processing unit indicated by the task progress information.

[0097] By adopting the above scheme, task migration between different on-chip systems or different computing nodes can be completed using unified continuation execution information. Without transmitting the execution context of the source core hardware, the scope of collaborative processing can be extended from a single multi-core processor to cross-chip systems or distributed computing systems.

[0098] Optionally, the above-mentioned collaborative processing method for multi-core asymmetric multiprocessing architecture further includes: Establish task records corresponding to each business task in the task pool, and set the lifecycle status of the task record to indicate the current execution stage of the business task; when a business task is created, assigned, executed, migrated, or finishes execution, update the corresponding lifecycle status, wherein the lifecycle status includes at least one of the following: creation status, waiting to be executed status, executing status, migration status, execution completed status, and abnormal status.

[0099] By utilizing each processor core, during the execution of business tasks, the current task progress information and business status information of the business tasks are updated to the task pool according to preset saving conditions, so as to form an execution record that can be used to restore the business tasks.

[0100] Monitor the operating status of each processor core. When a processor core is detected as unable to continue executing its assigned business tasks, update the lifecycle status of the business tasks that have not yet been completed on that processor core to an abnormal state. Based on the task progress information and business status information stored in the task pool, reschedule the business tasks in the abnormal state to the normally operating target core, so that the target core can resume the execution of the corresponding business tasks based on the most recently saved task progress information and business status information.

[0101] By adopting the above scheme, we can uniformly manage all execution stages of business tasks from creation to completion. In the event of a processor core failure, we can use the continuation execution information stored in the task pool to restore unfinished business tasks, thereby reducing task loss or duplicate execution caused by core failures and improving the operational stability and fault tolerance of multi-core processors.

[0102] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0103] Based on the same inventive concept, this application also provides a collaborative processing module. This module is applicable to the collaborative processing method of the above-mentioned multi-core asymmetric multiprocessing architecture. The solution provided by this module is similar to the solution described in the above method. Therefore, the specific limitations of one or more module embodiments provided below can be found in the limitations of the method above, and will not be repeated here.

[0104] Please see Figure 3 In one embodiment, the collaborative processing module is applicable to a multi-core processor, which includes multiple processor cores and a task pool shared by the multiple processor cores; the collaborative processing module includes: an acquisition unit, a determination unit, and a continuation unit.

[0105] The acquisition unit is used to acquire business tasks and assign them to at least one of the multiple processor cores for execution.

[0106] The determination unit is used to determine the operating load of each processor core and determine the load distribution state based on the operating load. If the load distribution state indicates that there is an imbalance in the load, the unit determines the business tasks to be migrated and the source core and target core used for migration out and continued execution of the business tasks to be migrated, respectively.

[0107] The succession unit is used to store the succession execution information of the business tasks to be migrated into the task pool, and schedule the business tasks to be migrated to the target core, so that the target core can obtain the succession execution information from the task pool and continue to execute the business tasks to be migrated according to the succession execution information without migrating the hardware execution context on the source core.

[0108] The aforementioned collaborative processing module determines the operating load of each processor core. When the load is unbalanced, it schedules the business tasks to be migrated from the source core to the target core. It also utilizes the task pool shared by all processor cores to provide continuation execution information to the target core, enabling the target core to continue executing the business tasks to be migrated based on this information. This application can dynamically adjust the distribution of business tasks among processor cores according to the operating load, alleviating the problem of some cores being overloaded while others are idle. Simultaneously, it eliminates the need to migrate the hardware execution context of the source core, reducing the amount of execution state transfer and recovery overhead during cross-core migration, thereby improving the resource utilization and task processing efficiency of multi-core processors.

[0109] Each unit in the aforementioned collaborative processing module can be implemented entirely or partially through software, hardware, or a combination thereof. These units can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device in software form, so that the processor can invoke and execute the corresponding operations of each module.

[0110] In one feasible embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 4As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements the collaborative processing method of the aforementioned multi-core asymmetric multiprocessing architecture. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0111] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0112] In one feasible embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described collaborative processing method of a multi-core asymmetric multiprocessing architecture.

[0113] In one feasible embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the above-described collaborative processing method of a multi-core asymmetric multiprocessing architecture.

[0114] In one feasible embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the above-described collaborative processing method for a multi-core asymmetric multiprocessing architecture.

[0115] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0116] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0117] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A collaborative processing method for a multi-core asymmetric multiprocessing architecture, characterized in that, Applicable to multi-core processors; the multi-core processor includes multiple processor cores and a task pool shared by the multiple processor cores; the method includes: Obtain business tasks and assign the business tasks to at least one of the plurality of processor cores for execution; Determine the operating load of each processor core, and determine the load distribution state based on each operating load; When the load distribution status indicates that there is an unbalanced load, the service tasks to be migrated and the source cores and target cores used for migration and continued execution of the service tasks to be migrated are determined according to the load distribution status. The continuation execution information of the business task to be migrated is stored in the task pool, and the business task to be migrated is scheduled to the target core, so that the target core obtains the continuation execution information from the task pool and continues to execute the business task to be migrated according to the continuation execution information without migrating the hardware execution context on the source core.

2. The method according to claim 1, characterized in that, The plurality of processor cores includes a master core and at least one slave core; The step of determining the operating load of each processor core and determining the load distribution state based on each operating load includes: The main control core and each of the subordinate cores are used to determine their own operating load; Using the main control core, the load distribution state is determined based on its own operating load and the operating load of each of the subordinate cores; The main control core and each of the subordinate cores run operating system instances based on the same operating system image, load the same business code, and execute the assigned business tasks through task executors with the same structure.

3. The method according to claim 2, characterized in that, The process of using the main control core and each of the subordinate cores to determine their own operating load includes: Using the main control core and each of the subordinate cores, the number of business tasks assigned to each core is counted, and the preset task weight of each business task is obtained. Using the main control core and each of the subordinate cores, the sum of the preset task weights of all current business tasks is calculated based on the number of business tasks and the preset task weights, and the sum of the preset task weights is determined as its own operating load.

4. The method according to claim 2, characterized in that, When the load distribution status indicates an unbalanced load, the process of determining the service tasks to be migrated and the source and target cores for migrating out and continuing execution of the service tasks to be migrated, respectively, based on the load distribution status, includes: Using the main control core, the operating loads are compared to determine the maximum and minimum operating loads, and the load difference between the two is calculated. If the load difference exceeds a preset threshold, it is determined that there is a load imbalance. The processor core corresponding to the maximum operating load is determined as the source core, and the processor core corresponding to the minimum operating load is determined as the target core. For each business task currently assigned to the source core, the predicted load difference for migrating each business task to the target core is calculated based on the corresponding preset task weight, and the business task to be migrated is determined based on the predicted load difference.

5. The method according to claim 1, characterized in that, The step of allocating the business task to at least one of the plurality of processor cores for execution includes: The business tasks are organized into task queues consisting of multiple business processing units; Each of the processor cores executes the corresponding business processing unit sequentially according to the task queue, and updates the task progress information used to indicate the execution position of the business task.

6. The method according to claim 5, characterized in that, The continuation execution information includes task progress information and business status information; The step of storing the continuation execution information of the business task to be migrated into the task pool includes: Using the source core, during the execution of the business task to be migrated, business status information is generated and updated; the business status information includes at least one of the task parameters, business data, and resource dependency information required to continue executing the next business processing unit to be executed. When the current business processing unit is completed and the next business processing unit has not yet been executed, the task progress information is updated to indicate the next business processing unit to be executed; According to the preset task data structure, the updated task progress information and the business status information are combined into the follow-up execution information, and the follow-up execution information is written into the task pool.

7. The method according to claim 6, characterized in that, The step of continuing to execute the business task to be migrated according to the continuing execution information includes: Using the target core, the next business processing unit to be executed is determined in the task queue based on the task progress information; Based on the business status information, restore the business data required to execute the next pending business processing unit; The task executor of the target core is used to call the business code loaded in the target core to execute the business task to be migrated starting from the next business processing unit to be executed, and to update the task progress information and the business status information after the business processing unit is completed.

8. The method according to claim 1, characterized in that, The step of scheduling the business tasks to be migrated to the target core includes: Obtain the core identifier of the target core; write the core identifier into the task scheduling attribute corresponding to the business task to be migrated, so as to specify the target core to execute the business task to be migrated; Using the target core, the corresponding continuation execution information is extracted from the task pool according to its own core identifier, and the business task to be migrated is added to the task queue of the target core.

9. The method according to claim 8, characterized in that, The target core obtains the continuation execution information from the task pool, including: The target core's task executor accesses the task pool and matches its own core identifier with the task scheduling attribute. If the match is successful, it obtains the corresponding continuation execution information from the task pool and adds the business task to be migrated to the target core's task queue according to the continuation execution information.

10. A collaborative processing module, characterized in that, Suitable for multi-core processors; The multi-core processor includes multiple processor cores and a task pool that is shared and accessed by the multiple processor cores. The module includes: An acquisition unit is used to acquire business tasks and allocate the business tasks to at least one of the plurality of processor cores for execution. A determining unit is configured to determine the operating load of each processor core and determine the load distribution state based on the operating load; if the load distribution state indicates that there is a load imbalance, the unit determines the service task to be migrated and the source core and target core to be migrated and executed respectively, based on the load distribution state. The succession unit is used to store the succession execution information of the business task to be migrated into the task pool, and schedule the business task to be migrated to the target core, so that the target core obtains the succession execution information from the task pool and continues to execute the business task to be migrated according to the succession execution information without migrating the hardware execution context on the source core.

11. A collaborative processing system, characterized in that, The system includes: A multi-core processor, comprising multiple processor cores and a task pool shared by the multiple processor cores; The collaborative processing module as described in claim 10 is used to determine the business tasks to be migrated based on the operating load of each processor core; to schedule the business tasks to be migrated from the source core to the target core using the task pool; and to enable the target core to continue executing the business tasks to be migrated based on the succession execution information stored in the task pool.

12. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1-9.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-9.

Images