Task processing method, processor, computer equipment and computer-readable storage medium

Abstract

This application discloses a task processing method, a processor, a computer device, and a computer-readable storage medium. The method includes: grouping service subsystem instances corresponding to a target service type in at least one core to obtain at least one subsystem group corresponding to the target service type; determining a target scheduling processor corresponding to the subsystem group in a scheduling processor in at least one core; and processing task queues of the target service type using the service subsystem instances in the subsystem group and the corresponding target scheduling processor.

Description

Technical Field

[0001] This application relates to, but is not limited to, the field of computer technology, and particularly to a task processing method, a processor, a computer device, and a computer-readable storage medium. Prior Technology

[0002] With the continuous development of computer technology, multi-core processors have become the mainstream architecture of today's computer systems. A multi-core processor contains multiple cores, each capable of executing tasks independently, enabling the processor to process multiple tasks in parallel. However, how to effectively allocate and process tasks within a multi-core processor has become a crucial issue. Summary of the Invention

[0003] In view of this, embodiments of this application provide at least one task processing method, processor, computer device, and computer-readable storage medium.

[0004] The technical solution of this application embodiment is implemented as follows: On one hand, this application embodiment provides a task processing method applied to a processor including multiple cores, wherein the cores include a scheduling processor and a service subsystem instance; the method includes: grouping the service subsystem instances corresponding to a target service type in at least one of the cores to obtain at least one subsystem group corresponding to the target service type; determining the target scheduling processor corresponding to the subsystem group in the scheduling processors of at least one of the cores; and processing the task queue of the target service type using the service subsystem instances in the subsystem group and the corresponding target scheduling processor.

[0005] In some embodiments, grouping at least one instance of a business subsystem corresponding to a target business type in at least one core to obtain at least one subsystem group corresponding to the target business type includes: obtaining a grouping requirement corresponding to the target business type; and grouping at least one instance of a business subsystem corresponding to a target business type in at least one core based on the grouping requirement corresponding to the target business type to obtain at least one subsystem group corresponding to the target business type.

[0006] In some embodiments, the grouping requirement includes at least one of the following: a group quantity requirement and a requirement for the number of business subsystem instances within a subsystem group; wherein, in a virtualization scenario, the group quantity requirement is the number of users in the virtualization scenario, and the quantity requirement is determined based on the performance requirements of the users; in a multi-application scenario, the group quantity requirement is the number of applications in the multi-application scenario, and the quantity requirement is determined based on the performance requirements of the applications.

[0007] In some embodiments, determining the target scheduling processor corresponding to the subsystem group in at least one scheduling processor in the core includes: determining each scheduling processor corresponding to each service subsystem instance of the subsystem group in the at least one scheduling processor in the core; and determining the target scheduling processor corresponding to the subsystem group in each scheduling processor.

[0008] In some embodiments, determining the target scheduler corresponding to the subsystem group in each scheduler includes: obtaining load information of each scheduler; the load information is used to characterize the scheduling status of the scheduler for service subsystem instances of non-target service types; and determining the target scheduler in each scheduler based on the load information.

[0009] In some embodiments, processing the task queue of the target service type using the business subsystem instance in the subsystem group and the corresponding target scheduler includes: in response to a task issuance event of the target service type, obtaining at least one task in the task queue through the target scheduler, and distributing the at least one task to at least one business subsystem instance in the subsystem group; and processing the distributed task through the at least one business subsystem instance in the subsystem group.

[0010] In some embodiments, processing a task of the target service type using a business subsystem instance in the subsystem group and a corresponding target scheduler includes: in response to a task issuance event of the target service type, obtaining task information of the task through the target scheduler and sending the task information of the task to a business subsystem instance in the subsystem group; determining subtask information corresponding to the business subsystem instance based on the task information of the task through the business subsystem instance in the subsystem group; and obtaining and processing the distributed subtask based on the corresponding subtask information through the business subsystem instance in the subsystem group.

[0011] In some embodiments, the method further includes: responding to a system event generated by a business subsystem instance in the subsystem group, reporting the system event to a target scheduler corresponding to the subsystem group through the business subsystem instance; wherein the system event includes at least one of the following: a task completion event, a task-to-scheduler interaction event, a multi-core task synchronization event, and a subsystem exception event.

[0012] In some embodiments, the processor further includes a host processor; the step of reporting the system event to the target scheduling processor corresponding to the subsystem group through the service subsystem instance in response to a system event generated by a service subsystem instance in the subsystem group includes: reporting the first task completion event to the target scheduling processor corresponding to the subsystem group through the service subsystem instance in response to a first task completion event generated by a service subsystem instance in the subsystem group; the first task completion event is generated when the service subsystem instance finishes processing the distributed subtask; the method further includes: reporting a second task completion event to the host processor in the processor through the target scheduling processor in response to the target scheduling processor corresponding to the subsystem group receiving the first task completion event reported by the service subsystem instance in the subsystem group; the second task completion event is used to indicate that the task of the target service type has been completed.

[0013] In some embodiments, the processor further includes a common subsystem for providing common resources to the business subsystem instance; the method further includes: responding to a common event corresponding to the common subsystem, the processor further including a host processor; sending the common event to a common event processing unit through the common subsystem, and processing the common event through the common event processing unit.

[0014] In some embodiments, sending the public event to the public event processing unit through the public subsystem and processing the public event through the public event processing unit includes at least one of the following: when the public event processing unit is a target scheduling processor, reporting the public event to all target scheduling processors of the processor through the public subsystem; when a target scheduling processor determines that the public event is related to itself, processing the public event through the target scheduling processor; or, when the public event processing unit is a target scheduling processor, reporting the public event to the main scheduling processor through the public subsystem; the main scheduling processor is the scheduling processor of the main core among the plurality of cores; through the main scheduling processor, determining the scheduling processor to be sent corresponding to the public event among the target scheduling processors corresponding to each subsystem group; sending the public event to the scheduling processor to be sent through the main scheduling processor, and processing the public event through the scheduling processor to be sent; or, when the public event processing unit is a host processor, reporting the public event to the host processor through the public subsystem; and processing the public event through the host processor.

[0015] In some embodiments, the service subsystem instance is configured with an information register; the method further includes: in response to determining the target scheduler corresponding to the subsystem group, storing group information of the subsystem group corresponding to the service subsystem instance through the information register; the group information is used to determine the core corresponding to each service subsystem instance within the subsystem group and the core corresponding to the target scheduler of the subsystem group.

[0016] In some embodiments, the information register includes a mask register; storing group information of the subsystem group corresponding to the service subsystem instance through the information register includes: storing a core mask corresponding to the subsystem group through the mask register; wherein, the core mask includes a sub-mask corresponding to each core in the processor, and when the service subsystem instance corresponding to the core belongs to the subsystem group, the sub-mask corresponding to the core is set to a first value; when the service subsystem instance corresponding to the core does not belong to the subsystem group, the sub-mask corresponding to the core is set to a second value; the core masks stored in the mask registers of service subsystem instances within the same subsystem group are the same, and the core masks stored in the mask registers of service subsystem instances within different subsystem groups are mutually exclusive.

[0017] In some embodiments, the information register includes a number register; storing the grouping information of the subsystem group corresponding to the service subsystem instance through the information register includes: storing the identifier of the core corresponding to the target scheduler of the subsystem group through the number register.

[0018] On the other hand, embodiments of this application provide a processor, the processor including multiple cores, each core including a host processor, service subsystem instances, and a scheduling processor, wherein: the host processor is configured to group service subsystem instances corresponding to a target service type in at least one of the cores to obtain at least one subsystem group corresponding to the target service type; in the scheduling processors in at least one of the cores, a target scheduling processor corresponding to the subsystem group is determined; the service subsystem instances in the subsystem group and the target scheduling processor corresponding to the subsystem group are configured to process task queues of the target service type.

[0019] In another aspect, embodiments of this application provide a computer device, including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-described method.

[0020] In another aspect, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements some or all of the steps in the above-described method.

[0021] In another aspect, embodiments of this application provide a computer program product, including a computer program or instructions, which, when executed by a processor, implement some or all of the steps in the above-described method.

