JPH05233572A - Process dispatch system for multiprocessor - Google Patents

Abstract

PURPOSE:To repeat the execution with a single processor corresponding to a local run queue based on the time slice by holding the processes or the process groups in the local run queues for a fixed time based on the order of priority from the process groups which ere connected to an accessable global run queue from all processors. CONSTITUTION:The processes included in a global run queue 112 ere fetched to the local run queues 106-108 provided in the processors respectively in the order of priority. Then these processes are successively carried out based on the time slice. The processors 101-103 contain the processing means which return again the processes fetched to the local run queues and carried out to the queue 112 after a fixed time.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention, in a multiprocessor system having a cache memory for each processor, improves the cache memory effect (cache hit ratio) while maintaining the load balance between the processors. The present invention relates to a process dispatch method in a multiprocessor capable of performing.

[0002]

2. Description of the Related Art Conventionally, in a multiprocessor system, a run queue (also called a ready queue) in which a plurality of executable processes (tasks, jobs, threads, etc.) can be accessed from all processors in the order of arrival or priority There is a method in which each processor dispatches processes sequentially from the head of the queue in time slices.

However, when the process scheduling according to this method is used, the process frequently moves among a plurality of processors. In the extreme case, a context switch occurs and the executing processor changes each time the process is redispatched.

In such a state, the effect of caching due to the locality of access of the process (program) is reduced, so that the cache hit rate of each CPU is reduced and the throughput of the entire system is reduced. ..

In order to avoid this problem, there is a method of fixing the process execution processor. However, this method has a problem that the number of processes that can be executed is not uniform and the load balance between the processors is deteriorated.

[0006]

As described above, in the conventional dispatching method in the multiprocessor, the caching effect cannot be enhanced without disturbing the load balance between the processors, so that the system throughput is improved. There was a problem that could not rise.

The present invention eliminates the above-mentioned drawbacks of the prior art, and in a multiprocessor system, the effect of caching can be enhanced and the system throughput can be improved without disturbing the load balance between the processors. The purpose is to provide a process dispatch method.

[0008]

In order to achieve the above object, in a process dispatch system in a multiprocessor according to the present invention, a global run queue accessible from all processors to hold an executable process is provided. , In a multiprocessor system having a local run queue provided for each processor and having a cache memory for each processor, processes are fetched into the local run queue from the processes in the global run queue in order of priority. And means for sequentially executing the processes fetched to the local run queue based on the time slice, and means for returning the processes fetched to the local run queue and executed after a certain time to the global run queue again. do it And wherein the Rukoto.

Further, in the present invention, a global run queue accessible from all processors to hold an executable process and a local run queue provided for each processor are provided, and a cache memory is provided for each processor. In a multiprocessor system that has, based on a time slice, a method for fetching a plurality of processes sharing the same address space from among the processes in the global run queue to a local run queue and a process fetched to the local run queue. It is characterized by comprising means for sequentially executing and means for returning the process fetched to the local run queue to the global run queue again after a certain period of time.

[0010]

According to the present invention, each of the plurality of processors holds a process or a group of processes from the processes in the global run queue in the local run queue for a certain period of time according to the priority, the address space, etc. By repeating the execution based on the time slice, the cache hit rate in the processor access can be improved. At the same time, by moving a process or a group of processes between a global run queue accessible from all processors and each local run queue at a certain timing, it is possible to prevent the load balance between processors from being lost. In this way, in a multiprocessor, it is possible to improve the throughput of the system without disturbing the load balance between the processors and enhancing the effect of caching.

[0011]

Embodiments of the present invention will be described below with reference to the drawings. FIG. 1 is a block diagram showing the configuration of the first embodiment of the present invention.

The shared memory type multiprocessor system of this embodiment shown in FIG. 1 has three processors (PM).
0, PM1, PM2) 101, 102, 103 and a plurality of these processors (PM0, PM1, PM2) 10
1, a shared memory (CM) 105 connected to a memory bus (BUS) 104 is illustrated as an example. Each of the above processors (PM0, PM1,
The PM2) 101, 102, 103 each have a dedicated cache memory.

On the shared memory (CM) 105, all the processors (PM0, PM1, PM2) 101, 1
02 and 103, the global run queue (GRQ) 112 and the global run queue (GRQ)
Q) Global run queue counter (GC) 1 that stores the number of pending processes (P) connected to 112
13 and each processor (PM0, PM1, PM2) 10
A local run queue (LR) that is provided for each of the 1, 102, and 103 and connects the waiting process (P) 114
Q0, LRQ1, LRQ2) 106, 107, 108
And this local run queue (LRQ0, LRQ1, L
RQ2) Local run queue counters (LC0, LC1, L that store the number of processes in 106, 107, 108)
C2) 109, 110 and 111 are held.

