JP2001249821A - Job scheduling method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce dead waiting time due to waiting for an event of a process in a job in the job to perform calculation by plural processes. SOLUTION: When a generation factor of waiting for the event to be requested by the process in a certain job exists in except the job for a scheduler to switch processes by unit of job, the job is preferentially switched over to a job to be the generation factor. In addition, when the job waits for the event for execution of a collective function, switching of the jobs is instructed to the scheduler. Furthermore, a processor to execute the collective function is separated from a processor to execute the next job in multi-processor environment. Thus, the useless waiting time for the event is eliminated and processor use rate of all jobs are enhanced by switching the jobs. In addition, the lowering of parallelization efficiency of the jobs is prevented by selectively using the processors.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method of scheduling a program execution in which all processes distributed on a plurality of nodes operate as one job. Particularly, when there are a plurality of such jobs, each job can be efficiently processed. The present invention relates to a job scheduling method which can be executed in a job.

[0002]

2. Description of the Related Art In recent years, in order to satisfy the demand for high-speed processing of enormous data represented by scientific and technological calculations and image processing calculations, a parallel computer capable of performing parallel processing using a plurality of processors has been required. It became the center of the computer to meet.
As a method to connect multiple processors, a relatively small number of processors are connected by a high-speed bus, and a direct connection to each processor allows direct memory access. There is a loosely-coupled multiprocessor configuration system in which a plurality of nodes are connected by a high-speed network. The user program has a plurality of execution conditions (processes or
Threads, hereinafter referred to as processes) are used for parallel processing. The OS controls the execution of the parallel processing corresponding to each user program in units of a job in which the plurality of processes are put together.

Normally, the scheduler of the OS controls the execution of a program on a process-by-process basis. Therefore, when a job is composed of a plurality of processes, the synchronization wait between the processes increases if the execution of the programs of the processes does not cooperate. There is. In order to avoid this increase in the synchronization waiting time, O
S has a gang scheduler. If there are a plurality of jobs to be executed, the continuous execution time (quantum time) of the job is set. By suspending the execution of the same job, the execution of the same job is suspended, another executable job is selected, and the execution of all processes belonging to this job is resumed.
Re-execute the job.

For example, Japanese Patent Application Laid-Open No. 9-128351 assumes a loosely coupled multiprocessor system,
In order to perform gang scheduling efficiently, a system is provided in which the system monitors the frequency of inter-node communication and activates the job switching process based on the frequency.

[0005]

In the above-mentioned prior art, the problem of the synchronization waiting time relating to the synchronization between processes in a job is solved by introducing a gang scheduler.
The quantum time of a job in the gang scheduler is set to be longer than the quantum time in the scheduler of a normal process. because,
This is because, in gang scheduling, all processes included in a job are suspended and re-executed, so that scheduling overhead becomes larger than scheduling of a process that handles suspension and re-execution of a single process. Particularly, in a loosely coupled multiprocessor system, when a process belonging to a job extends to a plurality of nodes, a delay in communication processing is added, and the scheduling overhead further increases.

However, in a system having a conventional gang scheduler, when synchronization is required between different jobs, there is a problem that the gang scheduling alone cannot solve the problem of the synchronization waiting time. FIG. 4 shows different jobs 100 and 104 acquiring locks to access certain resources. The process 102 of the job 104 currently holds the lock, and the process 101 of the job 100 requests the lock. Currently, the gang scheduler permits execution of the job 100, and other jobs including the job 104 are connected to the run queue 103. Each job is switched sequentially in the direction of the arrow of the run queue. Currently running job 100
Process 101 requests acquisition of the lock,
Since the process 102 in the job 104 is not scheduled while holding the lock, the job 101 needs to wait until the job 104 resumes its operation and releases the lock. However, in gang scheduling, since the quantum time of a job is long, the job 1
00 is a problem because it does not switch to the next job immediately after the lock acquisition request.

Further, in the conventional gang scheduler,
Since the context is switched asynchronously with the user job, even if all processes in the user job are stopped waiting for some event, a quantum time is assigned to the user job. Therefore, because a job that does not use a processor is assigned a processor,
Processor utilization is reduced, which is a problem. Along with this problem, for example, if all the jobs in the run queue in FIG. 4 are waiting for a lock, there is a possibility that a processor is uselessly allocated to the intervening jobs (105 to 108) until the job 104 is scheduled. Yes, it is a problem.