[0022] In this embodiment, within a processor comprising multiple cores, for business subsystem instances of a target business type, this application groups the business subsystem instances corresponding to the target business type within the processor from the perspective of business subsystem instances. Simultaneously, a corresponding target scheduling processor is assigned to each subsystem group. This avoids performance bottlenecks caused by the scheduling processor compared to the traditional approach of using a single scheduling processor to handle task scheduling for all business subsystem instances. Furthermore, by grouping the business subsystem instances corresponding to the target business type within the processor from the perspective of business subsystem instances, compared to the traditional approach of grouping at the core level, the subsystem groups can be flexibly adjusted according to different task characteristics and system load conditions, thus adapting to various application scenarios and requirements.

[0023] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this application. Simple Explanation of the Diagram

[0024] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present invention and, together with the specification, serve to explain the technical solutions of the embodiments of the present invention. Figure 1 is a schematic diagram illustrating the implementation flow of a task processing method provided in an embodiment of this application; Figure 2 is a schematic diagram illustrating the implementation flow of a task processing method according to another embodiment of this application; Figure 3 is a schematic diagram illustrating the implementation flow of a task processing method according to another embodiment of this application; Figure 4 is a schematic diagram illustrating the implementation flow of a task processing method according to another embodiment of this application; Figure 5 is a schematic diagram illustrating the implementation flow of a task processing method according to another embodiment of this application; Figure 6A is a schematic diagram illustrating the implementation flow of a task processing method according to another embodiment of this application; Figure 6B is a schematic diagram of a task completion event processing flow provided in another embodiment of this application; Figure 7 is a schematic diagram illustrating the implementation flow of a task processing method according to another embodiment of this application; Figure 8 is a schematic diagram of a public event processing flow provided in an embodiment of this application; Figure 9 is a schematic diagram of a public event processing flow provided in another embodiment of this application; Figure 10 is a schematic diagram illustrating the implementation flow of a task processing method according to another embodiment of this application; Figure 11 is a schematic diagram of the composition structure of a processor provided in an embodiment of this application; Figure 12 is a schematic diagram showing the correspondence between a business subsystem instance and a scheduling processor provided in an embodiment of this application; Figure 13 is a schematic diagram showing the correspondence between a business subsystem instance and a scheduling processor according to another embodiment of this application; Figure 14 is a schematic diagram showing the correspondence between a business subsystem instance and a scheduling processor according to another embodiment of this application; Figure 15 is a schematic diagram of the hardware of a computer device provided in an embodiment of this application. Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] In the following description, references to "some embodiments" refer to a subset of all possible embodiments. It is understood that "some embodiments" may be the same or different subsets of all possible embodiments and may be combined with each other without conflict. The terms "first / second / third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permissible, so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein.

[0027] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this application.

[0028] This application provides a task processing method that can be executed by a processor of a computer device. The computer device refers to a device with data processing capabilities, such as a server, laptop, tablet, desktop computer, smart TV, set-top box, or mobile device (e.g., mobile phone, portable video player, personal digital assistant, dedicated messaging device, portable gaming device). In this application embodiment, the task processing method is applied to a processor with multiple cores, including a scheduling processor and a business subsystem instance.

[0029] Figure 1 is a schematic diagram of the implementation flow of a task processing method provided in an embodiment of this application. As shown in Figure 1, the method includes the following steps S101 to S103: Step S101: Group at least one instance of a business subsystem corresponding to a target business type in the core to obtain at least one subsystem group corresponding to the target business type.

[0030] In this embodiment, the processor includes multiple cores, each core containing instances of the same type of business subsystem. Considering that each instance of a business subsystem may exist in every core or only in one core, the process of grouping instances of that type involves identifying at least one core (containing instances of that type of business subsystem). Accordingly, step S101 involves grouping instances of the same type of business subsystem within at least one core to obtain at least one subsystem group corresponding to that type. Each subsystem group includes at least one instance of a business subsystem. It is understood that this embodiment groups instances of the same type of business subsystem within the processor based on their type, obtaining at least one subsystem group corresponding to that type. For ease of explanation, the following description uses a target business type as an example and is not intended to limit the scope of this embodiment.

[0031] In some embodiments, each of the processor's multiple cores includes one instance of a service subsystem of the target service type; in other embodiments, each of the processor's multiple cores includes at least one instance of a service subsystem of the target service type; in still other embodiments, some cores of the processor may not include an instance of a service subsystem of the target service type. That is, the service subsystem instance of the target service type in the processor can be distributed across all cores or across some cores; furthermore, a single instance of a service subsystem of the target service type may exist in a core, or multiple instances may exist therein, and this application does not impose any limitations on this.

[0032] In some embodiments, during the grouping process, all service subsystem instances of the target service type in the processor can be grouped to obtain at least one subsystem group corresponding to the target service type; alternatively, some service subsystem instances of the target service type in the processor can be grouped to obtain at least one subsystem group corresponding to the target service type. For example, if the processor includes 8 service subsystem instances for the target service type, all 8 service subsystem instances can be grouped, or some (e.g., 5) service subsystem instances can be grouped.

[0033] Step S102: In at least one of the scheduling processors in the core, determine the target scheduling processor corresponding to the subsystem group.

[0034] Each core includes a scheduling processor. After grouping to obtain at least one subsystem group, a target scheduling processor needs to be determined for each subsystem group. The target scheduling processor is used to process the target business type tasks with the business subsystem instances within the subsystem group.

[0035] In some embodiments, for a subsystem group, the target scheduler corresponding to the subsystem group is the scheduler of any one of the cores in the processor. For example, taking a current processor comprising 8 cores, each core including a scheduler and a service subsystem instance of a target service type, if the service subsystem instances of the 1st to 3rd cores are considered as the first subsystem group, and the service subsystem instances of the 4th to 8th cores are considered as the second subsystem group, then the target scheduler for both the first and second subsystem groups can be the scheduler of any one of the 8 cores.

[0036] In other embodiments, the target scheduler corresponding to the subsystem group is the scheduler of the core to which each service subsystem instance belongs within the subsystem group. Based on the above example, if the service subsystem instances of the 1st to 3rd cores are taken as the first subsystem group, and the service subsystem instances of the 4th to 8th cores are taken as the second subsystem group, then the target scheduler of the first subsystem group is the scheduler of any one of the 1st to 3rd cores; the target scheduler of the second subsystem group is the scheduler of any one of the 4th to 8th cores.

[0037] Step S103: Using the business subsystem instances and corresponding target schedulers in the subsystem group, process the task queues of the target business type.

[0038] In some embodiments, during the process of processing a task queue of a target business type through subsystem grouping, the target scheduler can be used to distribute the task queue of the target business type to each business subsystem instance within the subsystem group, and then process the distributed task queue through each business subsystem instance within the subsystem group to complete the task queue of the target business type.

[0039] In this embodiment, within a processor comprising multiple cores, for business subsystem instances of a target business type, this application groups the business subsystem instances corresponding to the target business type within the processor from the perspective of business subsystem instances. Simultaneously, a corresponding target scheduling processor is assigned to each subsystem group. This avoids performance bottlenecks caused by the scheduling processor compared to the traditional approach of using a single scheduling processor to handle task scheduling for all business subsystem instances. Furthermore, by grouping the business subsystem instances corresponding to the target business type within the processor from the perspective of business subsystem instances, compared to the traditional approach of grouping at the core level, the subsystem groups can be flexibly adjusted according to different task characteristics and system load conditions, thus adapting to various application scenarios and requirements.

[0040] Figure 2 is a schematic flowchart of a task processing method according to another embodiment of this application, which can be executed by the processor of a computer device. Based on Figure 1, S101 in Figure 1 can be updated to S201 to S202, and will be described in conjunction with the steps shown in Figure 2.

[0041] Step S201: Obtain the grouping requirements corresponding to the target business type.

[0042] In this embodiment, different grouping requirements are preset for different types of business subsystem instances within the core. For example, if the core includes business subsystem instances of type 1 and type 2, a first grouping requirement can be set for type 1 and a second grouping requirement can be set for type 2. In this way, different grouping principles can be adopted for different types of business subsystem instances.