That is, the processor (PM0) 101 has a local run queue (LRQ0) 106, a local run queue counter (LC0) 109, and a processor (PM1).
The local run queue (LRQ1) 107 and the local run queue counter (LC1) 110 are shown in 102, and the local run queue (LRQ) is shown in the processor (PM2) 103.
2) 108 and local run queue counter (LC2) 1
11 are provided correspondingly.

The global run queue counter (G
C) 113 and each local run queue counter (LC
The values of 0, LC1, LC2) 109, 110, and 111 are changed (updated) at the time of creating and deleting processes in each run queue.

For example, each processor (PM0, PM1,
The schedulers of PM2) 101, 102, and 103 respectively transmit from the global run queue (GRQ) 112 to their own local run queues (LRQ0, LRQ1, LRQ2) 1
The number of processes fetched to 06, 107, 108 is fixed at X at a time.

Then, each processor (PM0, PM1,
PM2) 101, 102, 103 are local run queues (LRQ0, LRQ1, LRQ2) 106, 107,
The process groups fetched to 108 are sequentially executed based on the time slice, and if the total CPU consumption time of each process (referred to as [TCT] here) is within Y seconds, the process group remains in its own local run queue. , [TC
After [T] has passed Y seconds, the global run queue (GRQ) 112 is executed for all processes connected to the local run queue and processes executed by the local processor.
I will return to. Further, it is assumed that X processes are fetched again from the global run queue (GRQ) 112 to the empty local run queue.

However, the CPU consumption used for the calculation of [TCT] is not the consumption time when the time when the process is generated is "0", but the consumption time after the process is fetched into each local run queue. is there. FIG. 2 is a flowchart showing an algorithm of the dispatch method according to the embodiment shown in FIG.

Each processor (PM0, PM1, PM2)
The schedulers corresponding to 101, 102 and 103 first send X processes from the global run queue (GRQ) 112 to their own local run queues (LRQ0, LRQ).
1, LRQ2) 106, 107, 108 are fetched (step a1 in FIG. 2).

At this time, the values of the local run queue counters (LC0, LC1, LC2) 109, 110, 111 are set to X. At this point, [TC
T] is initialized to "0" (step a2 in FIG. 2).

Next, the processors (PM0, PM1, PM
2) 101, 102, 103 are local local queues (LRQ0, LRQ1, LRQ2) 106, 107, 1
One of the X processes connected to 08 is dispatched and executed based on the time slice (steps a3 and a4 in FIG. 2).

Then, after the process runs out of time intervals of execution, the CPU consumption time of the process (in this case, the value of the time step) is added to [TCT] (FIG. 2).
Step a5).

When the value of [TCT] exceeds Y seconds, the scheduler of the processor returns all the X processes fetched to the local run queue to the global run queue (GRQ) 112, and again,
X new processes are fetched from the global run queue (GRQ) 112 to the local run queue (steps a7 and a1 in FIG. 2).

On the contrary, when the value of [TCT] is within Y seconds, the processor returns the process which was being executed up to that time to its own local run queue, and then dispatches and executes the next process from its own local run queue. (Steps a6, a3, a4, ... in FIG. 2) are continued.

When the dispatch method performed by such an algorithm is adopted, the states of the global run queue and the local run queue at a certain time point are shown in FIG.
become that way.

Incidentally, in FIG. 3, 301, 302, 30
3 is the processor (PM0, PM1, PM2) 1 of FIG.
01, 102, 103, 304, 305, 30
6 is the local run queue (LRQ0, LRQ of FIG.
1, LRQ2) 106, 107, 108, and 30
Reference numeral 8 corresponds to the global run queue (GRQ) 112 in FIG. 307 is an execution waiting process (P).

Under the condition shown in FIG. 3, the local run queues (LRQ0, LRQ1, LRQ2) 30 are provided.
No more than X-1 processes (P) are always connected to 4, 305, 306 (that is, one process is being executed by the processor. Also, waiting for execution due to I / O wait, execution termination, etc.) The number of processes in the local run queue is reduced because the process disappears).

Each local run queue (LRQ0, LRQ
1, LRQ2) 304, 305, and 306 are respectively assigned to the processors (P
M0, PM1, PM2) 301, 302, 303 corresponding to the global run queue (G
While it is being returned to the RQ) 308, it will not be dispatched to another processor no matter how many context switches occur. As a result, it is possible to suppress frequent movement of processes between processors, and it is possible to improve the caching effect.

