JP2018028769A - Conversion program and conversion method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a conversion program capable of converting identification information of a processor to be allocated to an application without changing the application.SOLUTION: A conversion part 16 acquires setting information D1 including first identification information of a first processor from an application 17. The conversion part 16 determines second identification information of a second processor to be allocated to the application 17 based on arrangement of processors 11a, 11b, 11c, 11d, 12a, 12b, 12c and 12d and usage situation of the processors 11a, 11b, 11c, 11d, 12a, 12b, 12c and 12d. The conversion part 16 notifies an OS 15 of conversion information D2 in which the first identification information and the second identification information are associated with each other.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a conversion program and a conversion method.

  Currently, information processing apparatuses are used to execute various processes. In an information processing apparatus, a processor and a memory may be mounted by a technique called NUMA (Non-Uniform Memory Access). In NUMA, a plurality of nodes including a plurality of processors and memories are provided, and each processor can access a memory (local memory) on its own node and a memory (remote memory) on another node. The processor can access local memory faster than remote memory.

  For example, in a system in which a plurality of nodes are connected by an interconnect, there is a proposal that a hypervisor determines a physical CPU that executes a logical CPU (Central Processing Unit) allocated to a virtual machine based on access performance from the logical CPU to the physical memory. is there.

  In addition, upon receiving a request indicating characteristics related to a virtual machine, the system determines the number of virtual NUMA nodes of the virtual machine based on the characteristics and the physical topology of the system, and instantiates a virtual machine having the determined number of virtual NUMA nodes There is also a proposal.

  Also, when the virtual machine boots, the virtualizer groups the guest physical memory and guest virtual processors into virtual nodes, then changes the host physical memory behind the virtual nodes to ensure that the physical processors appropriate for the virtual processors in the nodes There are also proposals to provide a processor.

  Further, there is a proposal of a computer system that assigns a logical processor so as to extract the performance of a physical processor according to the dependency relationship between this process and a process that has already been assigned a logical processor when assigning a logical processor to a new process.

International Publication No. 2014/141419 Special table 2012-521611 gazette JP 2006-178933 A JP 2006-24180 A

  Different information processing apparatuses may have different NUMA structures (for example, the number of processors in one node and identification information allocated to processors on each node). An application executed by the information processing apparatus may be created in consideration of the NUMA structure of the information processing apparatus. For this reason, even if an application that has been operating properly in one information processing apparatus is executed by another information processing apparatus, problems such as inability to exhibit the expected performance or malfunction. Although it is conceivable to modify the application in advance in anticipation of deployment to another information processing apparatus, it is difficult to know the NUMA structure of the information processing apparatus at the deployment destination before deployment. For this reason, there is a problem that the user may be forced to correct the setting after the application is deployed.

  In one aspect, an object of the present invention is to enable conversion of identification information of a processor assigned to an application without changing the application.

  In one aspect, a conversion program is provided. This conversion program acquires setting information including first identification information of a first processor from an application to a computer having a plurality of processors, and based on the arrangement of the plurality of processors and the usage status of the plurality of processors, 2nd identification information of the 2nd processor allocated to 2 is determined, and the conversion information which matched 1st identification information and 2nd identification information is notified to the operating system of a computer.

  In one aspect, a conversion program is provided. The conversion program converts a computer having a plurality of processors in association with the first identification information of the first processor included in the application setting information and the second identification information of the second processor to be assigned to the application. Information is acquired, and based on the conversion information, a second processor corresponding to the second identification information is assigned to the application instead of the first identification information.

  In one aspect, a conversion method is provided. In this conversion method, a computer having a plurality of processors acquires setting information including the first identification information of the first processor from the application, and based on the arrangement of the plurality of processors and the usage status of the plurality of processors, the application 2nd identification information of the 2nd processor assigned to 2 is determined, the conversion information which matched the 1st identification information and the 2nd identification information is notified to the operating system of a computer, and it is converted into conversion information by an operating system. Based on this, instead of the first identification information, the second processor corresponding to the second identification information is assigned to the application.

  In one aspect, processor identification information assigned to an application can be converted without changing the application.

It is a figure which shows the information processing apparatus of 1st Embodiment. It is a figure which shows the hardware example of the server of 2nd Embodiment. It is a figure which shows the example of software of 2nd Embodiment. It is a figure which shows the example of the conversion table of 2nd Embodiment. It is a flowchart which shows the example of application starting of 2nd Embodiment. It is a figure which shows the example of conversion of the CPU number of 2nd Embodiment. It is a figure which shows the comparative example of allocation of CPU number. It is a figure which shows the example of software of 3rd Embodiment. It is a figure which shows the example of the process table of 3rd Embodiment. It is a flowchart which shows the example of application starting of 3rd Embodiment. 12 is a flowchart illustrating an example of CPU resetting according to the third embodiment. It is a flowchart which shows the example of CPU allocation change of 3rd Embodiment. It is a figure which shows the example of software of 4th Embodiment. It is a figure which shows the example of the conversion table of 4th Embodiment. It is a flowchart which shows the example of application starting of 4th Embodiment. It is a figure which shows the example of software of 5th Embodiment. It is a figure which shows the example of conversion of CPU number of 5th Embodiment. It is a figure which shows the comparative example of allocation of CPU number in a virtual machine.