[0043] In some embodiments, the grouping requirement includes at least one of the following: a group quantity requirement, and a requirement for the number of business subsystem instances within a subsystem group. The group quantity requirement includes a maximum subsystem group quantity and a minimum subsystem group quantity; the requirement for the number of business subsystem instances within a subsystem group includes a maximum subsystem instance quantity corresponding to the subsystem group and a minimum subsystem instance quantity corresponding to the subsystem group.

[0044] In the virtualization scenario, the required number of groups is the number of users in the virtualization scenario, and the required number is determined based on the performance requirements of the users; in the multi-application scenario, the required number of groups is the number of applications in the multi-application scenario, and the required number is determined based on the performance requirements of the applications.

[0045] In some implementation scenarios, the processor can be deployed in a virtualized environment, where different subsystem groups are virtualized into independent processing systems and assigned to different users. In this scenario, the number of subsystem groups corresponds to the number of users in the virtualized environment; the number of business subsystem instances corresponding to each subsystem group can be determined based on the performance requirements of the respective users. In other implementation scenarios, the processor can be used to execute multiple applications. In this scenario, the number of subsystem groups corresponds to the number of applications; the number of business subsystem instances corresponding to each subsystem group can be determined based on the performance requirements of the corresponding applications.

[0046] Step S202: Based on the grouping requirements corresponding to the target business type, group at least one instance of the business subsystem corresponding to the target business type in the core to obtain at least one subsystem group corresponding to the target business type.

[0047] Here, at least one subsystem group is obtained, each used to handle tasks corresponding to the target business type. It is understood that the tasks handled by different business subsystem instances do not overlap.

[0048] In this embodiment, by obtaining the grouping requirements corresponding to the target business type, different grouping principles can be adopted for different types of business subsystem instances, improving the flexibility and adaptability of the subsystem grouping principles. In virtualization scenarios and scenarios where multiple applications are executed, the number of subsystem groups and the number of business subsystem instances corresponding to the subsystem groups are determined according to the number of users and the performance requirements of the applications, which can better meet the performance requirements in different scenarios. At the same time, virtualizing different subsystem groups into an independent processing system and assigning them to different users or executing different applications improves the utilization of processor resources, ensures the independence of data between different users / applications, and enhances data security.

[0049] Figure 3 is a schematic flowchart of a task processing method according to another embodiment of this application, which can be executed by the processor of a computer device. Based on Figure 1, S102 in Figure 1 can be updated to S301 and S302, which will be described in conjunction with the steps shown in Figure 3.

[0050] Step S301: In at least one scheduling processor in the core, determine each scheduling processor corresponding to each instance of the service subsystem in the subsystem group.

[0051] In this embodiment of the application, in order to improve the scheduling effect of the scheduling processor on each service subsystem instance within the subsystem group and shorten the information transmission path, the selection range can be narrowed from all scheduling processors within the processor to the scheduling processor corresponding to each service subsystem instance in the subsystem group during the process of selecting the target scheduling processor corresponding to the subsystem group.

[0052] Step S302: In each scheduling processor, determine the target scheduling processor corresponding to the subsystem group.

[0053] In some embodiments, a random algorithm may be used to randomly select a scheduling processor from the scheduling processors corresponding to each business subsystem instance in the subsystem group as the target scheduling processor for that subsystem group.

[0054] In this embodiment, compared to selecting other core scheduling processors as the target scheduling processor, the above scheme can at least save the impact of information transmission between a service subsystem instance and the target scheduling processor on the bus bandwidth. Simultaneously, by determining the target scheduling processor from the scheduling processors corresponding to each service subsystem instance in the subsystem group, the load imbalance and performance degradation caused by fixed selection of a particular scheduling processor are avoided, thus improving the fairness and efficiency of scheduling.

[0055] In some embodiments, the above-mentioned determination of the target scheduling processor corresponding to the subsystem group in each scheduling processor can be achieved through steps S3021 and S3022.

[0056] Step S3021: Obtain the load information of each scheduling processor.

[0057] The load information is used at least to characterize the scheduling status of the scheduling processor for service subsystem instances that are not target service types.

[0058] In this embodiment, the processor may include multiple types of business subsystem instances. That is, in addition to the business subsystem instance of the target business type, it may also include at least one business subsystem instance of a non-target business type. Therefore, like the business subsystem instances of the target business type, non-target business type business subsystem instances will also be divided into at least one subsystem group, and a target scheduling processor will be determined for each non-target business type subsystem instance. It is understood that a scheduling processor within a core can simultaneously handle the scheduling tasks of different types of subsystem groups (business subsystem instances).

[0059] In some embodiments, the load information may include the number of scheduled tasks for subsystem groups under the responsibility of the scheduler.

[0060] Step S3022: Based on the load information, determine the target scheduling processor in each scheduling processor.

[0061] In some embodiments, the load information of the scheduling processor corresponding to each of the service subsystem instances can be compared, and the scheduling processor with the lowest load in each of the service subsystem instances of the subsystem group can be determined as the target scheduling processor corresponding to the subsystem group.

[0062] For example, when a subsystem group includes a first service subsystem instance, a second service subsystem instance, and a third service subsystem instance, if the scheduling processor corresponding to the first service subsystem instance is responsible for scheduling tasks of three non-target service type subsystem groups, the scheduling processor corresponding to the second service subsystem instance is responsible for scheduling tasks of one non-target service type subsystem group, and the scheduling processor corresponding to the third service subsystem instance is responsible for scheduling tasks of two non-target service type subsystem groups, then the scheduling processor corresponding to the second service subsystem instance is determined as the target scheduling processor corresponding to the subsystem group.

[0063] In this embodiment, by obtaining the load information of the scheduling processor corresponding to each business subsystem instance, the workload of each scheduling processor can be understood, thereby providing a basis for subsequently determining the target scheduling processor and improving the accuracy and efficiency of scheduling. At the same time, by comparing the load information of the scheduling processor corresponding to each business subsystem instance, the scheduling processor with the lowest load among the scheduling processors corresponding to each business subsystem instance in the subsystem group is determined as the target scheduling processor corresponding to the subsystem group, which can make the target scheduling processor have a lower load, thereby better meeting the scheduling needs of the subsystem group.

[0064] Figure 4 is a schematic flowchart of a task processing method according to another embodiment of this application, which can be executed by the processor of a computer device. Based on Figure 1, S103 in Figure 1 can be updated to S401 to S402, which will be described in conjunction with the steps shown in Figure 4.

[0065] Step S401: In response to the task distribution event of the target service type, at least one task in the task queue is obtained through the target scheduling processor, and the at least one task is distributed to at least one service subsystem instance in the subsystem group.

[0066] Here, the task dispatch event indicates that the target scheduler needs to dispatch the corresponding task queue to the business subsystem instance within the subsystem group.

[0067] In this embodiment of the application, the target scheduling processor obtains at least one task corresponding to the task queue, and determines the mapping relationship between the at least one task and at least one business subsystem instance within the subsystem group, and then sends the task corresponding to each business subsystem instance to each business subsystem instance respectively.

[0068] It should be noted that the tasks assigned to different business subsystem instances do not overlap.

[0069] In some embodiments, at least one task can be stored in system memory. The target scheduler can obtain the address information corresponding to each task. After determining the mapping relationship between at least one task and the business subsystem instance within the subsystem group, the task address corresponding to the business subsystem instance can be sent to the business subsystem instance.

[0070] Step S402: Process the distributed tasks through at least one business subsystem instance in the subsystem group.

[0071] In some embodiments, at least one business subsystem instance receives the task addresses of each task sent by the target scheduler corresponding to the subsystem group, and retrieves the corresponding task from the system memory based on the task address of each task, and then processes it.

[0072] In this embodiment, the task distribution of each business subsystem instance is completed by the target scheduling processor corresponding to the subsystem group. Since the task distribution is processed by a target scheduling processor, the same task can be avoided to a certain extent from being distributed to different business subsystem instances, thereby improving the overall collaboration capability between the various business subsystem instances and thus improving task processing efficiency.

[0073] Figure 5 is a schematic flowchart of a task processing method according to another embodiment of this application, which can be executed by the processor of a computer device. Based on Figure 1, S103 in Figure 1 can be updated to S501 to S503, and will be described in conjunction with the steps shown in Figure 5.

