Information processing device and information processing method

Abstract

To prevent a decrease in processing speed.SOLUTION: An information processing device 1 includes a plurality of physical CPUs 10 and a control unit 40. Each of the plurality of physical CPUs 10 has a plurality of CPU cores 11. The control unit 40 performs control to select, from one physical CPU 10 among the plurality of physical CPUs 10, the two or more CPU cores 11 on which an application executed using the two or more CPU cores 11 is to be executed.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to an information processing device and an information processing method. [Background technology]

[0002] There are several known techniques for managing allocation of processing resources to applications to be executed (see, for example, Patent Documents 1 and 2). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2022-180850 [Patent Document 2] Japanese Patent Application Laid-Open No. 2006-244479 Summary of the Invention [Problem to be solved by the invention]

[0004] When a composite application consisting of multiple applications is executed, data transfer may occur between the applications. Consider an information processing device equipped with multiple physical CPUs, each of which has multiple CPU (Central Processing Unit) cores, where each application constituting the composite application is executed on a CPU core of a separate physical CPU. In this case, data transfer between applications is performed using an inter-CPU bus connecting the physical CPUs. Therefore, if this data transfer occurs frequently, a bottleneck in the bandwidth of the inter-CPU bus will cause delays in data transmission between the physical CPUs, resulting in a decrease in the processing speed of the composite application by the information processing device.

[0005] In one aspect, the present invention aims to suppress a decrease in processing speed. [Means for solving the problem]

[0006] In one embodiment, an information processing device includes a plurality of physical CPUs and a control unit. Each of the plurality of physical CPUs includes a plurality of CPU cores. The control unit controls the selection of two or more CPU cores from one of the plurality of physical CPUs to execute an application executed using the two or more CPU cores. [Effects of the Invention]

[0007] In one aspect, the present invention suppresses a decrease in processing speed. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 2 illustrates an example of the configuration of a physical server. [Figure 2] 10A and 10B are diagrams illustrating an example of allocation of CPU cores to applications constituting a composite application and deployment of accelerators by a control unit. [Figure 3] 10 is a flowchart illustrating an example of an application startup process. [Figure 4] FIG. 10 is a diagram illustrating an example of data in a group registration table. [Figure 5] 10 is a flowchart illustrating an example of a CPU core allocation process. [Figure 6] FIG. 10 is a diagram illustrating an example of data in a CPU information table. [Figure 7] FIG. 10 is a diagram illustrating an example of data in a CPU utilization rate table. [Figure 8] 10 is a flowchart illustrating an example of a deployment request process. [Figure 9] 10 is a flowchart illustrating an example of a deployment request process. [Figure 10] 10A and 10B are diagrams showing examples of data in an accelerator information table and a standby accelerator number table. DETAILED DESCRIPTION OF THE INVENTION

[0009] When a composite application, which is an application composed of multiple applications, is executed on an information processing device equipped with multiple physical CPUs each having multiple CPU cores, data transfer may occur between the applications. When each application constituting the composite application is executed on a CPU core possessed by a separate physical CPU, data transfer between the applications is performed using the inter-CPU bus connecting the physical CPUs. Therefore, if this data transfer occurs frequently, delays in data transfer may occur due to a bottleneck in the bandwidth of the inter-CPU bus.

[0010] Also, information processing devices equipped with a computing device (accelerator) suitable for a specific operation are known. In such information processing devices, a part of the processing of an application that would be slow if executed by a general-purpose CPU is offloaded to the accelerator, thereby realizing faster processing.

[0011] Also, information processing devices equipped with multiple accelerators, such as disaggregated computers, are known. Such information processing devices may use an orchestrator. The orchestrator, for example, manages the deployment of each accelerator and deploys each accelerator included in the information processing device to an application executed on a physical CPU included in the information processing device. In this case, if an accelerator under a physical CPU other than the physical CPU that executes the application is deployed to the application, communication for accessing the accelerator from the application is performed via an inter-CPU bus. In this case, a bandwidth bottleneck on the inter-CPU bus may cause delays in communication between physical CPUs, resulting in a decrease in performance when the application accesses the processing offloaded to the accelerator.