Hereinafter, the present embodiment will be described with reference to the drawings.
[First Embodiment]
FIG. 1 is a diagram illustrating the information processing apparatus according to the first embodiment. The information processing apparatus 10 includes a plurality of processors and a plurality of memories. Here, the memory is, for example, a RAM (Random Access Memory). The processor is, for example, a CPU. The processor may also include a set of multiple processors (multiprocessor). The information processing apparatus 10 may be called a computer. The processor and memory are implemented using NUMA technology. The information processing apparatus 10 includes nodes 11 and 12.

  The node 11 includes processors 11a, 11b, 11c, 11d and a memory 11e. The node 12 includes processors 12a, 12b, 12c, 12d and a memory 12e. The nodes 11 and 12 are hardware of the information processing apparatus 10. Nodes 11 and 12 may also be called NUMA nodes.

  Here, the identification information of the processor 11a is “1” (ID (IDentifier) = 1). The identification information of the processor 11b is “2”. The identification information of the processor 11c is “3”. The identification information of the processor 11d is “4”. The identification information of the processor 12a is “5”. The identification information of the processor 12b is “6”. The identification information of the processor 12c is “7”. The identification information of the processor 12d is “8”.

  The information processing apparatus 10 executes an operating system (OS) 15, a conversion unit 16, and an application 17 using the hardware described above. The OS 15, the conversion unit 16, and the application 17 are software of the information processing apparatus 10. The OS 15 is an OS of the information processing apparatus 10 and is executed using the nodes 11 and 12. The application 17 executes user business processing.

  The conversion unit 16 generates conversion information for converting the identification information of the processor assigned to the application 17. The conversion unit 16 is executed by any processor belonging to the nodes 11 and 12. The conversion unit 16 is implemented as a function outside the application 17 (for example, a dynamic shared library or a scheduler). The conversion unit 16 executes the following process in order to determine a processor to be used for executing the application 17.

  The conversion unit 16 acquires the setting information D1 including the first identification information of the first processor from the application 17. For example, the setting information D1 is information given in advance to the application 17 in order to tune the operation method of the application 17. For example, the setting information D1 includes IDs = 3, 4, 5, and 6 of the processors 11c, 11d, 12a, and 12b as the first identification information of the first processor.

  The conversion unit 16 determines second identification information of the second processor to be assigned to the application 17 based on the arrangement of the plurality of processors and the usage status of the plurality of processors. For example, the conversion unit 16 assigns processors belonging to the same node to the application 17 based on the arrangement of a plurality of processors in the nodes 11 and 12. This is because the processing speed can be increased if each processor accesses the common local memory. Further, the conversion unit 16 assigns a processor to the application 17 so that the load on the node 11 and the load on the node 12 are not biased.

  For example, the setting information D1 includes processor IDs = 3, 4, 5, and 6. The processors 11 c and 11 d identified by ID = 3 and 4 belong to the node 11. The processors 12 a and 12 b identified by ID = 5 and 6 belong to the node 12. The processors 11c, 11d, 12a, and 12b belong to the nodes 11 and 12, respectively. Therefore, the conversion unit 16 assigns a processor from either the node 11 or the node 12. For example, when the load on the node 12 is larger than the load on the node 11, the conversion unit 16 determines to allocate the processors 11 a, 11 b, 11 c, and 11 d belonging to the node 11 to the application 17. In this case, the second identification information is ID = 1, 2, 3, 4.

  The conversion unit 16 notifies the OS 15 of the information processing apparatus 10 of conversion information D2 in which the first identification information and the second identification information are associated with each other. In the above example, the first identification information is ID = 3, 4, 5, 6. The second identification information is ID = 1, 2, 3, 4. That is, the conversion information D2 indicates that the processor ID = 3, 4, 5, 6 is converted to ID = 1, 2, 3, 4.

  The OS 15 acquires conversion information D2 from the conversion unit 16. Based on the conversion information D2, the OS 15 assigns a second processor corresponding to the second identification information to the application 17 instead of the first identification information. In the case of the above example, the OS 15 assigns the processors 11a, 11b, 11c, and 11d corresponding to ID = 1, 2, 3, 4, and 4 to the application 17 instead of the processor IDs = 3, 4, 5, and 6.

  According to the information processing apparatus 10, the processor identification information can be converted without changing the application 17. Specifically, the conversion unit 16 notifies the OS 15 of conversion information D2 based on the setting information D1 acquired from the application 17. For this reason, the application 17 does not need to be aware of the change of the setting information D1.

  In particular, in the application 17 created in consideration of NUMA, processor identification information used to execute the application 17 is defined in advance. However, the predefined identification information does not necessarily match the NUMA structure (NUMA structure) of the information processing apparatus 10 that is actually executed. For example, a processor of identification information defined in advance may not exist on the corresponding information processing apparatus. Further, there is a possibility that the processor group corresponding to the combination of the identification information defined in advance is not on the same node. Although it is conceivable to modify the application in advance in anticipation of deployment to another information processing apparatus, it is difficult to know the NUMA structure of the information processing apparatus at the deployment destination before deployment. For this reason, there is a problem that the user may be forced to correct the setting of the application after the application is deployed.

  The conversion unit 16 determines a processor to be assigned to the application 17 according to the NUMA implementation in the information processing apparatus 10. For this reason, the information processing apparatus 10 can exhibit the performance expected with respect to the application 17 created in consideration of NUMA and can operate appropriately. Further, it is not necessary to force the user to change the application 17, and the burden on the user can be reduced.

Next, the above function will be described in more detail by exemplifying a server computer (sometimes simply referred to as a server) that executes an application.
[Second Embodiment]
FIG. 2 is a diagram illustrating a hardware example of the server according to the second embodiment. The server 100 is mounted with a CPU and RAM using NUMA technology. The server 100 includes nodes 101 and 102, an HDD 103, an image signal processing unit 104, an input signal processing unit 105, a media reader 106, and a communication interface 107. Each unit is connected to the bus of the server 100.

  The node 101 includes CPUs 11p, 12p,... And RAM 1m. The node 102 includes CPUs 21p, 22p,... And RAM 2m. Nodes 101 and 102 may be referred to as NUMA nodes.