[0074] Step S501: In response to the task issuance event of the target service type, obtain the task information of the task through the target scheduling processor, and send the task information of the task to the service subsystem instance in the subsystem group.

[0075] Here, the task dispatch event indicates that the target scheduler needs to dispatch the corresponding task to the business subsystem instance within the subsystem group.

[0076] In this embodiment, the target scheduler obtains the task information corresponding to the task. This task information may include at least one of the following: the queue address of the task queue corresponding to the task, the task addresses of each subtask in the task, and the number of subtasks in the task. This task information is used to instruct each business subsystem instance within the subsystem group to determine the subtasks it needs to process based on this task information; that is, the task information is used by each business subsystem instance to complete the negotiation process for subtask distribution.

[0077] Step S502: Determine the subtask information corresponding to the business subsystem instance based on the task information of the task through the business subsystem instance in the subsystem group.

[0078] In this embodiment, after the subsystem group is generated, each business subsystem instance in the subsystem group is configured with grouping information for that subsystem group. This grouping information includes the number of business subsystem instances in the subsystem group and the order of the business subsystem instances within the current subsystem group. For example, if the graphics subsystem instances in cores 1 to 4 are divided into a subsystem group, then the graphics subsystem instances in core 1 can store "the subsystem group includes four core graphics subsystem instances, and it is the first of these four core graphics subsystem instances"; the graphics subsystem instances in core 2 can store "the subsystem group includes four core graphics subsystem instances, and it is the second of these four core graphics subsystem instances"; and so on. In this way, the business subsystem instance can determine the subtask information corresponding to the business subsystem instance based on the stored subsystem grouping information and the task information of the task.

[0079] In some embodiments, the task information may include the column address of a task column, wherein the task column includes at least one subtask; correspondingly, the subtask information may be the position of the subtask corresponding to the business subsystem instance in the task column. Thus, the business subsystem instance can determine the position of the subtask corresponding to the business subsystem instance in the task column based on the position of each subtask in the task column and the order of the business subsystem instance within the current subsystem group.

[0080] For example, taking a subsystem group containing 3 business subsystem instances as an example, assuming there are 10 subtasks in the task queue, the first business subsystem instance can obtain the subtasks sorted into 3n+1 (the 1st, 4th, 7th, and 10th) from the task queue, the second business subsystem instance can obtain the subtasks sorted into 3n+2 (the 2nd, 5th, and 8th) from the task queue, and the third business subsystem instance can obtain the subtasks sorted into 3n+3 (the 3rd, 6th, and 9th) from the task queue, where n is an integer greater than or equal to 0.

[0081] Step S503: Based on the corresponding subtask information, obtain and process the distributed subtasks through the business subsystem instances in the subsystem group.

[0082] In this embodiment, a business subsystem instance can obtain the corresponding subtask from the task queue stored in the system memory based on the position of the corresponding subtask in the task queue, and then achieve task distribution of at least one subtask to the business subsystem instance within the subsystem group through negotiation between business subsystem instances.

[0083] In this embodiment, task information is transmitted to each business subsystem instance within the subsystem group through the target scheduling processor corresponding to the subsystem group. The distribution of subtasks is realized through the negotiation mechanism between the business subsystem instances. Since the distribution of subtasks does not need to be processed by the scheduling processor, the computing resources of the scheduling processor can be saved to a certain extent, thereby improving the overall task scheduling efficiency and task processing efficiency.

[0084] Figure 6A is a schematic flowchart illustrating the implementation of a task processing method according to another embodiment of this application. This method can be executed by the processor of a computer device. Based on Figure 1, the method further includes S601, which will be described in conjunction with the steps shown in Figure 6A.

[0085] Step S601: In response to a system event generated by a service subsystem instance in the subsystem group, report the system event to the target scheduling processor corresponding to the subsystem group through the service subsystem instance.

[0086] The system events include at least one of the following: task completion event, task-scheduler interaction event, multi-core task synchronization event, and subsystem exception event.

[0087] In this embodiment of the application, for any business subsystem instance within a subsystem group, system events generated by that business subsystem instance can be reported through the target scheduling processor corresponding to that subsystem group.

[0088] In some embodiments, when the service subsystem instance and the target scheduler are on the same core, system events generated by the service subsystem instance can be directly reported to the target scheduler; when the service subsystem instance and the target scheduler are on different cores, system events generated by the service subsystem instance can be transmitted to the target scheduler through a configured bus.

[0089] In some embodiments, the processor further includes a host processor; the system event generated by the service subsystem instance in the subsystem group can be responded to in step S6011, and the system event is reported to the target scheduling processor corresponding to the subsystem group through the service subsystem instance.

[0090] Step S6011: In response to the first task completion event generated by the business subsystem instance in the subsystem group, the business subsystem instance reports the first task completion event to the target scheduler corresponding to the subsystem group; the first task completion event is generated when the business subsystem instance finishes processing the distributed subtask.

[0091] In some embodiments, when a subsystem group of the target business type obtains a task of the target business type that needs to be processed, it will divide at least one subtask of the task of the target business type and distribute it to the business subsystem instance. When the business subsystem instance finishes processing the distributed subtask, it generates a first task completion event and reports the first task completion event to the corresponding target scheduler.

[0092] Accordingly, the target scheduling processor within the subsystem group is used to monitor and accept the first task completion event reported by each business subsystem instance in order to determine whether at least one subtask of this division and distribution has been completed.

[0093] In some embodiments, the method may further include: in response to a target scheduling processor corresponding to the subsystem group receiving a first task completion event reported by a service subsystem instance distributed within the subsystem group, reporting a second task completion event to a host processor in the processor through the target scheduling processor; the second task completion event is used to characterize that the task of the target service type has been completed.

[0094] For example, please refer to Figure 6B, which illustrates a schematic diagram of a task completion event processing flow. The processor includes cores 1 to 4. Each core in the processor includes a graphics subsystem instance, a computing subsystem instance, and a video subsystem instance. For the four graphics subsystem instances in the processor, the graphics subsystem instances of cores 1 and 2 can be divided into a first graphics subsystem instance group, with the target scheduling processor being the scheduling processor of core 1; the graphics subsystem instances of cores 3 and 4 can be divided into a second graphics subsystem instance group, with the target scheduling processor being the scheduling processor of core 3. For the first graphics subsystem instance group, the implementation process of the above scheme includes: the graphics subsystem instance of core 1 receives and processes the subtasks in the task, and generates a first task completion event after completing the processing, as shown in data flow 61 in Figure 6B; the graphics subsystem instance of core 1 reports the first task completion event to the scheduling processor of core 1. After receiving the first task completion event reported by the graphics subsystem instance of core 1, the scheduling processor of core 1 can determine that the graphics subsystem instance of core 1 has completed the distributed subtask. Similarly, the graphics subsystem instance of Core 2 can also receive and process subtasks within a task. After processing, it generates a first task completion event, as shown in data flow 62 in Figure 6B. The graphics subsystem instance of Core 2 reports this first task completion event to the scheduling processor of Core 1 through the configured busbar. The scheduling processor of Core 1 determines whether all subtasks have been completed based on all received first task completion events. If all subtasks have been completed (i.e., the first task completion events reported by the graphics subsystem instances of Core 1 and Core 2 have been received), as shown in data flow 63 in Figure 6B, the scheduling processor of Core 1 will report a second task completion event to the host processor in the processor, indicating that the task of the target business type has been completed.

[0095] In this embodiment, by reporting the second task completion event to the host processor through the target scheduling processor, parallel processing of target business type tasks can be achieved, improving task completion efficiency and system throughput. Simultaneously, the host processor can obtain the completion status of the target business type tasks in a timely manner, facilitating subsequent processing and decision-making.

[0096] Figure 7 is a schematic flowchart illustrating the implementation of a task processing method according to another embodiment of this application. This method can be executed by the processor of a computer device. Based on Figure 1, the processor further includes a common subsystem that provides common resources for the business subsystem instance; the method may also include S701, which will be described in conjunction with the steps shown in Figure 7.