[0012] Furthermore, when such an information processing device is used to execute a composite application consisting of multiple applications, data may be passed between the applications. In this case, if some of the processing in each application constituting the composite application is offloaded to an accelerator, data may also be passed between the accelerators deployed for each application. If accelerators under different physical CPUs are deployed for each application, communication for data exchange between the accelerators also occurs via the inter-CPU bus. Therefore, in this case, too, a bandwidth bottleneck on the inter-CPU bus can cause delays in communication between the physical CPUs, making it difficult to guarantee the execution performance of the composite application.

[0013] Therefore, in the embodiment described below, the multiple applications that make up the composite application are executed by each CPU core of one of the multiple physical CPUs included in the information processing device. In this way, it is possible to reduce (or eliminate) the need for data transfer between applications to go through the inter-CPU bus, thereby suppressing a decrease in processing speed due to the bandwidth of the inter-CPU bus.

[0014] In the embodiment described below, when a portion of the processing in each application constituting a composite application is offloaded to an accelerator, an accelerator under the one physical CPU is deployed to each application. In this way, access from an application to an accelerator and communication for transferring data between accelerators are performed without going through the inter-CPU bus, thereby suppressing a decrease in processing speed due to the bandwidth of the inter-CPU bus.

[0015] Hereinafter, embodiments will be described in detail with reference to the drawings.

[0016] 1 shows an example of the configuration of a physical server 1. The physical server 1 is an example of an information processing device.

[0017] The physical server 1 includes multiple physical CPUs 10, each having multiple CPU cores 11. In the configuration example of Fig. 1, the physical server 1 includes two physical CPUs 10, each having eight CPU cores 11, but the number of physical CPUs 10 included in the physical server 1 and the number of CPU cores 11 included in each physical CPU 10 do not have to be the number shown in Fig. 1.

[0018] In the physical server 1, the physical CPUs 10 are connected one-to-one by an inter-CPU bus 20. The inter-CPU bus 20 is a data transmission path between the physical CPUs 10, and is, for example, a QPI (Quick Path Interconnect) or a UPI (Ultra Path Interface).

[0019] The physical server 1 also includes a plurality of accelerators 30, and the accelerators 30 are connected to each of the plurality of physical CPUs 10 via a PCIe bus 31. The PCIe bus 31 is a data transmission path conforming to the PCIe (Peripheral Component Interconnect-Express) standard, but the physical CPUs 10 and the accelerators 30 may be connected via an interface conforming to another standard.

[0020] In this application, an accelerator 30 that can transmit data to and from a physical CPU 10 using such an interface without going through another physical CPU 10 will be referred to as an accelerator 30 subordinate to that physical CPU 10.

[0021] Furthermore, in the configuration example of FIG. 1, each physical CPU 10 has six subordinate accelerators 30, but the number of subordinate accelerators 30 that each physical CPU 10 has does not have to be the number shown in FIG. 1.

[0022] 1 further includes a control unit 40 that controls each component of the physical server 1. The control unit 40 may be configured, for example, by one of the CPU cores 11 of the physical CPU 10 included in the physical server 1 executing a predetermined control program. In this embodiment, the control processes executed by the control unit 40 include an application startup process 41 and an orchestrator process 42.

[0023] The application startup process 41 is a process for allocating a CPU core 11 that executes each application to each of the applications that make up the composite application and starting the applications when the composite application is executed on the physical server 1. However, in this embodiment, the application startup process 41 selects one of the multiple physical CPUs 10 of the physical server 1 as the CPU core 11 to be allocated to each of the applications that make up the composite application that is executed using two or more CPU cores 11.

[0024] The orchestrator processing 42 is a processing for providing a function as an orchestrator. In this embodiment, in response to a request to deploy the accelerator 30, the orchestrator processing 42 deploys the accelerator 30 under the physical CPU 10 having the CPU core 11 assigned to the application to the application that made the request.

[0025] Here, an example of allocation of the CPU core 11 to each application constituting the composite application and deployment of the accelerator 30 by the control unit 40 will be described with reference to FIG.

[0026] Here, an example will be described in which an application that performs video analysis processing is executed on physical server 1. Note that this application that performs video analysis processing is a composite application consisting of three applications for performing decoding processing, AI analysis processing, and encoding processing, respectively. Note that "AI" is an abbreviation for artificial intelligence. Also, it is assumed that all three applications provide part of their functions through offload processing performed using one accelerator 30.