CPU 11p, 12p,... And CPU 21p, 22p,.
The RAMs 1m and 2m are main storage devices of the server 100. The RAMs 1m and 2m temporarily store at least a part of the OS programs and application programs. The RAM 1m is a local memory of the CPUs 11p, 12p,. The RAM 1m is a remote memory of the CPUs 21p, 22p,. The RAM 2m is a local memory of the CPUs 21p, 22p,. A RAM 2m is a remote memory of the CPUs 11p, 12p,. The server 100 may further include one or more nodes in addition to the nodes 101 and 102.

  The HDD 103 is an auxiliary storage device of the server 100. The HDD 103 magnetically writes and reads data to and from the built-in magnetic disk. The HDD 103 stores an OS program, application programs, and various data. The server 100 may include other types of auxiliary storage devices such as flash memory and SSD (Solid State Drive), or may include a plurality of auxiliary storage devices.

  The image signal processing unit 104 outputs an image to the display 21 connected to the server 100 in accordance with an instruction from each CPU. As the display 21, a CRT (Cathode Ray Tube) display, a liquid crystal display, or the like can be used.

  The input signal processing unit 105 acquires an input signal from the input device 22 connected to the server 100 and outputs it to each CPU. As the input device 22, for example, a pointing device such as a mouse or a touch panel, a keyboard, or the like can be used.

  The medium reader 106 is a device that reads programs and data recorded on the recording medium 23. As the recording medium 23, for example, a magnetic disk such as a flexible disk (FD) or an HDD (Hard Disk Drive), an optical disk such as a CD (Compact Disc) or a DVD (Digital Versatile Disc), a magneto-optical disk (MO) -Optical disk). Further, as the recording medium 23, for example, a non-volatile semiconductor memory such as a flash memory card can be used. For example, the medium reader 106 stores programs and data read from the recording medium 23 in the RAMs 1m and 2m or the HDD 103 in accordance with instructions from each CPU.

  The communication interface 107 communicates with other devices via the network 24. The communication interface 107 may be a wired communication interface or a wireless communication interface.

  FIG. 3 is a diagram illustrating an example of software according to the second embodiment. The server 100 includes a storage unit 110, an OS kernel 120, a CPU name conversion unit 130, and an application 140. The storage unit 110 is realized as a storage area secured in the RAM 1m, 2m or the HDD 103. The OS kernel 120 and the CPU name conversion unit 130 are realized by at least one of the CPUs 11p, 12p,... And the CPUs 21p, 22p,. As will be described later, the application 140 is executed using a CPU group and a RAM belonging to one node as much as possible.

  The storage unit 110 stores a conversion table 111. The conversion table 111 is a table used for processing by the CPU name conversion unit 130. The conversion table 111 is information in which the correspondence between the conversion source CPU name and the conversion destination CPU name is recorded. For example, the user can create the conversion table 111 in advance and store it in the storage unit 110.

  Here, the CPU name corresponds to the identification information of the CPU. In the second embodiment, the CPU name is a CPU number (CPU number). The CPU number is an integer in ascending order starting from “0”. The CPU number is assigned to each CPU using a predetermined algorithm by the CPU firmware and OS. That is, the CPU number assignment rule may differ depending on the server computer. For example, a predetermined number of consecutive numbers may belong to the same node, or a predetermined number of discontinuous numbers may belong to the same node.

The OS kernel 120 is an OS kernel of the server 100. The OS kernel 120 assigns a CPU to the application 140 executed on the server 100.
The CPU name conversion unit 130 detects a predetermined system call (system call for CPU setting) when the application 140 is activated, and accepts designation of a CPU number from the application 140. The CPU name conversion unit 130 converts the CPU number based on the conversion table 111 stored in the storage unit 110 and notifies the OS kernel 120 of it.

  The application 140 is software that performs processing related to a user's business. The application 140 is created in consideration of NUMA, and a CPU number used for executing the application 140 is defined in advance. However, the predefined CPU number does not always match the NUMA structure of the server that is actually executed. For example, a predefined CPU number may not exist on the corresponding server, or a predefined combination of CPU numbers may not exist on the same node. In the following description, “application” may be abbreviated as “application”.

  FIG. 4 is a diagram illustrating an example of a conversion table according to the second embodiment. The conversion table 111 is stored in the storage unit 110. The conversion table 111 includes items of an application designated CPU number and a converted CPU number.

  In the application designation CPU number item, the CPU number designated by the application 140 is registered. The post-conversion CPU number is registered with the post-conversion CPU number. For example, in the conversion table 111, information indicating that the application designated CPU number is “0” and the converted CPU number is “2” is registered. This indicates that when the CPU number “0” is designated by the application 140, the CPU number “2” is converted.

  Similarly, the combination of the application designated CPU number and the CPU number is registered in advance in the conversion table 111 for other CPU numbers. In particular, the CPU number of the CPU on the same node is registered in advance in the item of the converted CPU number.

Next, a processing procedure at the time of application activation by the server 100 will be described.
FIG. 5 is a flowchart illustrating an application activation example according to the second embodiment. Hereinafter, the process illustrated in FIG. 5 will be described in order of step number.

  (S11) The CPU name conversion unit 130 receives an input of a combination of the application designation CPU number and the converted CPU number by the user, and creates the conversion table 111. The CPU name conversion unit 130 stores the created conversion table 111 in the storage unit 110. The CPU name conversion unit 130 creates a conversion table for each application, and stores the created conversion table in the storage unit 110 in association with the identification information of the application. The conversion table 111 is associated with the identification information of the application 140.

  (S12) The CPU name conversion unit 130 detects a system call for performing CPU setting when the application is activated. For example, when the application 140 is activated, the CPU name conversion unit 130 detects a system call for setting a CPU used to execute the application 140.

(S13) The CPU name conversion unit 130 hooks a system call.
(S14) The CPU name conversion unit 130 converts the CPU name of the CPU setting information included in the system call based on the conversion table 111 stored in the storage unit 110. For example, the conversion table 111 includes information indicating that the application designated CPU number “0” is converted to the converted CPU number “2”. For this reason, the CPU name conversion unit 130 converts the CPU number “0” included in the CPU setting information into the CPU number “2”. The CPU name conversion unit 130 similarly converts other CPU numbers included in the CPU setting information based on the conversion table 111.

  (S15) The CPU name conversion unit 130 notifies the OS of the converted CPU name. Specifically, the CPU name conversion unit 130 notifies the OS kernel 120 of the CPU setting information converted in step S14. The OS kernel 120 assigns the CPU to the application 140 based on the CPU setting information received from the CPU name conversion unit 130.

As a result, the OS kernel 120 can appropriately allocate the CPU on the same node to the application 140.
FIG. 6 is a diagram illustrating a conversion example of the CPU number according to the second embodiment. FIG. 6A illustrates a case where a CPU number that spans multiple nodes is designated by the application 140. For example, it is assumed that the node 101 has a CPU group P1 including 10 CPUs. The CPU numbers belonging to the CPU group P1 are “0” to “9” (indicated as “0-9” in the figure, and so on). Further, it is assumed that the node 102 has a CPU group P2 including 10 CPUs. The CPU numbers belonging to the CPU group P2 are “10” to “19”. Further, it is assumed that the conversion table 111 is defined to convert each of the CPU numbers “8, 9, 10, 11” to the CPU numbers “4, 5, 6, 7”.

  In this case, it is assumed that the application 140 issues a system call including the setting of the CPU number “8, 9, 10, 11” at the time of activation. Of the four CPUs corresponding to the CPU numbers “8, 9, 10, 11”, the CPU with the CPU number “8, 9” belongs to the node 101. The CPU with the CPU number “10, 11” belongs to the node 102.

  The CPU name conversion unit 130 hooks the system call and converts the CPU number “8, 9, 10, 11” into the CPU number “4, 5, 6, 7” based on the conversion table 111. The CPU name conversion unit 130 notifies the converted OS setting information to the OS kernel 120 (the OS kernel 120 is not shown in FIG. 6). The OS kernel 120 allocates four CPUs corresponding to the CPU numbers “4, 5, 6, 7” to the application 140 based on the notification from the CPU name conversion unit 130. The four CPUs all belong to the node 101.

  FIG. 6B illustrates a case where a failure occurs in a certain CPU (a CPU having a CPU number “9” as an example) on the node 101. In this case, the server 100 stops the use of the CPU number “9” in the node 101 and performs the degenerate operation. It is assumed that the conversion table 111 is defined so that each of the CPU numbers “6, 7, 8, 9” is converted into the CPU numbers “5, 6, 7, 8”.

  At this time, it is assumed that the application 140 issues a system call including the setting of the CPU number “6, 7, 8, 9” at the time of activation. In the example of FIG. 6B, the CPU number “9” cannot be used due to a failure. The CPU name conversion unit 130 hooks the system call and converts the CPU number “6, 7, 8, 9” into the CPU number “5, 6, 7, 8” based on the conversion table 111. The CPU name conversion unit 130 notifies the OS kernel 120 of the CPU setting information after the conversion. The OS kernel 120 assigns four CPUs corresponding to the CPU numbers “5, 6, 7, 8” to the application 140 based on the notification from the CPU name conversion unit 130. The four CPUs all belong to the node 101.

  In this way, the CPU name conversion unit 130 determines the CPU to be assigned to the application 140 from the single node 101, thereby improving the processing performance of the application 140 and allowing the application 140 to operate appropriately.