[0008] On the other hand, in the above-described conventional technique, the timing of switching is detected by monitoring the network packet. Even if only counting is performed, it is not possible to determine whether or not all processes have entered the waiting state, and the above problem cannot be solved. Further, even when the job does not perform communication, the above problem cannot be solved.

Also, as a function unique to the parallel computing program, there is a collective function in which all processes in a job execute the same function. If the collective function involves waiting for completion of a function, all processes in the job during this wait are performed. However, the conventional gang scheduler cannot catch this opportunity, and each process wastefully occupies the processor even during the waiting time, which is a problem.

As another problem, when the number of processes used by the jobs to be switched is different, if the number of allocated processors is smaller than the above-mentioned number of processes, the synchronization waiting time between the processes may be extended. Furthermore,
If the maximum number of processors is always reserved, if the number of processors to be used is smaller than the maximum number of processors, there is a problem that the processor utilization is reduced.

[0011] It is an object of the present invention to reduce the processor utilization rate due to event waiting by using a gang scheduler to wait for an event of a process in a user job caused by a process other than the user job as a trigger of a schedule. Is to deter.

Still another object of the present invention is to use a waiting event when executing a collective function unique to a parallel computing program as a trigger of a gang schedule.

Further, as another object of the present invention, a processor in which an OS for performing a switching process of a gang scheduler operates and a processor in which a user job operates are separated.
An object of the present invention is to reduce the effect of parallelizing jobs, to prevent an increase in synchronization waiting time, and to increase the utilization rate of a processor by changing the configuration of both jobs and performing parallel processing.

[0014]

In order to achieve the above object, in a plurality of processes constituting a user job,
When one of the processes issues an event wait instruction, the OS uses an event occurrence identification unit to determine whether the process in which the process waits is included in the user job, and Is not included, the process in the user job is switched to another executable job.

In order to achieve the above object, when a user job executes a collective function, the user job is switched to another executable job in response to a request for a collective function.

In order to achieve the above object, the node has a multiprocessor configuration, and has a function of separating a user execution processor on which a user job operates and a service execution processor on which an OS or a service program operates. When a user job is switched to another executable job triggered by a certain event, the configurations of the user execution processor and the service execution processor are changed.

[0017]

FIG. 1 is a diagram showing the configuration of an embodiment of the present invention. 1 to 6 represent nodes. The node includes a plurality of processors (25 to 28, 13) and a main memory,
Each processor can directly access the main memory in the node. Each node is connected by a high speed network (18), and the processor on one node can usually access the memory of another node via this network and OS processing. A node (2,
Disk devices (7, 9) are connected to 6). A plurality of disk devices 8 are connected to the node 5. These disk devices can be accessed from the other nodes (1, 3, 4) via the OS.

Each node has a functionally equivalent OS. In each OS, a process (12) for processing the OS runs on a processor (13) dedicated to the OS. In this embodiment, no distinction is made between processes and threads unless otherwise specified. For example, when the OS is composed of a plurality of threads, each thread can share data in the OS. However, when the OS is composed of a plurality of processes, the virtual space of each process is independent. Therefore, another device is required to access the shared data. It is also possible to perform OS processing by appropriately mixing processes and threads. To access these shared data,
The invention is essentially adaptable to either method, as it is only an implementation difference for the invention.

The user program is executed as a job. A job is composed of a plurality of processes, and a process is composed of a plurality of threads. Threads in a process share the same virtual space. In FIG. 1, jobs 10 and 1
1 exists, and the job 10 holds processes 17 to 20. When the process is executed as a thread, for example, 17 and 18 are set as the thread of the process on the node 1. Since threads belonging to the same process share the virtual space, threads on different nodes belong to different processes. If attention is paid to this, the process can be replaced with a process and a thread at any time. Therefore, the migration does not distinguish between the process and the thread. However, this embodiment can be easily applied to the embodiment using a thread. The process belonging to the user job is a user processor (1
It is executed in 4), and is not executed by the OS dedicated processor.

Each OS has a process scheduler for scheduling a process and a gang scheduler for scheduling a job including a plurality of processes. The process scheduler is a scheduler in a node, and schedules each process according to the priority of the process on the node managed by the scheduler. The gang scheduler is a scheduler that spans nodes,
Schedule each job according to the priority assigned to each job. Process priority and job priority are independent of each other and usually do not affect each other.