[0027] In this case, the application startup process 41 first groups the above-mentioned three applications that make up the composite application that performs video analysis processing into one group. Next, when starting each application, the application startup process 41 assigns one CPU core 11 selected from the multiple CPU cores 11 possessed by one physical CPU 10 out of the multiple physical CPUs 10 to each application in the same group. In this embodiment, the application startup process 41 refers to the CPU usage rate of each of the multiple CPU cores 11 possessed by one physical CPU 10, and selects and assigns the CPU core 11 to each application in ascending order of CPU usage rate. Note that a CPU affinity function provided by the OS (Operating System) of the physical server 1, for example, is used to assign CPU cores 11 to applications.

[0028] Figure 2 shows a state in which the application startup process 41 has assigned three applications, namely, decoding processing, AI analysis processing, and encoding processing, to all three CPU cores 11 of the physical CPU 10 on the left side of the physical server 1.

[0029] Next, the orchestrator processing 42 acquires a deployment request for an accelerator 30 from each application in the same group. This deployment request includes information on the number of accelerators 30 required for offload processing by the application that requested the deployment request. The orchestrator processing 42 calculates the total required number of accelerators 30 included in the deployment requests from each application in the same group. The orchestrator processing 42 also acquires the number of accelerators 30 in a standby state among those subordinate to the physical CPU 10 having the CPU cores 11 that the application startup processing 41 assigned to each application in the same group. Then, if the total value of the required number is equal to or less than the acquired number of accelerators 30 in a standby state, the orchestrator processing 42 deploys the required number of accelerators 30 in a standby state to each application that requested the deployment request.

[0030] 2 shows a state in which one accelerator 30 is deployed for each of three applications, namely, decoding processing, AI analysis processing, and encoding processing, by the orchestrator processing 42. Furthermore, it shows that all three of these deployed accelerators 30 are accelerators 30 subordinate to the physical CPU 10 on the left side, which has a CPU core 11 assigned to each of the three applications.

[0031] The application startup process 41, the orchestrator process 42, and the process performed by each application to request the deployment of the accelerator 30 will be further described below.

[0032] First, an example of the application startup process 41 will be described with reference to the flowchart of FIG.

[0033] When the processing in FIG. 3 starts, first, in S101, the same group ID (Identification) is assigned to each application constituting the composite application, thereby grouping the applications into one group.

[0034] 4 shows an example of data in the group registration table 51. The group registration table 51 is a table that associates "application names" with "group IDs." The "application names" are names that identify the applications that make up the composite application, and the "group IDs" are group IDs that are assigned to each application by the processing in S101.

[0035] For example, in the data example of Fig. 4, in the records from the first to third lines, the same group ID "1" is associated with each of the three applications that make up a certain video analysis process: "decoding process A," "AI process A," and "encoding process A." Therefore, the data in these records indicates that the three applications, "decoding process A," "AI process A," and "encoding process A," are grouped together as one group.

[0036] In this embodiment, it is assumed that information indicating the relationship between a composite application and each application that constitutes the composite application is provided to the physical server 1 in advance.

[0037] 3, next, in S102, a CPU core allocation process is performed. The CPU core allocation process is a process of selecting and allocating one CPU core 11 from the multiple CPU cores 11 possessed by one physical CPU 10 as the CPU core 11 that will execute each application included in the same group, and the details of this process will be described later.

[0038] Next, in S103, a process is performed in which each application is started on the CPU core 11 according to the allocation result obtained in the process of S102.

[0039] Next, in S104, a process is performed in which the group ID assigned in the process of S101 is notified to each application started in the process of S103.

[0040] Next, in S105, a process is performed in which a deployable / undeployable notification indicating the result of the deployment of the accelerator 30 by the orchestrator process 42 described below is received from each application. For example, if the deployable / undeployable notification indicates that the accelerator 30 was not deployed, the deployable / undeployable notification may be used to select a CPU core 11 from another physical CPU 10 that will execute each application in subsequent processing.

[0041] After the process of S105 is completed, the application startup process 41 is terminated.

[0042] Next, an example of the CPU core allocation process, which is the process of S102 in FIG. 3, will be described with reference to the flowchart in FIG.

[0043] When the process of FIG. 5 starts, first, in S111, the process of substituting the initial value "1" for the variable n is performed.