The function of the CPU name conversion unit 130 is useful when the NUMA configuration of the server that executes the application 140 can change.
FIG. 7 is a diagram illustrating a comparative example of CPU number assignment. For example, the server 200 does not have the function of the CPU name conversion unit 130. The server 200 includes a node 201 that includes a CPU and a RAM, and a node 202 that includes a CPU and a RAM. Each of the nodes 201 and 202 has 12 CPUs. The CPU numbers belonging to the CPU group P3 of the node 201 are “0” to “11”. The CPU numbers belonging to the CPU group P4 of the node 202 are “12” to “23”. The application 240 on the server 200 is set to fix the CPU to be executed, and CPU numbers “8, 9, 10, 11” are defined in advance.

  For example, consider moving the application 240 to another server 300 (changing the deployment destination) and operating it (the case of FIG. 7A). The server 300 has nodes 301 and 302. Each of the nodes 301 and 302 has 10 CPUs. The CPU numbers belonging to the CPU group P5 of the node 301 are “0” to “9”. The CPU numbers belonging to the CPU group P6 of the node 302 are “10” to “19”.

  On the other hand, in the application 240, CPU numbers “8, 9, 10, 11” are defined in advance. When the OS kernel of the server 300 determines the CPU to be assigned according to the definition of the application 240, the CPU that executes the application 240 straddles the nodes 301 and 302. As described above, in NUMA, it is possible to speed up processing by accessing local memory rather than accessing remote memory. Conversely, when the CPU accesses the remote memory, the expected processing performance cannot be exhibited. For this reason, when a plurality of CPUs executing the application 240 straddle a plurality of nodes, the processing performance cannot be sufficiently exhibited.

  Next, consider a case where a hardware error has occurred in the server 200 and the CPU with the CPU number “9” (denoted as “CPU9” in the figure) is degenerated (case in FIG. 7B). In this case, the OS kernel of the server 200 cannot assign the CPU with the CPU number “9” in response to the designation of the CPU number “8, 9, 10, 11” on the application 240 side. For this reason, the OS kernel arbitrarily determines a CPU to be substituted for the CPU with the CPU number “9” and assigns it to the application 240. The OS kernel may assign an alternative CPU from the node 202 to the application 240. In this case as well, as in FIG. 7A, the expected processing performance cannot be exhibited.

  In each case illustrated in FIG. 7A and FIG. 7B, it is conceivable that the user changes the designation of the CPU by the application 240 every time the arrangement of the CPU on the node is changed. However, if such a work is forced on the user, the work burden on the user increases.

  On the other hand, in the server 100, the CPU name conversion unit 130 determines a CPU to be assigned to the application 140 according to the NUMA implementation in the server 100 based on the conversion table 111. For this reason, the server 100 can exhibit the performance expected with respect to the application 140 created in consideration of NUMA and can operate appropriately. Further, the user only needs to set the conversion table 111, and does not need to change the application 140. Since it is not necessary to force the user to change the application 140, the burden on the user can be reduced.

[Third Embodiment]
Hereinafter, a third embodiment will be described. Items that differ from the second embodiment described above will be mainly described, and descriptions of common items will be omitted.

  In the second embodiment, the server 100 determines a CPU to be assigned to the application 140 when the application 140 is activated based on the conversion table 111. On the other hand, it is also conceivable to dynamically change the CPU assigned to the application 140 at the time of activation and after activation. This is because the CPU and the load on the CPU that can be used in each node can vary depending on the operation. Therefore, in the third embodiment, a function of dynamically changing the CPU assigned to the application 140 is provided.

  Here, in the third embodiment, a server 100 a is used instead of the server 100. The hardware of the server 100a is the same as that of the server 100 of the second embodiment illustrated in FIG. For this reason, the hardware of the server 100a is indicated using the same symbols and names as the server 100.

  FIG. 8 is a diagram illustrating an example of software according to the third embodiment. The server 100a includes a storage unit 110, an OS kernel 120, an application 140, and a scheduler 150. The storage unit 110 is realized as a storage area secured in the RAM 1m, 2m or the HDD 103. The OS kernel 120 and the scheduler 150 are realized by at least one of the CPUs 11p, 12p,... And the CPUs 21p, 22p,. As will be described later, the application 140 is executed using a CPU group and a RAM belonging to one node as much as possible.

  The server 100 a is different from the server 100 in that the process table 112 is stored in the storage unit 110 instead of the conversion table 111. The server 100a is different from the server 100 in that it includes a scheduler 150 instead of the CPU name conversion unit 130. In addition, the storage unit 110 stores CPU configuration information indicating the CPU number of the server 100a and the correspondence between the CPU number and the node to which the CPU corresponding to the CPU number belongs.

  The process table 112 is a table in which information for identifying a process to be converted into a CPU number by the scheduler 150 is recorded. The process table 112 is created by the scheduler 150 and stored in the storage unit 110.

  The scheduler 150 resets the CPU number for the process of the application 140. The scheduler 150 determines the CPU number of the CPU to be assigned to the application 140 based on the placement of each CPU on the node and the usage status of each CPU. The scheduler 150 notifies the OS kernel 120 of the determined CPU number.

  In addition, the scheduler 150 collects information on the CPU configuration information, the current CPU allocation status of each application, and the CPU and RAM loads in each node, and stores them in the storage unit 110.

