KR940009103B1 - Mechanism for process streaming on multiprocessor environment - Google Patents

Abstract

The stream mechanism servicing the stream process scheduling, the run-que list on the multiprocessor environment and the stream input/output system calls for either parallelization or serialization mode has the first step executing read/write/getmsg/pntmsg/ioctl in parallel;the second step executing open/close/ioctl in serial which can not be paralleled; the third step making the entry point unite to manage the scheduler; the fourth step improving system performance using plural demon scheduler; the fifth step executing the ready-to-run process in the run-que with awaking up the stream scheduler; the final step reducing the run-que table managing time by classifying each process by priority.

Description

Streaming Mechanism in a Multiprocessor Environment

1 is a flowchart showing a stream structure and a message flow diagram.

2 is a flow chart showing a flow scheduler of a stream scheduler in a single processor environment.

3 is a block diagram of a stream run queue in a single processor environment.

4 is a flowchart showing a flow scheduler of a stream scheduler in a multiprocessor environment.

5 is a block diagram of a stream run queue in a multiprocessor environment.

* Explanation of symbols for main parts of the drawings

1: user process (s)

2: stream head with write and read-only queues

3: stream module (s) with write and read-only queues

4: stream driver with write and read-only queues

5: Control information and data messages moving in the downstream direction

6: Data message moving in the upstream direction

The present invention relates to a stream mechanism that operates in a multiprocessor environment with two or more processors.

Streams is not only a generic and flexible facility, but also a set of constructs for developing communication services on UNIX systems.

Streams provides a standard interface for character input and output between the Unix kernel and the rest of the Unix system. The stream consists of a head, a driver, and optional module (s), which may or may not exist as needed.

Each consists of a read-only queue, which can have services, put, open, and close procedures to process the queued messages. The service procedure functions as the flow control of the stream mechanism, and the put procedure has the ability to put a message in its own module, driver, or neighbor queue, and the open procedure opens the module or driver. Function has a function of close.

In the related art, the stream scheduling function and the system call function are operated under a single processor, and thus there is a disadvantage in that two or more processors are not used in a multiprocessor environment, and thus, system performance is not improved.

Typical examples of those using the stream function are local area networks using the Open Systems Interconnection (OSI) protocol, telecommunications networks using the X.25 protocol, and terminal drivers.

The present invention implements a stream process scheduling method and a run queue list in a multiprocessor environment among various stream functions, and provides parallelization and serislization of system calls related to stream input / output in a multiprocessor environment. It aims to provide system performance improvement.

In order to achieve the above object, stream scheduling, run queue casting, and system call are implemented in a manner different from that of a single processor.

The basic framework of scheduling for a multiprocessor environment is to ensure that runnable stream processes, if present, are run as soon as possible.

To do this, the daemon process for scheduling the stream is executed when the system is booted, and two runqueues are used instead of the stream, one for the high priority queue used for urgent control, and the other for general. Used as a queue for data processing.

In addition, in case of system call, control message or general data message from the stream head to and from the driver should be executed in parallel as independently as possible, and if it is executed in parallel, the problem is likely to occur. Make it work as a book.

The present invention will now be described in detail with reference to the accompanying drawings, in comparison with a single treatment.

1 is a simplified diagram of the basic stream structure and the flow of data and control messages after the stream is opened. When the first user process 1 opens the stream, the stream head 2 and driver 4 write queues respectively. The diary has a dedicated queue and is connected in both directions.

There are two types, depending on the direction in which the message travels, one that is downstream in the write-only direction, when the user process uses the write, putmsg, or ioctl system call. The data message 7 is moved from the head to the driver direction.

The other is to move the control message 8 or the data message 6 as a result of the movement of the data message 6 or the ioctl system call in the read-only getmsg system call.

There are two or more user processes in some cases, and two or more stream heads exist (2 and 10) depending on the driver the user opens.

In the case where the stream heads are different (2, 10), the lower drivers 4, 11 attached to each have different functions, for example, one may be a driver for local area network control and the other is terminal control. It may be a terminal driver for.

These drivers function to control the system or external hardware devices and to interface with the head 2 or module 3 on top of the driver.

As above, the stream having the structure and function is for a single processor environment, and thus the data movement, service function, and function for performing a procedure are not suitable for a multiprocessor environment.

Therefore, in the multiprocessing environment, as mentioned above, the concept of vertical parallelism and horizontal parallelism can be introduced for the service of all system calls. It was.

Service procedures and put procedures in the same queue for vertical parallelism are assigned to different handlers so that they can run concurrently. For horizontal parallelism, all procedures in different streams can run concurrently. did.

Here, different streams mean when a process head wants the stream head to be serviced through another passage 19.

To do this, we introduced the concept of spinlocks and semaphores to protect global variables and data structures, providing transparency to the user.

This is closely related to the stream scheduler and the run queue, and the detailed description thereof will be described in the introduction of the drawings (FIGS. 4 and 5) in which the stream scheduler and the run queue are modified to be suitable for a multiprocessor environment.

But here are system calls that should not be executed in parallel: open, close and some ioctls.

In the case of open, it should not be parallelized so that no two stream heads are allocated for the same driver. In the case of close, the open stream should not be closed if another process has raw data.

For some ioctls, if a process is inserting or deleting a module directly under the stream head, data movement to the neighboring module must be paused until the insertion or deletion is complete.

In this way, system calls that can be parallelized are executed at the same time, and existing stream-related system calls are modified so that the impossible can be performed in order to make the most of the multiprocessor environment.

Figure 2 shows a flow diagram in which the stream scheduler is called under a single processor for comparison with Figure 4 modified for a multiprocessor environment.