The OS on each node manages user jobs to be executed using a job management table (16). Details of the job management table will be described later. Further, the OS has an event occurrence specifying means, and when a user program requests a certain event wait, it is possible to specify a process for generating the event.

Next, referring to FIG. 2, an overall operation of an example in which a user job displays characters on a screen will be described.
FIG. 2 is a diagram illustrating the node 1 and the node 2 in the overall operation according to the present embodiment. Each job (1
0, 11) is a certain basic time (quantum time), and the processes included in each job are switched simultaneously. It is assumed that the job 10 is currently operating and the job 11 is executable, but the processor is not allocated and is waiting for execution.

The process 17 in the job 11 of FIG. 2 attempts to obtain a lock for accessing the device corresponding to the screen in order to display characters on the screen (210). This lock is not a so-called spin lock that monitors acquisition of a lock. If acquisition of a lock fails, the processor yields and waits for acquisition of the lock. The OS on the node 1 receives this request and checks whether the lock can be acquired (211). If you can get the lock,
Return to the user program and start outputting characters. If not, go to the next step. Next step 2
At 12, an event wait request for lock release is made to acquire the lock. Next, the OS uses the event occurrence specifying means to specify a process that generates the lock release event (213), and checks whether the process belongs to the job 11 to which the process that issued the lock request belongs ( 214). If the process belongs to the job 11, the process proceeds to step 216, and the process 17 enters an event waiting state. Otherwise, a job switching request is made to the gang scheduler on node 1 (215). The gang scheduler on node 1 suspends processes 17 to 20 belonging to job 11. The process 17 enters an event waiting state at 216 after the job switching. Since process 18 is on node 1, the gang scheduler on node 1 updates the state to a suspended state. For processes 19 and 20, node 2
A job switching request is issued to the above gang scheduler (215). Job switching request received (217)
The gang scheduler on node 2 processes
20 is updated to the suspended state.

Through the above steps, the job 10 is triggered by the lock acquisition event, all the processes are suspended, and the used processor is released. Thereafter, if there is another executable job, the gang scheduler allocates a free processor to a process in the job. Otherwise, put the processor in the idle state. In FIG. 1, for example, if the job 11 is executable, a processor is allocated to the process in the job and the execution is resumed.

In the above example, the case where the event specifying means 15 is included in the OS has been described. However, the event specifying means may be managed at the user program level together with the job and the process. In this case, at the user program level, specify the event occurrence job,
Add event occurrence job information.

According to this procedure, only when the cause of the event is a job other than the job waiting for the event, the job waiting for the event is temporarily stopped and the job is switched to another job. Therefore, when the above-mentioned factor is present in the event waiting job, the switching is not performed, so that unnecessary calling of the job switching process is prevented. In other words, if the factors are in the same job, it is easier for the process that has requested the lock to acquire the lock if the job is executed without switching.

FIG. 3 shows the process of completing the event wait. In this example, it is assumed that a certain process on the node 2 holds the lock. When the above process releases the lock (2
20) A release request is issued to the OS on the node 2. When the OS on the node 2 receives the lock release request (221), the process management table (230 in FIG. 5)
, The job waiting for the lock is specified from the process waiting for the lock (222). The process management table will be described later. In the case of the present example, the job 10 which is the job to which this process belongs is specified from the lock waiting process 17. Next, the gang scheduler on the node 2 makes the lock waiting job 10 executable (223). The gang scheduler specifies that the processes belonging to the job 10 are processes 17 to 20, and makes all the processes executable. For the gang scheduler on node 2, processes 19 and 20
Is a process on the same node, so that it is directly executable. Since the processes 17 and 18 are jobs on different nodes, a job start request is made to the gang scheduler on the node 1. The gang scheduler on the node 1 that has received the activation request is (22
5) The processes 17 and 18 existing on the same node are made executable (226).

By the above processing, the entire job 10 to which the process that issued the lock request belongs is temporarily stopped when a lock request is issued, and the entire job 10 is executable when a lock is acquired. As a result, the job 10 does not wastefully use the processor until the end of the quantum time.