The OS kernel 120 assigns a CPU to the application 140 based on the CPU number notified from the scheduler 150.
FIG. 9 illustrates an example of a process table according to the third embodiment. The process table 112 is stored in the storage unit 110. The process table 112 includes items of process ID and designated CPU number.

  In the process ID item, the process ID of the process of the application 140 is registered. The CPU number designated by the application 140 is registered in the designated CPU number field. For example, information that the process ID is “10203” and the designated CPU number is “0, 1” is registered in the process table 112. This indicates that the CPU number designated by the application 140 corresponding to the process with the process ID “10203” is “0, 1”.

Next, a processing procedure at the time of application activation by the server 100a will be described.
FIG. 10 is a flowchart illustrating an application activation example according to the third embodiment. In the following, the process illustrated in FIG. 10 will be described in order of step number.

  (S21) The scheduler 150 acquires CPU information when the application is activated. For example, when starting the application 140, the server 100a can start the application 140 by using the following start command.

"# Set-cpu-run-cpu <cpu name list>command"
Here, a list of designated CPU numbers is inserted in the place of “<cpu name list>”. In addition, an arbitrary command for starting the application 140 is inserted in the place of “command”. The scheduler 150 obtains a list of designated CPU numbers input by the start command.

  (S22) The scheduler 150 records the CPU information (that is, the list of designated CPU numbers) acquired in step S21 for the process ID of the application 140. For example, the scheduler 150 registers the designated CPU number “0, 1” for the process ID “10203” of the application 140 in the process table 112 stored in the storage unit 110. The OS kernel 120 sets the CPU to be assigned to the application 140 according to the internal logic after the application 140 is started.

  (S23) The scheduler 150 resets the CPU to be assigned to the application 140 in accordance with the CPU arrangement status for each node and the CPU load of each node of the server 100a. The scheduler 150 notifies the OS kernel 120 of the result of the CPU resetting. Details of the processing in step S23 will be described later.

The OS kernel 120 changes the CPU assignment to the application 140 based on the CPU reset result received from the scheduler 150.
FIG. 11 is a flowchart illustrating an example of CPU resetting according to the third embodiment. In the following, the process illustrated in FIG. 11 will be described in order of step number. The following procedure corresponds to step S23 in FIG.

  (S31) The scheduler 150 acquires host information. The host information includes information regarding the load on the server 100a. The host information includes information indicating the configuration information of the CPU in the server 100a (which node each CPU belongs to). Further, the host information includes information on the CPU number of the CPU currently assigned to each application.

  (S32) The scheduler 150 determines whether all processes recorded in the process table 112 have been confirmed. If all the processes have been confirmed, the process is terminated (wait until the next CPU reset timing). If not all processes have been confirmed, the process proceeds to step S33.

(S33) The scheduler 150 selects one process (process ID) from the process table 112.
(S34) The scheduler 150 inquires about the CPU and host information assigned to the process selected in step S33. For example, the scheduler 150 can inquire about the CPU assigned to the relevant process by inquiring the CPU number of the CPU assigned to the relevant process from the OS kernel 120. Further, the scheduler 150 checks the load of each CPU by inquiring host information.

  (S35) The scheduler 150 changes the CPU number conversion destination for the application 140, and notifies the OS kernel 120 of the change result. Details of the processing in step S35 will be described later.

In addition, the scheduler 150 may execute the above steps S31 to S35 periodically (at a predetermined cycle).
FIG. 12 is a flowchart illustrating an example of CPU allocation change according to the third embodiment. In the following, the process illustrated in FIG. 12 will be described in order of step number. The following procedure corresponds to step S35 in FIG.

  (S41) The scheduler 150 determines whether an application-specified CPU exists. If an application-designated CPU exists, the process proceeds to step S42. If there is no application-designated CPU, the process proceeds to step S44. Here, the scheduler 150 collates the CPU configuration information (information indicating the CPU number and the affiliation of the CPU number with the node) in the process table 112 and the server 100a to determine whether or not the application-designated CPU exists. judge. As described above, the CPU configuration information is collected by the scheduler 150 and stored in the storage unit 110. The scheduler 150 can acquire the CPU number of the CPU designated by the application by specifying the designated CPU number corresponding to the process ID of the application 140 on the process table 112. When there are a plurality of application-designated CPUs, the scheduler 150 advances the process to step S42 when all the CPUs exist on the server 100a. On the other hand, the scheduler 150 advances the process to step S44 when at least one CPU does not exist on the server 100a.

  (S42) The scheduler 150 determines whether all CPUs designated by the application are on the same node. If all the CPUs are on the same node, the process proceeds to step S43. If all the CPUs are not on the same node, the process proceeds to step S44. For example, the scheduler 150 can determine whether all CPUs designated by the application are on the same node based on the above-described CPU configuration information.

  (S43) The scheduler 150 determines whether any one of the CPUs designated by the application has a high load. If any one of the CPUs designated by the application has a high load, the process proceeds to step S46. If none of the CPUs designated by the application is loaded, the process ends. In the latter case, the CPU number is not converted. That is, the OS kernel 120 assigns the CPU group designated by the application 140 to the application 140 as it is. Here, the scheduler 150 can determine whether or not the corresponding CPU is heavily loaded, for example, depending on whether or not the CPU busy rate exceeds a predetermined threshold. When the CPU busy rate exceeds the threshold, the CPU is heavily loaded. If the CPU busy rate does not exceed the threshold, the CPU is not heavily loaded.

  (S44) The scheduler 150 determines whether there is a node that can supply the number of CPUs required by the application 140. If there is no node that can supply the number of CPUs required by the application 140, the process proceeds to step S45. If there is a node that can supply the number of CPUs required by the application 140, the process proceeds to step S46. Here, the scheduler 150 can acquire the number of CPUs required by the application 140 by counting the number of designated CPU numbers corresponding to the process ID of the application 140 on the process table 112. Further, the number of CPUs possessed by each node can be obtained from the CPU configuration information stored in the storage unit 110. A node including the required number of CPUs is a node that can provide the number of CPUs required by the application 140.

  (S45) The scheduler 150 acquires a CPU list on the host (that is, on the server 100a). The CPU list is a list of CPU numbers. Then, the process proceeds to step S48.

  (S46) The scheduler 150 selects a node having free CPU / RAM among the nodes 101 and 102 of the server 100a. For example, the scheduler 150 selects a node having a CPU and RAM that are not used to execute any application. Further, for example, the scheduler 150 may select a node whose CPU and RAM loads are lower than a predetermined threshold. If a plurality of nodes are candidates for selection, the scheduler 150 may select a node having the lowest CPU and RAM load among the plurality of candidate nodes. The aforementioned busy rate can be considered as a load on the CPU. As the load on the RAM, the usage rate of the storage area of the RAM can be considered. The scheduler 150 may evaluate the load in units of nodes by weighting and adding the CPU busy rate and the RAM usage rate. For example, the scheduler 150 may determine a node to be used for selection of a CPU to which a node having a minimum node unit load is allocated.