[0044] Next, in S112, the CPU information table 52 is referenced, and a process is performed to acquire the "CPUID" in each record in which the value of the variable n is indicated as the "physical CPU number."

[0045] 6 shows an example of data in CPU information table 52. CPU information table 52 is a table that associates "CPUID" with "physical CPU number." "CPUID" is identification information that identifies CPU core 11 of multiple physical CPUs 10 provided in physical server 1, and "physical CPU number" is number information that identifies physical CPU 10 that has CPU core 11 identified by "CPUID." In this embodiment, it is assumed that in physical server 1, the CPUID of each CPU core 11 and the physical CPU number of each physical CPU 10 are predetermined, and CPU information table 52 is prepared in advance.

[0046] 6, it can be seen that the CPU cores 11 with CPUIDs of "1," "3," "5," "7," "9," "11," ..., and "15" are all CPU cores 11 that belong to the physical CPU 10 with physical CPU number "1." It can also be seen that the CPU cores 11 with CPUIDs of "2," "4," "6," "8," "10," "12," ..., and "16" are all CPU cores 11 that belong to the physical CPU 10 with physical CPU number "2."

[0047] In the case of the data example of Figure 6, if the processing of S112 of Figure 5 is executed after the processing of S111, the CPUIDs indicated in each record with the physical CPU number "1" are obtained: "1", "3", "5", "7", "9", "11", ..., "15".

[0048] In S113 following S112, a process is performed in which the CPU utilization rate of the CPU core 11 identified by the CPU ID obtained in the process of S112 is obtained from the CPU utilization rate table 53.

[0049] 7 shows an example of data in the CPU usage rate table 53. The CPU usage rate table 53 is a table showing the CPU usage rate of a CPU core 11 identified by a CPUID, and is a table in which the CPUID is associated with the CPU usage rate. In this embodiment, it is assumed that the OS of the physical server 1 obtains the CPU usage rate of the CPU core 11 and creates the CPU usage rate table 53.

[0050] In S114 following S113, a process is performed in which, among the CPUIDs acquired in the process of S113, the number of CPUIDs whose CPU utilization rate associated with the CPUID in the CPU utilization rate table 53 is lower than 100% is counted. This process is performed to exclude CPU cores 11 whose CPU utilization rate has reached 100% from the CPU cores 11 that can execute applications.

[0051] Next, in S115, the number of applications that belong to the same group as a result of the grouping performed in the process of S101 in FIG. 3, that is, the number of applications that have been assigned the same group ID, is counted and acquired.

[0052] In the data example of the group registration table 51 in Figure 4, for example, the applications assigned the group ID "1" are "decoding processing A," "AI processing A," and "encoding processing A," so the count value by the processing of S115 is "3."

[0053] Next, in S116, it is determined whether the number of applications acquired in the process of S115 is equal to or less than the number of CPUIDs counted in the process of S114. In this determination process, if it is determined that the number of applications is equal to or less than the number of CPUIDs (if the determination result is YES), the process proceeds to S118. On the other hand, in this determination process, if it is determined that the number of applications is greater than the number of CPUIDs (if the determination result is NO), the process proceeds to S117.

[0054] The process of S117 is performed when it is determined that all of the applications belonging to the same group cannot be executed by the CPU core 11 of the physical CPU 10 whose physical CPU number is the value of the variable n at the time of this process. In S17, the value of the variable n is incremented (increased by "1"). Then, the process returns to S112, and a new process is performed to determine whether all of the applications belonging to the same group can be executed by the CPU core 11 of another physical CPU 10.

[0055] On the other hand, in S118, a process is performed in which CPUIDs equal to the number of applications obtained in the process of S115 are identified from the CPUIDs obtained in the process of S112, in order of lowest CPU usage rate obtained in the process of S113.

[0056] 7, the three CPU cores 11 having CPUIDs "7," "9," and "11" respectively have CPU usage rates of "0" (%), which is the lowest. Therefore, if the number of applications acquired by the process of S115 is "3," "7," "9," and "11" are identified by the process of S117.

[0057] In this case, if the CPU utilization table 53 contains four or more CPUIDs with a CPU utilization of "0" (%), three of the CPUIDs are identified. Any method may be used to select the CPUIDs to be identified. For example, if the CPUIDs are numbers, the CPUIDs may be identified in ascending order of numbers.