When the stream scheduler is called in a single processor environment, when there is no process that can be executed in the run queue used in process management (12) before the interrupt occurs and before the interrupt service is completed, before the interrupt occurs. 13) and through a designated Check Point 14 during system call processing.

In this case, only one scheduler runs at any one time.

The scheduler starts up differently than when called after returning from the interrupt service before returning. After the interrupt service is completed (12), if the condition is satisfied (15), the scheduler is directly driven (16), but in the other cases (13, 14), the scheduler (17, 18, 19) goes through preparation for the scheduler operation. .

In this case, the preparatory work refers to checking whether there is an executable process in the run queue waiting to be scheduled at the same time as checking whether the current scheduler is running by another process.

If the current scheduler is running or there is no stream process available in the run queue, the scheduler is not driven (20).

Therefore, the flow for stream scheduling under a single processor is not suitable for a multiprocessor system because the entry point for the scheduler is not uniformized and two schedulers are not simultaneously executed. Scheduling will be described in FIG.

Figure 3 shows a stream process related run queue list that is operated independently of run queues used in process management under a single processor.

The run queue is a unidirectional link of runnable stream processes, and has a variable 21 representing a head of a link list and a variable 22 representing a tail. Processes connected to the run queue have a higher priority toward the head (23) and a lower priority toward the tail (24).

Control messages for urgent results are inserted into the head, and when the process in the run queue is detached to run the queued process, it is removed from the front of the bottom.

Therefore, when inserting a high-priority message into the run queue, it is not a problem because it is inserted from the front, but when inserting a low-priority message, a message higher than its priority to be inserted should be searched and placed after it. Therefore, there is a case where it takes time to insert. This problem was solved with the following run-queue handling in a multiprocessor environment, which will be discussed in detail in Figure 5.

4 is a flow chart for stream scheduling under a multiprocessor.

This section focuses on the changes made for the multiprocessor as compared to FIG. 2, which is a scheduling method under a single processor. There are three distinctive changes for multiprocessing, one of which is that the entry point for driving the stream scheduler is unified (25).

The reason is that in case of single processor, there is only one processing, so even if there are two entry points, the same situation occurs. In the case of multiprocessors, if there are two or more handlers, race conditions or deadlocks may occur. Because there is a possibility.

As such, by unifying entry points, stream scheduling management can be managed systematically, and timer driving described below can be facilitated.

The entry point 25 checks whether there is a process waiting to be executed in the run queue, and in the part 26 that checks whether the scheduler driving condition is satisfied, the entry point 25 checks whether all daemon processes for scheduling are running. . Of course, do not run the scheduler when all daemon processes are running.

The second is to have more than one scheduler for scheduling stream-related processes, not one, but proportional to the number of processors (27) (two ideally for non-stream bound jobs).

In the case of a single processor, if you run the scheduler (16) (Figure 2), there is only one scheduler, and if one process is currently running the scheduler, only one scheduler is running (16) because no other process can run the scheduler. In the case of the multiprocessor, two or more schedulers may be driven according to the number of processes waiting to be scheduled in the stream run queue list (27).

In the multiprocessor, these schedulers exist as daemon processes at system boot time. If there are no processes to run, they go to sleep, and then wake up the scheduler when a wakeup condition is met by a timer, interrupt, or system call. Drive it.

When executing a process that waits to be executed in a stream run queue, a higher priority process is executed first, which will be mentioned in FIG.

Running two or more stream schedulers in this way can improve the execution time and overall system performance of the stream-related processes.

Here, Semaphore is used for synchronization when the scheduler is running.

Third, when the scheduled daemon process 27 enters sleep again (28), it sets a certain amount of time (28) so that even if it is not awakened by an external event (interrupt, system call, etc.) The process that awakens (29) waits to be scheduled and checks if it is waiting in the run queue and immediately executes it.

The introduction of the Timer concept can greatly reduce the time that stream-related processes wait on the run queue, resulting in improved system performance.

5 shows a stream related run queue structure under a multiprocessor.

In the case of a single processor, a single run queue manages high priority process lists 21 and 23 and low process lists 22 and 24 (FIG. 3) to insert low priority processes into the run queue. There was a disadvantage in that it consumes a lot of time.

However, when managing the run queue by separating the queue 30 for the high priority process and the queue 31 for the low process as shown in FIG. 5, the above disadvantage is eliminated.

If there is a high priority process 30 and the stream scheduler is running this is done immediately. The low priority process 31 is performed when no high priority process exists. Whenever you remove a waiting process from the run queue, you always detach it from the front.

When a low priority process is inserted, the run queue list for the low priority is managed separately, thereby eliminating the need for searching as in FIG. You can also maximize the advantage of having more than one scheduler by setting two queues.

As described above, the present invention provides a method for scheduling stream processes among various stream functions, a method for implementing a run queue list under a multiprocessor environment, and a third method for parallelizing and ordering stream I / O related system calls under a multiprocessor environment. It has the effect of improving the overall system performance.

Claims (1)

Introduces the concept of vertical parallelism and horizontal parallelism to perform some parallel read, write, getmsg, pntmsg and ioctl system calls and to perform some system calls in open, close and ioctl that cannot introduce parallelism. Step 2 to perform the sequence, step 3 to systematically manage the scheduler by having one entry point for running the scheduler, and two or more systems in proportion to the number of processors rather than one schedule related to the stream Step 4 to reduce the execution time of stream-related processes and improve overall system performance by placing them as daemon processes at boot-up, and the stream scheduler does not wake up solely by external events (interrupts, system calls), but instead puts tires on its own A program that wakes itself up after timeout and waits for it to run on a stream run queue. Step 5 to perform the process, and step 6 to shorten the time to insert or delete the process into the run queue by managing the stream processes to the run queue independently of each other by distinguishing between the high priority and the low priority. Streaming mechanism in a multiprocessor environment.