(S47) The scheduler 150 acquires a CPU list on the node selected in step S46. Then, the process proceeds to step S48.
(S48) The scheduler 150 sorts the CPU numbers in the acquired CPU list in ascending order of CPU load corresponding to the CPU numbers.

  (S49) The scheduler 150 selects a CPU number of a CPU with a low load based on the sorting result. For example, the scheduler 150 selects a CPU number to be assigned to the application 140 by the number of CPUs required by the application 140 in order from the smallest load of the corresponding CPU.

  (S50) The scheduler 150 changes the CPU number assigned to the application 140 to the CPU number selected in step S49 (changes the conversion destination CPU number). The scheduler 150 notifies the OS kernel 120 of the process ID of the application 140, the designated CPU number, and the changed conversion destination CPU number.

In response to the notification from the scheduler 150, the OS kernel 120 changes the CPU allocation to the application 140.
As described above, the CPU 150 can be dynamically changed with respect to the application 140 by using the scheduler 150. At this time, the scheduler 150 determines a conversion destination CPU number so that CPUs on the same node are preferentially assigned to the application 140. Thereby, the processing performance of the application 140 created in consideration of NUMA can be appropriately exhibited, and the application 140 can be operated.

  Further, the scheduler 150 can prevent a processing load from being biased to a specific node by setting a node having the smallest load as an extraction target of a CPU to be assigned to the application 140 in accordance with the load of each node. Further, the scheduler 150 can select the number of CPUs requested by the application 140 in order from the lowest load in the same node, and thereby level the CPU load in the node. Thereby, the efficiency of resource utilization in the server 100a can be improved. As a result, the processing of a plurality of applications executed on the server 100a can be accelerated. Furthermore, it is not necessary to force the user to change the application 140, and the burden on the user can be reduced.

[Fourth Embodiment]
Hereinafter, a fourth embodiment will be described. Items different from the second and third embodiments described above will be mainly described, and description of common items will be omitted.

  In the third embodiment, the scheduler 150 notifies the OS kernel 120 of the conversion destination CPU number for each process ID. On the other hand, it is also conceivable to control the conversion of the CPU number by the OS kernel 120 by rewriting the conversion table of the CPU number in the OS kernel 120 from the outside. Therefore, in the fourth embodiment, a function for rewriting the conversion table in the OS kernel 120 is provided.

  Here, in the fourth embodiment, a server 100b is used instead of the server 100a. The hardware of the server 100b is the same as that of the server 100 of the second embodiment illustrated in FIG. For this reason, the hardware of the server 100b is indicated using the same symbols and names as the server 100.

  FIG. 13 is a diagram illustrating an example of software according to the fourth embodiment. The server 100b includes a storage unit 110, an OS kernel 120, an application 140, and a scheduler 160. The storage unit 110 is realized as a storage area secured in the RAM 1m, 2m or the HDD 103. The OS kernel 120 and the scheduler 160 are realized by at least one of the CPUs 11p, 12p,... And the CPUs 21p, 22p,. As will be described later, the application 140 is executed using a CPU group and a RAM belonging to one node as much as possible.

  The server 100b is different from the server 100a in that the conversion table 113 is stored in the storage unit 110 in addition to the process table 112. The server 100b is different from the server 100a in that the server 100b includes a scheduler 160 instead of the scheduler 150.

  The conversion table 113 is information used for CPU number conversion by the OS kernel 120. The conversion table 113 is created by the scheduler 160 and stored in the storage unit 110.

  The scheduler 160 resets the CPU number for the process of the application 140. The scheduler 160 determines the CPU number of the CPU assigned to the application 140 based on the arrangement of each CPU on the node and the usage status of each CPU. The scheduler 160 registers the determined CPU number in the conversion table 113 in association with the process ID and the conversion source CPU number (the CPU number specified by the application 140).

  In addition, the scheduler 160 collects information on the CPU configuration information, the current CPU allocation status of each application, and the CPU and RAM loads in each node, and stores them in the storage unit 110 or other storage units.

The OS kernel 120 assigns a CPU to the application 140 based on the conversion table 113 stored in the storage unit 110.
FIG. 14 is a diagram illustrating an example of a conversion table according to the fourth embodiment. The conversion table 113 is stored in the storage unit 110. The conversion table 113 includes items of process ID, conversion source CPU number, and conversion destination CPU number.

  In the process ID item, the process ID of the process of the application 140 is registered. The CPU number designated by the application 140 is registered in the item of conversion source CPU number. In the item of conversion destination CPU number, the conversion destination CPU number for the conversion source CPU number is registered.

  For example, information indicating that the process ID is “10203”, the conversion source CPU number is “0, 1”, and the conversion destination CPU number is “2, 3” is registered in the conversion table 113. This indicates that the conversion source CPU number designated by the application 140 corresponding to the process with the process ID “10203” is “0, 1”. Further, it indicates that the conversion destination CPU number is “2, 3”. That is, the CPU corresponding to the conversion destination CPU number “2, 3” is assigned to the process ID “10203”. By including the process ID in the conversion table 113, the OS kernel 120 can appropriately identify the application to be converted into the CPU number even when there are a plurality of applications to be executed on the server 100b.

Next, a processing procedure at the time of application activation by the server 100b will be described.
FIG. 15 is a flowchart illustrating an application activation example according to the fourth embodiment. In the following, the process illustrated in FIG. 15 will be described in order of step number.

  (S51) The scheduler 160 acquires CPU information when the application is activated. For example, as in the third embodiment, when starting the application 140, the server 100b can start the application 140 using the following start command.