[0058] Next, in S119, the CPU core 11 identified by the CPU ID identified in the process of S118 is assigned to each of the applications that belong to the same group and are assigned the same group ID.

[0059] When the process of S119 is completed, the CPU core allocation process of FIG. 5 is completed, and then the process returns to the flowchart of FIG. 3, where the processes from S103 onward are performed.

[0060] By performing the above CPU core allocation process, one of the multiple CPU cores 11 included in one physical CPU 10 is allocated as the CPU core 11 that executes each application that constitutes the composite application.

[0061] Next, the deployment request process will be described with reference to a flowchart of FIG.

[0062] The deployment request process is a process in which an application requests the orchestrator process 42 to deploy the accelerator 30 that offloads part of the processing of the application, and receives a deployment success / failure notification indicating the result of the deployment. This deployment request process is performed when each application is started by executing it on the assigned CPU core 11 in the process of S103 in the application start process 41 shown in FIG.

[0063] When the processing in FIG. 8 starts, first, in S201, a process is performed in which the group ID notified from the application startup process 41 in the process in S104 in FIG. 3 is received.

[0064] Next, in S202, a process is performed to send a deployment request for the accelerator 30 to the orchestrator processing 42. This deployment request includes information on the number of requested accelerators and the group ID received in the process of S201. The number of requested accelerators is the number of accelerators 30 used to offload part of the processing by the application that issued the deployment request. In this embodiment, the number of requested accelerators is assumed to be preset in the application that issued the deployment request.

[0065] Next, in S203, a process is performed to receive a deployable / undeployable notification indicating the result of the deployment of the accelerator 30 performed in response to the deploy request, which is notified from the orchestrator processing 42 as a response to the deploy request sent in the process of S201.

[0066] Next, in S204, the deployable / undeployable notification received in the process of S203 is sent to the application startup process 41. The deployable / undeployable notification sent in this process is received in the process of S105 in the application startup process 41 shown in FIG.

[0067] When the process of S204 ends, this deployment request process ends.

[0068] Next, an example of the orchestrator process 42 will be described with reference to the flowchart of FIG.

[0069] The flowchart in FIG. 9 starts when a deployment request sent by one of the applications constituting the composite application as a result of execution of the process in S202 in the deployment request process in FIG. 8 is received.

[0070] 9 starts, a process loop from S301 to S303 is first started. This process loop continues until a predetermined time has elapsed since it was started. Then, as the process of S302 within this process loop, a process is performed to receive a deploy request sent from another application that has the same group ID as the deploy request that triggered the start of orchestrator process 42. In this embodiment, this process loop completes the reception of deploy requests sent from all applications that have the same group ID, that is, all applications that constitute the composite application.

[0071] When the above-described processing loop ends, next, in S304, a process is performed to calculate and obtain the total number of requested accelerators for each application included in the deployment request having the same group ID. The total value obtained by this process is information on the number of accelerators 30 used in executing the composite application composed of each application.

[0072] Next, in S305, a process is performed to obtain the number of accelerators 30 that are in standby state and are subordinate to the physical CPU 10 that has all of the CPU cores 11 currently executing the application that requested the deployment request and has the same group ID.

[0073] In this embodiment, the control unit 40 that executes the orchestrator processing 42 uses an accelerator information table 54 and a standby accelerator number table 55 to manage the status of each accelerator 30 included in the physical server 1. FIG. 10 shows an example of data in the accelerator information table 54 and the standby accelerator number table 55.

[0074] The accelerator information table 54 is a table that associates "physical CPU number," "accelerator information," and "deployment." The "physical CPU number" is number information that identifies the physical CPU 10 included in the physical server 1 and is the same information as that shown in the CPU information table 52. The "accelerator information" is a name that identifies the accelerator 30 included in the physical server 1. The association between the "physical CPU number" and the "accelerator information" indicates the relationship between the physical CPU 10 and the accelerator 30 subordinate to the physical CPU 10. Furthermore, "deployment" indicates the deployment status of the accelerator 30 identified by the "accelerator information." Here, if the accelerator 30 is deployed to any application, the "deployment" data associated with the "accelerator information" that identifies the accelerator 30 is set to "completed." On the other hand, if the accelerator 30 is not deployed to any application and is in a standby state, the "deployment" data associated with the "accelerator information" that identifies the accelerator 30 is set to "empty."