[0097] Step S701: In response to a public event corresponding to the public subsystem, the processor further includes a host processor; the public event is sent to the public event processing unit through the public subsystem, and the public event processing unit determines to process the public event.

[0098] It is understood that this common subsystem provides common resources for all business subsystem instances in the processor. In some embodiments, this common resource can be at least one of the following resources: storage resources (e.g., memory, disk, database), network resources (e.g., network interface, router, etc.). Accordingly, the common subsystem can be a storage subsystem, a network subsystem, etc.; the common event is an event generated by the processor during the use of the aforementioned common resources, wherein the common event corresponding to the common subsystem can be at least one of the following: memory access event, disk read / write event, network connection event, network data transmission event, etc.

[0099] Since the common subsystem provides common resources for all business subsystem instances in the processor, when the common subsystem generates the aforementioned common event, the common subsystem cannot determine which business subsystem instance the common event is related to. Therefore, it needs to report the common event to the common event processing unit for processing.

[0100] In some embodiments, the aforementioned public event processing unit can be a target scheduling processor. Accordingly, step S7011 can be used to send the public event to the public event processing unit through the public subsystem and process the public event through the public event processing unit.

[0101] Step S7011: When the common event processing unit is a target scheduling processor, the common event is reported to all target scheduling processors of the processor through the common subsystem; when the target scheduling processor determines that the common event is related to itself, the common event is processed by the target scheduling processor.

[0102] The common subsystem is located in the processor. Considering that the processor includes business subsystem instances of different types, and that different types of business subsystem instances are also divided into at least one set of subsystems of the corresponding type, all target schedulers in the processor include not only the target schedulers of all subsystem sets corresponding to the target business type, but also the target schedulers of all subsystem sets corresponding to non-target business types.

[0103] Since this common subsystem provides common resources for all business subsystem instances in the processor, when the common subsystem generates the aforementioned common event, the common subsystem cannot determine which business subsystem instance the common event is related to. Therefore, it needs to report the common event to all target scheduling processors within the processor.

[0104] In some embodiments, the target scheduler can obtain the event attributes of the common event and determine whether the common event is related to itself based on the event attributes. The event attributes may include at least one of the following: event type, resource information corresponding to the event, and process identifier corresponding to the event.

[0105] In some embodiments, for any subsystem group, the target scheduler corresponding to that subsystem group stores system information corresponding to all service subsystem instances within that subsystem group. Therefore, after receiving a common event reported by a common subsystem, it can be determined whether the common event is related to any service subsystem instance within that subsystem group based on the stored system information corresponding to all service subsystem instances within that subsystem group.

[0106] In the above embodiments, if the target scheduler determines that the common event is related to any one of the service subsystem instances within the subsystem group, the target scheduler processes the common event. For example, if the common event only needs to be reported upstream, the target scheduler can directly report the common event to the host processor; if the common event requires processing by a corresponding service subsystem instance, the target scheduler can forward the common event to the corresponding service subsystem instance. Of course, if the target scheduler determines that the common event is unrelated to all service subsystem instances within the subsystem group, the common event is discarded.

[0107] For example, please refer to Figure 8, which illustrates a schematic diagram of a common event processing flow. The processor includes cores 1 to 4. Each core in the processor includes a graphics subsystem instance, a computing subsystem instance, and a video subsystem instance. For the four graphics subsystem instances in the processor, the graphics subsystem instances of cores 1 and 2 can be divided into a first graphics subsystem instance group, with the target scheduling processor being the scheduling processor of core 1; the graphics subsystem instances of cores 3 and 4 can be divided into a second graphics subsystem instance group, with the target scheduling processor being the scheduling processor of core 3. Based on the above subsystem grouping method, the computing subsystem instances and video subsystem instances can also be grouped to determine the target scheduling processors corresponding to the computing subsystem instances (the scheduling processors of core 2 and core 4) and the target scheduling processors corresponding to the video subsystem instances (the scheduling processor of core 3). Therefore, each core in the processor has a target scheduling processor. In response to a common event corresponding to the common subsystem, the common subsystem reports the common event to all target scheduling processors of the processor. That is, as shown in data flow 81 in Figure 8, the common subsystem needs to report the common event to the scheduling processor corresponding to each core. When the scheduling processor of core 1 determines that the common event is related to itself, it processes the common event. For example, if the common event requires processing by the corresponding business subsystem instance (the graphics subsystem instance of core 2), as shown in data flow 82, the scheduling processor of core 1 forwards the common event to the graphics subsystem instance of core 2; if the common event only needs to be reported upstream, as shown in data flow 83, the scheduling processor of core 1 can directly report the common event to the host processor.

[0108] In this embodiment, by sending public event notifications to all target scheduling processors of the processor, it can be ensured that the public event can be reported to the corresponding target scheduling processor for processing. The target scheduling processor determines whether the public event is related to itself and processes the public event. In this way, each business subsystem instance can process public events related to itself, thereby improving the efficiency and reliability of the processor.

[0109] In some embodiments, the aforementioned public event processing unit can be a target scheduling processor. Accordingly, step S7012 can be used to send the public event to the public event processing unit through the public subsystem and process the public event through the public event processing unit.

[0110] Step S7012: When the common event processing unit is the target scheduling processor, the common event is reported to the main scheduling processor through the common subsystem; the main scheduling processor is the scheduling processor of the main core among the multiple cores; through the main scheduling processor, the scheduling processor to be sent corresponding to the common event is determined among the target scheduling processors corresponding to each subsystem group; the common event is sent to the scheduling processor to be sent through the main scheduling processor, and the common event is processed by the scheduling processor to be sent.

[0111] In some embodiments, the master core is any one of multiple cores; after the processor is powered on, the master core can be determined among the multiple cores. Accordingly, the scheduler in the master core is the main scheduler in the processor.

[0112] In this embodiment, the common subsystem is located within the processor, providing shared resources for all service subsystem instances within the processor; the host processor is used to run the driver. Since the common subsystem provides shared resources for all service subsystem instances within the processor, when the common subsystem generates the aforementioned common event, it cannot determine which service subsystem instance the event is related to, and therefore needs to report the common event to the main scheduling processor.

[0113] In some embodiments, the main scheduling processor may store system information corresponding to all service subsystem instances within the processor. Therefore, after receiving a common event reported by a common subsystem, the main scheduling processor may obtain the event attributes of the common event and determine the service subsystem instance related to the common event based on the system information corresponding to all service subsystem instances stored in the processor. Then, the service subsystem instance related to the common event may be designated as the scheduling processor to be dispatched.

[0114] In some embodiments, if the dispatch processor to be dispatched is the same as the main dispatch processor, the common event can be directly processed by the main dispatch processor; if the dispatch processor to be dispatched is different from the main dispatch processor, the main dispatch processor sends the common event to the dispatch processor to be dispatched through the configuration bus, and the common event is processed by the dispatch processor to be dispatched.

[0115] In this embodiment, the main scheduling processor of the processor's main core schedules all common events. This reduces the impact of common events on other cores in the processor. In other words, the scheduling processors of other cores can focus on their own task scheduling for various types of business subsystem instances, thereby ensuring task scheduling efficiency and improving overall task processing efficiency.

[0116] In some embodiments, the aforementioned public event processing unit can be a host processor. Accordingly, step S7013 can be used to send the public event to the public event processing unit through the public subsystem and process the public event through the public event processing unit.

[0117] Step S7013: If the common event processing unit is a host processor, the common event is reported to the host processor through the common subsystem; the common event is processed by the host processor.

[0118] In this embodiment, the common subsystem is located in the processor, and it provides common resources for all business subsystem instances in the processor; the host processor is used to run the driver. Since the common subsystem provides common resources for all business subsystem instances in the processor, when the common subsystem generates the aforementioned common event, it cannot determine which business subsystem instance the event is related to, and therefore needs to report the common event to the host processor.

[0119] In some embodiments, the event attributes of the common event can be obtained through the driver running in the host processor, and the processing element corresponding to the common event can be determined based on the event attributes, that is, which processing element in the processor needs to process the common event. The processing element includes, but is not limited to, the host processor, the scheduling processor, and the business subsystem instance.