"# Set-cpu-run-cpu <cpu name list>command"
The scheduler 160 obtains a list of designated CPU numbers input by the start command.

  (S52) The scheduler 160 records the CPU information (that is, a list of designated CPU numbers) acquired in step S51 for the process ID of the application 140. For example, the scheduler 160 registers the designated CPU number “0, 1” for the process ID “10203” of the application 140 in the process table 112 stored in the storage unit 110. The OS kernel 120 sets the CPU to be assigned to the application 140 according to the internal logic after the application 140 is started.

  (S53) The scheduler 160 creates the conversion table 113 in the OS kernel 120 for the application 140. Specifically, the scheduler 160 creates the conversion table 113 and registers it in the storage unit 110 accessible from the OS kernel 120 and the scheduler 160. For example, the scheduler 160 sets the set value of the conversion source CPU number in the conversion table 113 as the designated CPU number corresponding to the corresponding process ID in the process table 112. Further, the scheduler 160 may use the initial setting value of the conversion destination CPU number in the conversion table 113 as the CPU number of the CPU assigned to the application 140 by the OS kernel 120 in step S52.

  (S54) The scheduler 160 resets the CPU number assigned to the application 140 according to the procedure of FIGS. 11 and 12 (CPU resetting). However, the scheduler 160 updates the entry of the conversion destination CPU number in the conversion table 113 created in step S53 according to the reset result. The OS kernel 120 changes the CPU allocation to the application 140 based on the conversion table 113.

Similar to the third embodiment, the scheduler 160 repeatedly executes the CPU resetting at a predetermined cycle.
As described above, the CPU 160 can be dynamically changed to the application 140 by using the scheduler 160. At this time, as in the third embodiment, the scheduler 160 determines the conversion destination CPU number so that CPUs on the same node are preferentially assigned to the application 140. Thereby, the processing performance of the application 140 created in consideration of NUMA can be appropriately exhibited, and the application 140 can be operated.

  Further, the scheduler 160 can prevent a processing load from being biased to a specific node by setting a node having the smallest load as an extraction target of a CPU to be assigned to the application 140 in accordance with the load of each node. Furthermore, the scheduler 160 can select the number of CPUs requested by the application 140 in order from the lowest load in the same node, thereby achieving leveling of the CPU load in the node. Thereby, the efficiency of resource utilization in the server 100b can be improved. As a result, the processing of a plurality of applications executed on the server 100b can be accelerated. Furthermore, it is not necessary to force the user to change the application 140, and the burden on the user can be reduced.

[Fifth Embodiment]
Hereinafter, a fifth embodiment will be described. Items that are different from the second to fourth embodiments described above are mainly described, and descriptions of common items are omitted.

  The functions exemplified in the second to fourth embodiments can also be applied to a virtual machine. Therefore, in the fifth embodiment, an example in which the function of the scheduler 160 is incorporated in a virtual machine will be described as an example.

  Here, in the fifth embodiment, a server 100c is used instead of the server 100b. The hardware of the server 100c is the same as that of the server 100 of the second embodiment illustrated in FIG. For this reason, the hardware of the server 100c is indicated using the same symbols and names as the server 100.

  The server 100c can execute one or more virtual machines. For example, the server 100c allocates resources such as a CPU and a RAM included in the server 100c to the virtual machine by software called a hypervisor. For example, the hypervisor divides CPU resources by time slots on the time axis and assigns them to virtual machines. One unit of CPU resources allocated to the virtual machine may be referred to as a virtual CPU (vCPU). The virtual CPU is also identified by the CPU number of the virtual CPU. Further, the hypervisor allocates a part of the RAM storage area to the virtual machine.

  FIG. 16 is a diagram illustrating an example of software according to the fifth embodiment. The server 100c has a virtual machine 170. The virtual machine 170 is a virtual machine that operates on the server 100c. The virtual machine 170 includes a storage unit 171, an OS kernel 172, an application 173, and a scheduler 174.

  The storage unit 171 is realized as a storage area reserved for the virtual machine 170 in the RAMs 1 m and 2 m or the HDD 103. The OS kernel 172, the application 173, and the scheduler 174 are realized by the virtual CPU assigned to the virtual machine 170 executing the programs stored in the RAMs 1m and 2m.

  The storage unit 171 includes a process table 171a and a conversion table 171b. The process table 171a corresponds to the process table 112 of the fourth embodiment. The conversion table 171b corresponds to the conversion table 113 of the fourth embodiment. However, the CPU number registered in the process table 171a and the conversion table 171b is the CPU number of the virtual CPU.

  The OS kernel 172 is an OS kernel of the virtual machine 170. The OS kernel 172 assigns a virtual CPU to the application 173 executed on the virtual machine 170. The OS kernel 172 changes the allocation of the virtual CPU to the application 173 based on the conversion table 171b stored in the storage unit 171.

  The application 173 is software that performs processing related to the user's business. As with the application 140, the application 173 has a predefined CPU number used for execution.

  The scheduler 174 resets the CPU number for the process of the application 173. For example, the scheduler 174 determines the CPU number of the CPU assigned to the application 140 based on the placement of each virtual CPU on the node and the usage status of each virtual CPU. Here, for example, the scheduler 174 can treat a plurality of virtual CPUs corresponding to a plurality of CPUs belonging to a common node as virtual CPUs belonging to the same node. The scheduler 174 registers the determined CPU number in the conversion table 171b in association with the process ID and the conversion source CPU number (the CPU number specified by the application 173).

  Also, the scheduler 174 collects information on the virtual CPU configuration information, the current virtual CPU allocation status of each application, and the load on the virtual CPU and RAM in the virtual machine 170, and the storage unit 171 or other storage unit To store. Here, the virtual CPU configuration information is information indicating which virtual CPU belongs to which node.

  Here, the scheduler 174 can determine the CPU number of the virtual CPU assigned to the application 173 by the same method as the scheduler 160 exemplified in the fourth embodiment. For example, “CPU” (physical CPU) described in the procedure executed by the scheduler 160 (corresponding to FIGS. 15, 11, and 12) can be read as “virtual CPU” assigned to the virtual machine 170. Then, the scheduler 174 executes the same procedure as that of the scheduler 160.

  FIG. 17 is a diagram illustrating an example of CPU number conversion according to the fifth embodiment. First, consider a case where there is no application-specified CPU number (FIG. 17A). For example, it is assumed that the virtual CPU group P11 for the virtual machine 170 includes eight virtual CPUs. The CPU number of each virtual CPU is “0” to “7”. At this time, it is assumed that the application 173 is activated by specifying the CPU number “8, 9, 10, 11”. However, the virtual CPU group P11 does not include the virtual CPUs with the CPU numbers “8, 9, 10, 11”.

  Therefore, the scheduler 174 registers the conversion source CPU number “8, 9, 10, 11” and the conversion destination CPU number “0, 1, 2, 3” in the conversion table 171b for the process ID of the application 173. The OS kernel 172 can assign a virtual CPU corresponding to the CPU number “0, 1, 2, 3” to the application 173 based on the conversion table 171b.