[0075] The standby accelerator number table 55 is a table that associates the physical CPU number of a physical CPU 10 with the number of accelerators 30 that are in a standby state among the accelerators 30 subordinate to the physical CPU 10.

[0076] Referring to the data example of the accelerator information table 54 in Fig. 10, among the accelerators 30 with a physical CPU number of "1," there are six accelerators 30 with an "empty" deployment. Also, among the accelerators 30 with a physical CPU number of "2," there are five accelerators 30 with an "empty" deployment. Therefore, in the standby accelerator count table 55 in Fig. 10, the record with the physical CPU number of "1" indicates the number of standby accelerators as "6," and the record with the physical CPU number of "2" indicates the number of standby accelerators as "5."

[0077] In the process of S305 in FIG. 9 described above, the number of accelerators 30 in a standby state is acquired by referring to this standby accelerator number table 55.

[0078] Next, in S306, a process is performed to determine whether the number of accelerators 30 to be used in executing the composite application, calculated in the process of S304, is equal to or less than the number of accelerators 30 in a standby state, acquired in the process of S305. In this determination process, if it is determined that the number of accelerators 30 to be used is equal to or less than the number of accelerators 30 in a standby state (if the determination result is YES), the process proceeds to S307. On the other hand, in this determination process, if it is determined that the number of accelerators 30 to be used is greater than the number of accelerators 30 in a standby state (if the determination result is NO), the process proceeds to S309.

[0079] In S307, the process deploys the number of subordinate accelerators 30 in standby state obtained by the process of S305 to the physical CPU 10 on which each application that has requested the deployment request and has the same group ID is running.

[0080] Next, in S308, a process is performed in which a deployment success / failure notification indicating that deployment is possible (deployment has been performed) is sent to each application that has the same group ID and has issued a deployment request, and then this orchestrator process 42 is terminated.

[0081] On the other hand, in S309, a process is performed in which a deployment notification indicating that deployment is not possible (deployment could not be performed) is sent to each application that has the same group ID and has made a deployment request, and then this orchestrator process 42 is terminated.

[0082] By performing the above orchestrator processing 42, only the accelerators 30 under the physical CPU 10 having the CPU cores 11 that execute the applications that make up the composite application are deployed to each application.

[0083] While the disclosed embodiments and their advantages have been described in detail above, those skilled in the art may make various modifications, additions, and omissions without departing from the scope of the invention as clearly set forth in the claims. [Explanation of symbols]

[0084] 1 physical server 10 physical CPUs 11 CPU cores 20 Inter-CPU bus 30 Accelerator 31 PCIe buses 40 Control Unit 41 Application startup process 42 Orchestrator Processing 51 Group Registration Table 52 CPU Information Table 53 CPU Usage Table 54 Accelerator Information Table 55 Waiting Accelerator Count Table

Claims

1. a plurality of physical CPUs each having a plurality of CPU (Central Processing Unit) cores; a control unit that performs control to select, from one physical CPU among the plurality of physical CPUs, two or more CPU cores that execute an application that is executed using the two or more CPU cores among the plurality of CPU cores; An information processing device comprising:

2. 2. The information processing apparatus according to claim 1, wherein the control unit selects the two or more CPU cores from the plurality of CPU cores included in the one physical CPU in descending order of usage rate.

3. Each of the plurality of physical CPUs has a plurality of accelerators under its control, the control unit selects the accelerator to be used in executing the application from the accelerators under the control of the one physical CPU; 3. The information processing apparatus according to claim 1, wherein the information processing apparatus is a computer.

4. 4. The information processing apparatus according to claim 3, wherein the control unit selects the accelerator to be used in executing the application from among the accelerators that are in a standby state and that are subordinate to the one physical CPU.

5. The information processing device according to claim 4, characterized in that the control unit acquires information on the number of accelerators to be used in executing the application, and if the number is less than or equal to the number of accelerators in a standby state that are subordinate to the one physical CPU, selects the accelerator to be used in executing the application from the accelerators in the standby state.

6. An information processing device including a plurality of physical CPUs, each having a plurality of CPU (Central Processing Unit) cores, selecting, from one physical CPU of the plurality of physical CPUs, two or more CPU cores that are to execute an application executed using the two or more CPU cores of the plurality of CPU cores; Executing the application using the selected two or more CPU cores; An information processing method comprising:

Images