Further, it is possible to prevent the load balance between the processors from being largely lost. This will be described with reference to FIG. In FIG. 4, 401, 402, 403
Is the processor (PM0, PM1, PM2) 10 of FIG.
1, 102, 103 (301, 302, 303 in FIG. 3)
1 corresponds to the local run queues (LRQ0, LRQ1, LRQ2) 106,
107, 108 (304, 305, 306 in FIG. 3), and 408 is the global run queue (GRQ) in FIG.
This corresponds to 112 (308 in FIG. 3). Reference numeral 407 is an execution waiting process (P).

FIG. 4 shows an example of a state in which the execution time of each process has passed several seconds ([TCT] is within Y seconds) from the state of FIG. 3 above. The number of pending processes for processors is uneven among the processors. That is, in this example, in the process processing of the processor (PM2) 403, for example, a switch between processes, waiting for I / O processing (idle), and the like intervene, and [T
CT] is another processor (PM0, PM1) 401, 4
It is extremely smaller than 02.

However, this is a processor (PM0, PM
1) When [TCT] of 401 and 402 exceeds Y seconds,
The local run queue (LRQ0,
Since the processes in the LRQ1) 404 and 405 are fetched again from the global run queue (GRQ) 408, each processor (PM0, PM1, PM2) 401,
The number of pending processes for 402 and 403 becomes equal among the processors, and the state returns to the state of FIG.

As described above, it is possible to prevent the load balance between the processors from being greatly disturbed by executing the periodical process replacement processing between the local run queue and the global run queue.

Here, in the above embodiment, in order to further improve the caching effect for each processor,
Scheduling considering the access locality of the process is possible.

For example, now, there are three files F0, F1, and F2. The process accessing the file F0 has the address space A0, the process accessing the file F1 has the address space A1, and the process accessing the file F2 has the file F2. It is assumed that the address space A2 is shared.

At this time, each processor (P
The schedulers of M0, PM1, PM2) 101, 102, 103 from the global run queue (GRQ) 112 to their own local run queues (LRQ0, LRQ1, LRQ).
2) When selecting the processes fetched to 106, 107, 108, the process to access the file F0, that is, the address space A0 is shared by the processor (PM0) 101, rather than simply selecting them in order of priority. A process for accessing the file F1 to the processor (PM1) 102, that is, a process sharing the address space A1, and a process accessing to the file F2 for the processor (PM2) 103, that is, the address space A2.
Priority should be given to each process that shares the.

In this way, each processor (PM
0, PM1, PM2) 101, 102, 103 share the access space to some extent, so that the cache hit rate is further increased and the caching effect is significantly improved.

In the dispatch method of the first embodiment described above, in the process migration between the local run queue and the global run queue, the [TCT] of the processes in the local run queue (total CPU consumption time of each process) is In this method, when a certain value (Y seconds in the above example) is reached, a certain number (X in the example) of process groups are treated as a group. As described above, a second example of handling a single process will be described below, as compared to an example of handling a group of processes. In the second embodiment, the CPU consumption time of each process in the local run queue is [CT].

However, [CT] here is the time indicating how much the CPU has been used since the time when the process is fetched from the global run queue to the local run queue is "0". Therefore, the [CT] of a process is a valid value only when the process is in the local run queue.

Here, the scheduler of each processor is
Check the [CT] of the process in the local run queue, and return the process with the [CT] greater than Z seconds to the global run queue. Instead, retrieve one process from the global run queue and connect it to the local run queue. To do.

Further, at this time, as the execution of the processes in the local run queue progresses, the number of processes in the local run queue may decrease due to the disappearance of the waiting process.

Therefore, the scheduler of each processor is
The number of processes is checked by the value of the local run queue counter at an appropriate timing, and if the number is less than a certain number (upper limit of the number of processes), the global run queue is replenished with processes until the number reaches the certain number. To do. FIG. 5 shows the dispatch type algorithm of the second embodiment.

When the upper limit value of the number of processes in the local run queue is MXP, first, [(MXP)-(local run queue counter)] processes are fetched from the global run queue to the local run queue. At this time, [CT] of the fetched process is set to "0".
Initialization (steps b1 and b2 in FIG. 5). The processor dispatches a process in the local run queue and executes it based on the time slice (step b).
3, b4). Then, when the execution is completed, [CT] is updated (step b5).

After [CT] is updated, in order to determine the process switching between the global run queue and the local run queue, if it is longer than Z seconds, the process that has just finished being executed is returned to the global run queue instead of the local run queue, and the process is reversed. Then, the process is replenished from the global run queue to the local run queue (step b6).
b7, b1, ...).

On the other hand, if [CT] is less than Z seconds, the process is returned to the local run queue and waits for execution, and the processor executes a new process (steps b6, b).
3). In this algorithm, the timing of replenishing the process to the local run queue is synchronized with the time when [CT] exceeds Z seconds.