Next, consider a case in which the application-specified CPU numbers conflict (FIG. 17B). For example, applications 173 a and 173 b are executed on the virtual machine 170.
The application 173a is defined in advance to operate by designating the CPU number “0, 1”. The application 173b is also defined in advance to operate by specifying the CPU number “0, 1”. That is, the CPU numbers designated by the applications 173a and 173b are both “0, 1” and conflict.

  In this case, for example, the scheduler 174 notifies the OS kernel 172 of the CPU number “0, 1” requested from the application 173a. In response to the notification from the scheduler 174, the OS kernel 172 assigns the virtual CPU having the CPU number “0, 1” among the virtual CPUs included in the virtual CPU group P11 to the application 173a.

  On the other hand, for example, the scheduler 174 notifies the OS kernel 172 to convert the CPU number “0, 1” requested by the application 173b into an available CPU number “2, 3”. Specifically, the scheduler 174 registers the correspondence relationship between the process ID of the application 173b, the conversion source CPU number “0, 1”, and the conversion destination CPU number “2, 3” in the conversion table 171b. Based on the conversion table 171b, the OS kernel 172 can assign a virtual CPU corresponding to the CPU number “2, 3” to the application 173b.

  FIG. 18 is a diagram illustrating a comparative example of CPU number assignment in a virtual machine. In FIG. 18, a virtual machine 410 on the server 400 that does not have the function of the scheduler 174 is illustrated and a comparative example of CPU number assignment will be described. The server 400 includes a virtual CPU group P21 assigned to the virtual machine 410. Eight virtual CPUs belong to the virtual CPU group P21, and the CPU numbers of the eight virtual CPUs are “0” to “7”.

  FIG. 18A illustrates a case where a virtual CPU corresponding to a CPU number requested by an application is not included in the virtual CPU group P21. For example, the application requests CPU numbers “8” to “11”. However, the virtual CPU group P21 does not include virtual CPUs corresponding to the CPU numbers “8” to “11”. The virtual machine 410 does not have a function of converting the CPU number of the virtual CPU. Therefore, the OS kernel cannot appropriately assign a virtual CPU corresponding to the requested CPU number to the application. That is, the requested CPU number and the provided CPU number become inconsistent, which may affect the operation of the application.

  FIG. 18B illustrates a case where CPU numbers requested by two applications conflict. For example, two applications running on the virtual machine 410 both request the CPU number “0, 1”. The virtual machine 410 does not have a function of converting the CPU number of the virtual CPU. Therefore, the OS kernel allocates a virtual CPU corresponding to the requested CPU number to the two applications. However, in this case, the virtual CPU with the CPU number “0, 1” is assigned to both applications in duplicate. For this reason, there is a possibility that the load on the virtual CPU increases and affects the operations of both applications.

  On the other hand, as illustrated in FIG. 17, in the server 100c, the scheduler 174 creates a CPU number conversion table 171b requested from the application, and the OS kernel 172 converts the CPU number based on the conversion table 171b. Therefore, the OS kernel 172 can provide a virtual CPU corresponding to a CPU number that the virtual machine 170 does not have to the application. The OS kernel 172 can assign virtual CPUs to a plurality of applications so that the load on the virtual CPUs is not biased. Thereby, each application can be operated appropriately. Furthermore, it is not necessary to force the user to change the application, and the burden on the user can be reduced.

  Note that the technique of the second embodiment described above may be used in combination with the third to fifth embodiments. For example, the function of the scheduler 150 or the scheduler 160 may be added to the server 100. Then, the server 100 performs allocation to the application 140 based on the conversion table 111 at the initial stage when the application is activated. The server 100 can also change the CPU number of the CPU assigned to the application 140 by the function of the scheduler 150 or scheduler 160 according to the subsequent operation.

  The information processing according to the first embodiment can be realized by causing the computing unit 1b to execute a program. In addition, the information processing of the second to fifth embodiments can be realized by causing a CPU included in the servers 100, 100a, 100b, and 100c to execute a program. The program can be recorded on a computer-readable recording medium 23.

  For example, the program can be distributed by distributing the recording medium 23 on which the program is recorded. Alternatively, the program may be stored in another computer and distributed via a network. For example, the computer stores (installs) a program recorded in the recording medium 23 or a program received from another computer in a storage device such as the RAM 1m, 2m or the HDD 102, and reads and executes the program from the storage device. May be.

10 Information processing device 11, 12 Node 11a, 11b, 11c, 11d, 12a, 12b, 12c, 12d Processor 11e, 12e Memory 15 OS
16 Conversion unit 17 Application D1 Setting information D2 Conversion information

Claims (7)

In a computer having a plurality of processors,
A setting information including the first identification information of the first processor is obtained from the application, and the second of the second processors to be assigned to the application based on the arrangement of the plurality of processors and the usage status of the plurality of processors Determine the identity,
Notifying the operating system of the computer of conversion information in which the first identification information and the second identification information are associated with each other;
Conversion program that executes processing.   The conversion program according to claim 1, wherein in determining the second identification information, a plurality of the second processors belonging to the same NUMA (Non-Uniform Memory Access) node are selected.   3. The conversion program according to claim 2, wherein in the determination of the second identification information, the NUMA node used for selection of the second processor is selected in accordance with a load in units of a plurality of NUMA nodes included in the computer. .   In the determination of the second identification information, among the processors belonging to the NUMA node, the second processors are selected by the number of the first processors specified by the setting information in order from the lowest load. The conversion program according to claim 2 or 3.   5. The conversion program according to claim 1, wherein in the conversion information notification, identification information of the process of the application is included in the conversion information. In a computer having a plurality of processors,
Obtaining conversion information in which the first identification information of the first processor included in the setting information of the application is associated with the second identification information of the second processor assigned to the application;
Based on the conversion information, instead of the first identification information, the second processor corresponding to the second identification information is allocated to the application.
Conversion program that executes processing. A computer having a plurality of processors
A setting information including the first identification information of the first processor is obtained from the application, and the second of the second processors to be assigned to the application based on the arrangement of the plurality of processors and the usage status of the plurality of processors Determine the identity,
Notifying the operating system of the computer of conversion information that associates the first identification information with the second identification information;
The operating system assigns the second processor corresponding to the second identification information to the application instead of the first identification information based on the conversion information.
Conversion method.

Images