Next, a method for specifying the event occurrence process will be described in detail. FIG. 5 is a table used for specifying the event occurrence process, and is managed by the management program. The management program exists in the OS or the user program.
Each entry in the process management table 230 is a process I
D, a node number, a waiting event, and a job ID field. The process ID is an ID unique to each process. The node number is a node number where the process exists. When a process is waiting for an event, the wait event describes the event. A logical number (event number) is added to the event by the OS. For example, process 17 is waiting for an event, and the logical number of the event is L
It is one. The OS uses the event number as an argument to release the waiting state of the event waiting process, and
When waiting for an event, an interface is provided that returns the event number corresponding to the event specified by the user and then starts waiting for the event. The last job ID contains the ID of the job to which the process belongs. In FIG. 5, process 1
7 to 20 belong to the job with the job ID 10 and the process P
1 belongs to the job whose job ID is J1.

The job management table manages the correspondence between jobs and processes belonging to the jobs. Each entry includes a job ID and a process list field. The process list holds a list of processes belonging to the job corresponding to the job ID. In this example, the job 10 holds processes 17 to 20 as a process list.

Each entry in the event management table is an event,
It consists of a list of processes that cause the event and those that wait for the event. Entry 235 contains event L
No. 1 is described, indicating that the process that generates this event is P1, and the process waiting for the occurrence of this event is the process 17. For example, when this is applied to lock acquisition, the event is a lock release event, the lock holding process is the event generation process, and the lock waiting process is registered in the event waiting process list.

With respect to the above management table, the management program creates related entries on all nodes related when a process or a job is generated or when an event occurs.

Next, an event occurrence specifying procedure for specifying an event occurrence job will be described with reference to FIGS. The event occurrence specifying means receives the event number L1 as an argument, searches the event management table 231 and obtains the event occurrence process P1 from the entry 235 (250). Next, the process management table 230 is searched, and the job ID J1 is obtained from the entry 236 corresponding to the process P1 (25).
1). By obtaining the job ID, the specification of the event occurrence job is completed (252). Further, the job management table 1
6 is retrieved, and a process list is acquired from the job ID J1 (253). In this case, the process list consists only of the process P1.

By comparing the job ID and process list obtained by the event occurrence specifying means 15 with the event wait request process, it is possible to determine at 214 whether the event wait request process and the event occurrence process belong to the same job. it can.

Next, the job switching method will be described in detail. In the method shown in FIG. 2, by temporarily suspending the job in the event waiting state, the remaining quantum time of the job is prevented from being allocated to the event waiting time. As a result, unnecessary waiting time can be reduced, and the processor utilization of the system can be improved. However, as shown in FIG. 4, when there are a plurality of executable jobs other than the event waiting job 100 and all the jobs in the run queue are waiting for the same lock release event, all the jobs in the run queue are The event is wasted for one quantum time. Therefore, when the event waiting job 100 is suspended, the event occurrence job 1
04 is preferentially scheduled, thereby avoiding the useless waiting time as described above.

There are several methods for preferentially scheduling an event occurrence job as follows. (1) In FIG. 4, after temporarily suspending the event waiting job 100, the OS not only sets the event occurrence job 104 to the executable state, but also ignores the order on the run queue and
Processor is assigned to the job 104 prior to 08
Start execution.

(2) In FIG. 4, after the OS has a function of raising the priority for one quantum time, the job 100 is temporarily stopped, and the
Is temporarily increased, and the job 104 is scheduled with priority. The priority of the job automatically returns to its original state after the elapse of one quantum time.

(3) In the above method (2),
When the priority of the job 104 is temporarily increased, the priority of all processes belonging to the job is also temporarily increased.

Next, an embodiment at the time of executing the collective function will be described. FIG. 7 is a diagram showing a state of execution of the collective function. Each process of the user job 10 simultaneously starts executing the collective function. In FIG. 7, processes 17 to 17 of the processes constituting the user job 10 are illustrated.
Only 19 is shown. Another process 20 performs the same operation.

In FIG. 7, input / output to / from a disk device is performed as a collective function. First, in order to start collective input / output execution, each process in the job 10 issues a collective input / output execution request to the OS on the node where each process exists. In FIG. 7, processes 17, 1
8 issues a collective input / output request to the OS 301 on the node 1. Similarly, on the node 2, the processes 19 and 20 issue a collective input / output request to the OS, and the OS 301 on the node 2 receives the request.
After receiving requests from all the processes in the job, the OSs 300 and 301 optimize input / output while communicating with each other, and then execute the OS on a node (for example, the node 5 or the like) to which the disk is connected. Start executing I / O to.