[0120] Specifically, if the driver running in the host processor determines that the processing element corresponding to the common event is the host processor, the common event is processed directly by the host processor. If the driver running in the host processor determines that the processing element corresponding to the common event is a scheduling processor, the host processor can determine the scheduling processor to be sent to the common event from the target scheduling processors corresponding to each of the subsystem groups, and the host processor sends the common event to the scheduling processor to be sent, and the scheduling processor to be sent processes the common event. If the driver running in the host processor determines that the processing element corresponding to the common event is a business subsystem instance, the host processor can determine the scheduling processor to be sent to the common event from the target scheduling processors corresponding to each of the subsystem groups, and the host processor sends the common event to the scheduling processor to be sent, and the scheduling processor to be sent sends the common event to the target business subsystem instance, and the target business subsystem instance processes the common event.

[0121] For example, please refer to Figure 9, which illustrates a schematic diagram of a common event processing flow. As shown in data flow 91 of Figure 9, when a common event is generated by a common subsystem, the common event can be directly reported to the host processor through that common subsystem. The host processor, through its running driver, determines the corresponding dispatch processor for the common event from the target dispatch processors corresponding to each subsystem group. For example, the dispatch processor in core 1 is determined as the dispatch processor for the common event, as shown in data flow 92 of Figure 9. The host processor can then dispatch the common event to the dispatch processor in core 1. If the common event is processed by a graphics service subsystem instance in core 2, as shown in data flow 93 of Figure 9, the dispatch processor in core 1 transmits the common event to the graphics service subsystem instance in core 2 through a configuration bus for processing.

[0122] In this embodiment, when a common event is generated by a common subsystem, it is sent to the host processor, and the corresponding processing element is determined by the driver in the host processor. In this way, compared with the scheme of determining how to process the common event by the individual scheduling processors of the processor, the computational pressure of the scheduling processors of each core of the processor can be reduced. Correspondingly, the scheduling processors in the processor can devote more processing resources to the task scheduling process, thereby improving the task scheduling efficiency and task processing efficiency.

[0123] Figure 10 is a schematic flowchart illustrating the implementation of a task processing method according to another embodiment of this application. This method can be executed by the processor of a computer device. Based on Figure 1, the business subsystem instance is configured with an information register; the method may further include S1001, which will be described in conjunction with the steps shown in Figure 10.

[0124] Step S1001: In response to determining the target scheduling processor corresponding to the subsystem group, the group information of the subsystem group corresponding to the service subsystem instance is stored in the information register.

[0125] The grouping information is used to determine the core corresponding to each business subsystem instance within the subsystem group and the core corresponding to the target scheduling processor of the subsystem group.

[0126] In some embodiments, the service subsystem instance is configured with an information register, and the information stored in the information register is updated based on the current group information each time the group information changes.

[0127] In some embodiments, the information register includes a mask register, and storing the group information of the subsystem group corresponding to the service subsystem instance through the information register includes storing the core mask corresponding to the subsystem group through the mask register.

[0128] The core mask includes a sub-mask corresponding to each core in the processor. When the business subsystem instance corresponding to the core belongs to the subsystem group, the sub-mask corresponding to the core is set to a first value; when the business subsystem instance corresponding to the core does not belong to the subsystem group, the sub-mask corresponding to the core is set to a second value.

[0129] In some embodiments, the core mask includes N bits, where N is the number of cores in the processor; the sub-mask for each bit in the core mask is used to characterize whether the core corresponding to that bit has a service subsystem instance of the subsystem group.

[0130] Within the same subsystem group, the mask registers of business subsystem instances store the same core mask, while the mask registers of business subsystem instances in different subsystem groups store mutually exclusive core masks.

[0131] For example, please refer to Figure 8 for the two graphics subsystem instance groups obtained for the graphics subsystem instance. The processor includes cores 1 to 4, each core of which includes a graphics subsystem instance, a computing subsystem instance, and a video subsystem instance. For the four graphics subsystem instances in the processor, the graphics subsystem instances of cores 1 and 2 can be divided into a first graphics subsystem instance group, with the target scheduler being the scheduler of core 1; the graphics subsystem instances of cores 3 and 4 can be divided into a second graphics subsystem instance group, with the target scheduler being the scheduler of core 3. In this case, the mask register of the graphics subsystem instances of cores 1 and 2 stores the core mask as "1100", and the mask register of the graphics subsystem instances of cores 3 and 4 stores the core mask as "0011". It can be seen that the core masks stored in the mask registers of business subsystem instances within the same subsystem group are the same, that is, the core masks stored in the mask registers of the graphics subsystem instances of core 1 and core 2 are the same, and the core masks stored in the mask registers of the graphics subsystem instances of core 3 and core 4 are the same; at the same time, the core masks stored in the mask registers of business subsystem instances within different subsystem groups are mutually exclusive, that is, the core masks stored in the mask registers of the graphics subsystem instances of core 1 and core 2 are mutually exclusive with the core masks stored in the mask registers of the graphics subsystem instances of core 3 and core 4.

[0132] In this embodiment, by setting a mask register in the business subsystem instance and determining whether the business subsystem instance corresponding to the core belongs to the subsystem group by storing the submasks of each core in the mask register, the business subsystem instance can determine other business subsystem instances in the processor that belong to the same subsystem group and their core locations when the group information of the business subsystem instance changes. This facilitates the negotiation process of task distribution among the business subsystem instances in the subsystem group.

[0133] In some embodiments, the information register includes a number register; storing the grouping information of the subsystem group corresponding to the service subsystem instance through the information register includes: storing the identifier of the core corresponding to the target scheduler of the subsystem group through the number register.

[0134] In some embodiments, the identifier stored in the number register is the identifier of the core corresponding to the target scheduler of the subsystem group. For example, based on the two graphics subsystem instance groups obtained for the graphics subsystem instance in FIG8 above, the identifier of the core corresponding to the target scheduler stored in the number register of the graphics subsystem instance of core 1 and core 2 is "1", and the identifier of the core corresponding to the target scheduler stored in the number register of the graphics subsystem instance of core 3 and core 4 is "3".

[0135] In this embodiment of the application, by setting a number register in the business subsystem instance and storing the identifier of the core corresponding to the target scheduler of the subsystem group in the number register, the business subsystem instance can still determine the target scheduler of the latest subsystem group based on the number register when the group information of the business subsystem instance changes, so as to obtain the corresponding subtask through the target scheduler register and subsequent communication processes such as event reporting.

[0136] Based on the foregoing embodiments, this application provides a task processing device, which includes various units and modules included in each unit. It can be implemented by a processor in a computer device; of course, it can also be implemented by specific logic circuits. In the implementation process, the processor can be a central processing unit (CPU), a microprocessor unit (MPU), a digital signal processor (DSP), or a field programmable gate array (FPGA), etc.

[0137] Figure 11 is a schematic diagram of the composition structure of a processor provided in an embodiment of this application. As shown in Figure 11, the processor 1100 includes: multiple cores and a host processor 1130; the cores include service subsystem instances and scheduling processors, wherein: the host processor 1130 is configured to group service subsystem instances corresponding to a target service type in at least one of the cores to obtain at least one subsystem group 1120 corresponding to the target service type; in the scheduling processors in at least one of the cores, a target scheduling processor 1121 corresponding to the subsystem group is determined; the service subsystem instances 1122 in the subsystem group 1120 and the target scheduling processor 1121 corresponding to the subsystem group 1120 are configured to process task queues of the target service type.

[0138] It should be noted that the subsystem grouping 1120 in Figure 11 is for the purpose of illustrative purposes of the task processing method provided in the embodiments of this application, and is not a limitation on the grouping method.

[0139] In some embodiments, the host processor 1130 is configured to obtain the grouping requirements corresponding to the target service type; and to group at least one instance of a service subsystem in the core corresponding to the target service type based on the grouping requirements corresponding to the target service type, thereby obtaining at least one subsystem group 1120 corresponding to the target service type.

[0140] In some embodiments, the grouping requirement includes at least one of the following: a group quantity requirement and a requirement for the number of business subsystem instances within a subsystem group; wherein, in a virtualization scenario, the group quantity requirement is the number of users in the virtualization scenario, and the quantity requirement is determined based on the performance requirements of the users; in a multi-application scenario, the group quantity requirement is the number of applications in the multi-application scenario, and the quantity requirement is determined based on the performance requirements of the applications.