FIG. 6 shows the operation of the second embodiment.
In FIG. 6, reference numerals 601, 602 and 603 denote the processors (PM0, PM1, PM2) 101, 10 of FIG.
2 and 103, and 604, 605, and 606 are shown in FIG.
Local run queue (LRQ0, LRQ1, LRQ
2) 106, 107, and 108, and 609 corresponds to the global run queue (GRQ) 112 in FIG. 6
Reference numeral 07 is a process to be moved.

In this case, the value of [CT] immediately after the process executed by the processor (PM0) 601 is finished is Z seconds or more, and the global run queue (GRQ) is reached.
The process is passed to the global run queue (GRQ) 609 because the condition to be moved to 609 is satisfied, while one process is fetched from the global run queue (GRQ) 609 to the local run queue (LRQ0) 604.

As described above, the process connected to the local run queue is for a while (CT in this example).
> Z seconds) will be executed on only one processor, so the caching effect is improved.

Further, FIG. 7 shows the number of processes in the local run queue as a local run queue counter (LC0) 70.
In this example, the global run queue (GRQ) 709 is replenished because it is less than MXP. In FIG. 7, reference numerals 701, 702, 703 denote processors (PM0, PM1, PM2) 101, 102, 10 of FIG.
3 corresponds to the local run queues (LRQ0, LRQ1, LRQ2) 10 in FIG.
6, 107 and 108, and 709 corresponds to the global run queue (GRQ) 112 in FIG. Reference numeral 707 is a movement target process, and 708 is a supplement process.

In this way, the number of processes in the local run queue is checked by the local run queue counter, and M
Global run queue (GRQ) when less than XP
By replenishing from 709, the number of processes among the processors is maintained to some extent evenly, and the load balance is improved.

[0050]

As described in detail above, according to the present invention, a global run queue accessible from all processors for holding an executable process and a local run queue unique to each of a plurality of processors are provided. In a multiprocessor system in which each processor has a cache memory, hold a process or processes in the local run queue for a certain period of time, and repeat the execution based on the time slice on one processor corresponding to the local run queue. By doing so, the cache hit rate in processor access can be improved. At the same time, by moving a process or a group of processes between a global run queue accessible from all processors and each local run queue at a certain timing, it is possible to prevent the load balance between processors from being significantly disturbed. .. This allows
The throughput of the system can be improved.

[Brief description of drawings]

FIG. 1 is a block diagram showing a configuration of an exemplary embodiment of the present invention.

FIG. 2 is a flowchart showing an algorithm of the dispatch method of the embodiment shown in FIG.

FIG. 3 is a diagram showing the states of a global run queue and local run queues when the dispatch system of the first embodiment is used in the system of the embodiment shown in FIG.

4 is a diagram showing the states of the global run queue and each local run queue after a few seconds have elapsed from the state of FIG. 3 in the system of the embodiment shown in FIG.

FIG. 5 is a flowchart showing an algorithm of the dispatch method according to the second embodiment of the present invention.

FIG. 6 is a diagram showing process movement between a global run queue and a local run queue when the dispatch system of the second embodiment is used in the system having the configuration shown in FIG.

FIG. 7 is a diagram showing process replenishment from a global run queue to a local run queue in order to maintain a load balance between processors in the dispatch system of the second embodiment.

[Explanation of symbols]

101, 102, 103, 301, 302, 303, 4
01, 402, 403, 601, 602, 603, 70
1, 702, 703 ... Processor (processor module with cache; PM0, PM1, PM2). 104 ... Memory bus (BUS). 105 ... Shared memory (CM). 106, 107, 108, 304, 305, 306, 4
04,405,406,604,605,606,70
4, 705, 706 ... Local run queue (LRQ0,
LRQ1, LRQ2). 109, 110, 111 ... Local run queue counters (LC0, LC1, LC2). 112, 308, 408, 609, 709 ... Global run queue (GRQ). 113 ... Global run queue counter (GC). 114, 307, 407, 608, ... Waiting process (P). 607, 707 ... Process to be moved. 708 ... Replenishment process.

Claims (2)

[Claims] 1. For holding a runnable process,
In a multiprocessor system that has a global run queue accessible from all processors and a local run queue unique to each of the multiple processors, and each processor has a cache memory, the processes in the global run queue are listed in order of priority. Means for fetching a process into the local run queue, means for sequentially executing the process group fetched in the local run queue based on a time slice, and the process after the process group fetched in the local run queue is executed for a certain time A process dispatch system in a multiprocessor, comprising means for returning a group to the global run queue again based on priority. 2. The process dispatch method in a multiprocessor according to claim 1, further comprising means for fetching a plurality of processes sharing the same address space from among the processes in the global run queue to a local run queue.