In the collective function, all processes in a job perform the same operation. Therefore, if there is a wait event, all processes in the job enter a wait state. In the above example,
All the processes 17 to 20 in the job 10 wait for completion of the input / output request after the input / output request. Therefore, by switching jobs at this time, it is possible to reduce unnecessary waiting time of each process.

FIG. 8 shows the operation of the user program and the operation of the OS when the collective function is executed. The whole process is divided into a user program process and an OS process, and the processor that executes each process is also divided into a user execution processor and a service execution processor. Initially, a user program that performs collective processing operates on a user execution processor. This user program operates on the job 10. The process 17 executing this program first issues a collective request (300). The collective execution itself is executed by another module in the user program. Alternatively, there may be an implementation in which the OS executes collective execution. In that case, the processes 301 to 306 and 3 in FIG.
07 to 308 are executed in the OS. In this embodiment, the execution of the collective function operates as a user program. In this case, the separate module is divided into a part that operates as an extension of the user process and a part that is not included in the user job and operates as a separate process. . Upon receiving this request, the module operates as an extension of the user process and collects requests from other processes (18 to 20) (302). After all the requests have been collected, the completion of the collective request is waited for (302). At the same time, the service execution processor instructs the collective processing process operating as a separate process to execute the collective function. Thereafter, the collective function is executed on the same process in parallel with the user process (307).

The process that waits for the completion of the collective request issues a request to suspend the job 10 to the OS (303). The OS receiving the request checks whether there is another executable job (304), and if so, allocates a processor to another job and executes the same job (30).
5). If not, the processor is set to the idle state and the job is waited for activation. When the execution of the collective function being executed by the service execution processor is completed, the collective processing process sends a collective function execution end notification to the OS (308). The OS sets the job 10 waiting for this event to the item possible state again (30
6).

As described above, when the collective function is executed due to the characteristics of the collective function, all processes that have requested the function wait for the completion of the execution of the function. By instructing switching to a job, unnecessary waiting time is reduced. Therefore,
In the above example, input / output to / from the disk device has been described as a collective function. However, collective communication can be similarly easily applied. Further, by separating the processor for executing the user program and the processor for executing the service, there is also an effect of suppressing interference with the execution of the next job switched by waiting for an event.

The job to be executed next is job 11
In the case where 27 and 28 among the processors 14 on the node 2 are assigned to the service execution processor instead of the user execution processor, the configuration of the processor is changed at the time of switching to the job 11, and
By including 7 and 28 in the processor for user execution, the job 11 is switched to the next job without impairing the parallelism.

[0046]

According to the present invention, when a certain process in a user job enters an event waiting state, all processes in the user job are temporarily stopped only when the factor causing the event is other than the user job. By switching to the next job and switching to the next job, it is possible to prevent the user job from wastefully waiting for an event, so that the utilization rate of the processor can be increased. In addition, when there are a plurality of jobs waiting for the same event, by scheduling the event occurrence job in preference to those event waiting jobs,
It is possible to reduce unnecessary event waiting and increase the processor utilization rate.

Further, when the user job executes the collective function, the job is switched upon the event wait of all processes in the user job, which occurs during the collective function processing, thereby reducing unnecessary event wait.
It is possible to increase the processor utilization.

Further, when switching to another user job, by changing the configuration of the processor, it is possible to prevent the parallelism of the next job from being impaired.

[Brief description of the drawings]

FIG. 1 is a configuration diagram of a computer system according to an embodiment of the present invention.

FIG. 2 is a diagram showing a processing procedure when a user job waits for an event in the present invention.

FIG. 3 is a diagram showing a processing procedure when a user job that waits for an event is restarted in the present invention.

FIG. 4 is a diagram showing a state where a plurality of jobs wait for an event in the present invention.

FIG. 5 is a diagram showing a table used in the present invention.

FIG. 6 is a diagram showing a processing procedure for specifying occurrence of an event in the present invention.

FIG. 7 is a diagram schematically showing execution of a collective function in the present invention.

FIG. 8 is a diagram showing a processing procedure for executing a collective function in the present invention.

[Explanation of symbols]