[0141] In some embodiments, the host processor 1130 is configured to, in at least one scheduling processor in the core, determine each scheduling processor corresponding to each service subsystem instance 1122 of the subsystem group 1120; and in each scheduling processor, determine a target scheduling processor 1121 corresponding to the subsystem group 1120.

[0142] In some embodiments, the host processor 1130 is configured to acquire load information of each scheduler; the load information is used to characterize the scheduling status of the scheduler for the service subsystem instance 1122 of the non-target service type; and based on the load information, the target scheduler 1121 is determined in each scheduler.

[0143] In some embodiments, the target scheduling processor 1121 is configured to, in response to a task assignment event of the target service type, acquire at least one task in the task queue and distribute the at least one task to at least one service subsystem instance 1122 in the subsystem group 1120; the at least one service subsystem instance 1122 in the subsystem group 1120 is configured to process the distributed task.

[0144] In some embodiments, the target scheduling processor 1121 is configured to, in response to a task assignment event of the target service type, obtain task information of the task and send the task information of the task to the service subsystem instance 1122 in the subsystem group 1120; the service subsystem instance 1122 in the subsystem group 1120 is configured to determine the subtask information corresponding to the service subsystem instance 1122 based on the task information of the task; and obtain and process the assigned subtask based on the corresponding subtask information.

[0145] In some embodiments, the business subsystem instance 1122 is configured to report the system event to the target scheduler 1121 corresponding to the subsystem group 1120 in response to a system event generated by the business subsystem instance 1122 in the subsystem group 1120; wherein the system event includes at least one of the following: task completion event, task-scheduler interaction event, multi-core task synchronization event, and subsystem exception event.

[0146] In some embodiments, the service subsystem instance 1122 is configured to report a first task completion event to the target scheduler 1121 corresponding to the subsystem group 1120 in response to a first task completion event generated by the service subsystem instance 1122 in the subsystem group 1120; the first task completion event is generated when the service subsystem instance 1122 finishes processing the distributed subtask; the target scheduler 1121 is configured to report a second task completion event to the host processor 1130 in the processor in response to the target scheduler 1121 corresponding to the subsystem group 1120 receiving the first task completion event reported by the service subsystem instance 1122 in the subsystem group 1120; the second task completion event is used to indicate that the task of the target service type has been completed.

[0147] In some embodiments, the processor further includes a common subsystem for providing common resources to the business subsystem instance 1122; the common subsystem is configured to send a common event to a common event processing unit in response to a common event corresponding to the common subsystem; the common event processing unit is configured to process the common event.

[0148] In some embodiments, the processor further includes a host processor; when the common event processing unit is a target scheduling processor, the common subsystem is configured to report the common event to all target scheduling processors of the processor; when a target scheduling processor determines that the common event is related to itself, the target scheduling processor is configured to process the common event; or, when the common event processing unit is a target scheduling processor, the common subsystem is configured to report the common event to a master scheduling processor; the master scheduling processor is the scheduling processor of the master core among the plurality of cores; the master scheduling processor is configured to determine the scheduling processor to be dispatched corresponding to the common event among the target scheduling processors corresponding to each subsystem group; the master scheduling processor is configured to dispatch the common event to the scheduling processor to be dispatched, and the scheduling processor to be dispatched is configured to process the common event; or, when the common event processing unit is a host processor, the common subsystem is configured to report the common event to the host processor; the host processor is configured to process the common event.

[0149] In some embodiments, the service subsystem instance 1122 is configured with an information register; the information register is configured to store group information of the subsystem group 1120 corresponding to the service subsystem instance 1122 in response to determining the target scheduler 1121 corresponding to the subsystem group; the group information is used to determine the core corresponding to each service subsystem instance 1122 in the subsystem group 1120 and the core corresponding to the target scheduler 1121 of the subsystem group 1120.

[0150] In some embodiments, the information register includes a mask register; the mask register is configured to store a core mask corresponding to the subsystem group 1120; wherein, the core mask includes a sub-mask corresponding to each core in the processor, and when the service subsystem instance 1122 corresponding to the core belongs to the subsystem group 1120, the sub-mask corresponding to the core is set to a first value; when the service subsystem instance 1122 corresponding to the core does not belong to the subsystem group 1120, the sub-mask corresponding to the core is set to a second value; the core masks stored in the mask registers of service subsystem instances within the same subsystem group are the same, and the core masks stored in the mask registers of service subsystem instances within different subsystem groups are mutually exclusive.

[0151] In some embodiments, the information register includes a number register; the number register is configured to store an identifier of the core corresponding to the target scheduler 1121 of the subsystem group 1120.

[0152] Of course, the task processing method provided in this application embodiment can take different forms in actual implementation scenarios.

[0153] In some embodiments, a single scheduling processor manages a business subsystem instance. For example, when the business subsystem instances include two types, business subsystem instance A and business subsystem instance B, a first scheduling processor may be responsible for task scheduling of business subsystem instance A, and a second scheduling processor may be responsible for task scheduling of business subsystem instance B. Referring to Figure 12, business subsystem instances A1221 to A1223 all correspond to the first scheduling processor 1211; business subsystem instances B1231 to B1233 all correspond to the second scheduling processor 1212.

[0154] In some embodiments, a service subsystem instance is handled by at least two schedulers, i.e., by different schedulers. For example, when the service subsystem instances include two types, service subsystem instance A and service subsystem instance B, service subsystem instance A can be divided into at least two groups, service subsystem instance B can be divided into at least two groups, and service subsystem instances in different groups are handled by different schedulers. Referring to Figure 13, service subsystem instances A1221 and A1222 both correspond to the first scheduler 1211; service subsystem instances A1223 and A1224 correspond to the second scheduler 1212. Service subsystem instances B1231 and B1232 both correspond to the third scheduler 1213; service subsystem instances B1233 and B1234 correspond to the fourth scheduler 1214.

[0155] In some other embodiments, the two methods described above can be combined in a single processor, as shown in Figure 14, wherein service subsystem instance A1221 and service subsystem instance A1222 both correspond to the first scheduling processor 1211; service subsystem instance A1223 corresponds to the second scheduling processor 1212; and service subsystem instances B1231 to B1233 all correspond to the third scheduling processor 1213.

[0156] This application provides a computer device including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements some or all of the steps in the above-described method.

[0157] This application provides a computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements some or all of the steps in the above-described method. The computer-readable storage medium can be transient or non-transient.

[0158] This application provides a computer program including computer-readable code. When the computer-readable code is run in a computer device, the processor in the computer device executes some or all of the steps in the above method.

[0159] This application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a Software Development Kit (SDK), etc.

[0160] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0161] Figure 15 is a schematic diagram of the hardware entity of a computer device provided in an embodiment of this application. As shown in Figure 15, the hardware entity of the computer device 1500 includes a processor 1501 and a memory 1502. The memory 1502 stores a computer program that can run on the processor 1501. When the processor 1501 executes the program, it implements the steps in the method of any of the above embodiments.

[0162] The memory 1502 stores computer programs that can run on the processor. The memory 1502 is configured to store instructions and applications that can be executed by the processor 1501. It can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data and video communication data) in the processor 1501 and various modules in the computer device 1500. This can be achieved through flash memory or random access memory (RAM).

[0163] When the processor 1501 executes a program, it implements the steps of any of the above-mentioned task processing methods. The processor 1501 typically controls the overall operation of the computer device 1500.

[0164] This application provides a computer storage medium that stores one or more programs, which can be executed by one or more processors to implement the steps of the task processing method as described in any of the above embodiments.

[0165] It should be noted that the descriptions of the storage media and device embodiments above are similar to the descriptions of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the storage media and device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0166] The aforementioned processor can be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor. It is understood that other electronic devices can also implement the functions of the aforementioned processor, and this application does not specifically limit the specific implementation.

[0167] The aforementioned computer storage media / memory can be Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Ferromagnetic Random Access Memory (FRAM), Flash Memory, Magnetic Surface Memory, optical discs, or Compact Disc Read-Only Memory (CD-ROM), etc.; it can also be various terminals that include one or any combination of the above-mentioned memory types, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0168] It should be understood that the phrase "an embodiment" or "one embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "one embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0169] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0170] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or elements can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interface, and the indirect coupling or communication connection of devices or units can be electrical, mechanical, or other forms.

[0171] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0172] Furthermore, in the various embodiments of this application, all functional units can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units. Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0173] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence or the part that contributes to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as removable storage devices, ROMs, magnetic disks, or optical disks.

[0174] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

[0175] 61, 62, 63, 81, 83, 91, 92, 93: Data Flow 1100: Processor 1120: Subsystem Grouping 1121: Target Scheduler 1122: Example of a Business Subsystem 1130: Host Processor 1211: First Scheduler 1212: Second Scheduler 1213: Third Scheduler 1214: Fourth Scheduler 1500: Computer equipment 1502: Processor 1502: Memory A1221, A1222, A1223, A1224, B1231, B1232, B1233, B1234: Examples of Business Subsystems S101-S103, S201-S202, S301-S302, S3021-S3022, S401-S402, S501-S503, S601, S6011, S701, S7011-S7013, S1001: Steps

Claims

1. A task processing method applied to a processor comprising multiple cores, wherein the cores include a scheduling processor and a business subsystem instance; the method comprising: Group the business subsystem instances corresponding to at least one target business type in the core to obtain at least one subsystem group corresponding to the target business type; In at least one of the scheduling processors in the core, a target scheduling processor corresponding to the subsystem group is determined; and the task queue of the target service type is processed using the service subsystem instance in the subsystem group and the corresponding target scheduling processor.

2. The method as described in request item 1, wherein grouping at least one instance of a business subsystem corresponding to a target business type in the core to obtain at least one subsystem group corresponding to the target business type includes: Obtain the grouping requirements corresponding to the target business type; And based on the grouping requirements corresponding to the target business type, at least one instance of the business subsystem corresponding to the target business type in the core is grouped to obtain at least one subsystem group corresponding to the target business type.

3. The method as described in request item 2, wherein the grouping requirement includes at least one of the following: a group quantity requirement and a requirement for the number of business subsystem instances within a subsystem group; wherein, In a virtualization scenario, the required number of groups is the number of users in the virtualization scenario, and the required number is determined based on the performance requirements of the users; and in a multi-application scenario, the required number of groups is the number of applications in the multi-application scenario, and the required number is determined based on the performance requirements of the applications.

4. The method as described in claim 1, wherein determining the target scheduler corresponding to the subsystem group in at least one of the schedulers in the core includes: In at least one scheduling processor in the core, each scheduling processor corresponding to each business subsystem instance of the subsystem group is determined; And in each of the scheduling processors, the target scheduling processor corresponding to the subsystem group is determined.

5. The method as described in claim 4, wherein determining the target scheduler corresponding to the subsystem group in each scheduler includes: Obtain load information for each scheduler processor; The load information is used at least to characterize the scheduling processor's scheduling status for service subsystem instances that are not target service types; And based on the load information, the target scheduling processor is determined in each scheduling processor.

6. The method as described in request item 1, wherein processing the task queue of the target service type using the service subsystem instance and the corresponding target scheduler in the subsystem group includes: In response to a task assignment event of the target service type, at least one task in the task queue is obtained through the target scheduler, and the at least one task is distributed to at least one service subsystem instance in the subsystem group; and the distributed task is processed by the at least one service subsystem instance in the subsystem group.

7. The method as described in Request 1, wherein processing the task queue of the target service type using the service subsystem instance and the corresponding target scheduler in the subsystem group includes: In response to a task assignment event of the target service type, the task information of the task is obtained through the target scheduler, and the task information of the task is sent to the service subsystem instance in the subsystem group; the subtask information corresponding to the service subsystem instance is determined based on the task information of the task through the service subsystem instance in the subsystem group; and the assigned subtask is obtained and processed based on the corresponding subtask information through the service subsystem instance in the subsystem group.

8. The method as described in claim 1, wherein the method further comprises: In response to system events generated by business subsystem instances in the subsystem group, the system events are reported to the target scheduler corresponding to the subsystem group through the business subsystem instances; wherein, the system events include at least one of the following: task completion event, task-scheduler interaction event, multi-core task synchronization event, and subsystem exception event.

9. The method as described in claim 8, wherein the processor further comprises a host processor; the step of reporting the system event to the target scheduling processor corresponding to the subsystem group through the service subsystem instance in response to a system event generated in the subsystem group includes: In response to a first task completion event generated by a business subsystem instance in the subsystem group, the first task completion event is reported to the target scheduler corresponding to the subsystem group through the business subsystem instance. The method further includes: in response to the target scheduling processor corresponding to the subsystem group receiving the first task completion event reported by the distributed business subsystem instance within the subsystem group, reporting a second task completion event to the host processor in the processor through the target scheduling processor; The second task completion event is used to indicate that the task of the target business type has been completed.

10. The method of claim 1, wherein the processor further comprises a common subsystem for providing common resources for the business subsystem instances; the method further comprises: In response to a public event corresponding to the public subsystem, the public event is sent to the public event processing unit through the public subsystem, and the public event is processed by the public event processing unit.

11. The method as described in claim 10, wherein the processor further comprises a host processor; the step of sending the public event to the public event processing unit through the public subsystem, and processing the public event through the public event processing unit, includes: When the common event processing unit is a target scheduling processor, the common event is reported to all target scheduling processors of the processor through the common subsystem; And if the target scheduler determines that the common event is related to itself, the target scheduler processes the common event; Alternatively, if the common event processing unit is the target scheduling processor, the common event may be reported to the main scheduling processor through the common subsystem. The main scheduling processor is the scheduling processor of the main core among the plurality of cores; The main scheduling processor determines the scheduling processor to be dispatched for the common event from the target scheduling processors corresponding to each subsystem group. The common event is sent from the main scheduling processor to the scheduling processor to be sent, and the common event is processed by the scheduling processor to be sent. Alternatively, if the common event processing unit is a host processor, the common event may be reported to the host processor through the common subsystem; and the common event may be processed by the host processor.

12. The method as described in any one of requests 1 to 11, wherein the business subsystem instance is configured with an information register; the method further includes: In response to determining the target scheduling processor corresponding to the subsystem group, the grouping information of the subsystem group corresponding to the service subsystem instance is stored in the information register; The grouping information is used to determine the core corresponding to each business subsystem instance within the subsystem group and the core corresponding to the target scheduling processor of the subsystem group.

13. The method as described in request item 12, wherein the information register includes a mask register; the step of storing grouping information of the subsystem group corresponding to the service subsystem instance through the information register includes: The core mask corresponding to the subsystem group is stored in the mask register; wherein, the core mask includes a sub-mask corresponding to each core in the processor, and when the business subsystem instance corresponding to the core belongs to the subsystem group, the sub-mask corresponding to the core is set to a first value; when the business subsystem instance corresponding to the core does not belong to the subsystem group, the sub-mask corresponding to the core is set to a second value; the core masks stored in the mask register of business subsystem instances within the same subsystem group are the same, and the core masks stored in the mask register of business subsystem instances within different subsystem groups are mutually exclusive.

14. The method as described in request item 12, wherein the information register includes a number register; the step of storing grouping information of the subsystem group corresponding to the business subsystem instance through the information register includes: The identifier of the core corresponding to the target scheduling processor of the subsystem group is stored in the number register.

15. A processor, wherein the processor includes multiple cores, the cores including a host processor, a service subsystem instance, and a scheduling processor, wherein: The host processor is configured to group at least one instance of a business subsystem corresponding to a target business type in the core, thereby obtaining at least one subsystem group corresponding to the target business type. In at least one of the scheduling processors in the core, a target scheduling processor corresponding to the subsystem group is determined; and the service subsystem instance in the subsystem group and the target scheduling processor corresponding to the subsystem group are configured to process task queues of the target service type.

16. A computer device including a memory and a processor, wherein the memory stores a computer program executable on the processor, wherein the processor, when executing the program, implements the steps of the method described in any one of claims 1 to 14.

17. A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the method described in any one of claims 1 to 14.

Images