1 ... node 1, 2 ... node 2, 10 ... user job, 1
1: User job, 15: Event occurrence specifying means, 16: Job management table

 ──────────────────────────────────────────────────続 き Continuing on the front page (72) Inventor Kuma ▲ Saki ▼ Hiroyuki 5030 Totsuka-cho, Totsuka-ku, Yokohama-shi, Kanagawa Prefecture Inside Software Division, Hitachi, Ltd. (72) Inventor Hiroyuki Takatsu Totsuka-cho, Totsuka-ku, Yokohama-shi, Kanagawa 5030 F-term in the Software Division, Hitachi, Ltd. (Reference) 5B045 AA03 CC06 EE08 EE13 5B098 AA10 CC01 GA03 GA04 GA05 GA08 GC03 GC05 GD02 GD14 GD22

Claims (10)

[Claims] 1. A computer system in which a plurality of processors and a node comprising a memory accessible from each processor are connected by a high-speed network, and some of the nodes are connected to a plurality of input / output devices in a computer system. When an OS having an equivalent function operates on a node and one or more user processes belonging to the user job operate on each node for a user job composed of a plurality of user processes, and a plurality of user jobs exist ,
A time-division scheduler for a job that suspends all user processes that make up a running user job at once and reschedules all processes belonging to another stopped user job at one time, and when a user job waits for an event In the case of an OS having an event occurrence job specifying means for specifying which job causes the event, when a certain user job waits for an event to occur, a certain process in the user job waits for the event. A step of issuing a request to suspend, a step in which the OS that has received the suspension request identifies a job that causes the event using the event occurrence identifying unit, and a step in which the job identified in the previous step issues the suspension request. OS if different from user job
Suspending all processes belonging to the job that issued the suspension request, and setting the OS to a user job waiting for the event when the event occurs, so that all the processes belonging to the job can be executed by each node. And setting the job executable state again. 2. The job scheduling method according to claim 1, wherein when the user job waits for an event, if the means for specifying which job causes the event is not provided in the OS, the user job is set in the event waiting state. When you wait,
A step of specifying a job that causes an event; a step of issuing a request to suspend the job together with information of the event-occurring job to the OS; and the OS receiving the request uses the information to wait for the user job. Checking whether the job that causes the event is the user job. 3. The job scheduling method according to claim 1, wherein when the event occurrence job is made executable, the job is preferentially scheduled for a specific time. 4. The job scheduling method according to claim 3, wherein a processor is assigned to the event occurrence job immediately after the event waiting job is stopped so that the event occurrence job is preferentially scheduled for a specific time. And a job scheduling method. 5. The job scheduling method according to claim 3, wherein the priority of the job is increased only for a specific time in order to schedule the job only for a specific time. 6. The job scheduling method according to claim 5, wherein when increasing the priority of the job, the priority of all processes belonging to the same job is increased. 7. A computer system in which nodes each including a plurality of processors and a memory accessible from each processor are connected by a high-speed network, and some of the nodes are connected to a plurality of input / output devices in a computer system. An OS having the same function operates on a node on a predetermined service execution processor. For a user job including a plurality of user processes, a user process belonging to the user job is executed on each node. If one or more user jobs are running on a user execution processor other than the service execution processor and there are multiple user jobs, all the user processes that compose the running user job are suspended at once, and another suspended Time-division schedule of a job to reschedule all processes belonging to a user job at once When the user job waits for an event, the OS having event occurrence job specifying means for specifying which job causes the event to occur, the user job is executed by all user processes in the job. Starting the execution of the collective function that operates on the network, collecting the start request from each user process by the user job, and temporarily stopping the user process on each node in order to wait for the completion of the request function after collection is completed. Making a stop request to the OS; and, if another job exists, the OS selecting the user job and re-executing a user process belonging to the user job on each node. , A step in which a user program executes a collective function on a service execution processor, and a corresponding function Setting a user process that is waiting for completion at the end of the process to an executable state. 8. The job scheduling method according to claim 7, wherein a collective communication function for simultaneously communicating between processes belonging to the job is executed as a collective function. 9. The job scheduling method according to claim 8, wherein a collective file input / output function for simultaneously performing file input / output between processes belonging to the job is executed as a collective function. 10. The job scheduling method according to claim 7, wherein the service execution processor is a shared processor and the user execution processor is an exclusive processor, and the shared processor is allowed to execute a plurality of jobs in a time-division manner for each process. The OS has a scheduler that allows the exclusive processor to execute a plurality of jobs in a time-division manner on a job-by-job basis. A job scheduling method characterized by changing.