KR19990032701A - How to port Unix device drivers - Google Patents

Abstract

According to the present invention, when performing device driver porting of an operating system conforming to the concept of UNIX or UNIX device driver, the maximum load of the job queue step is the message interface limit in order to eliminate the process overhead due to the concentration of wait states. Designing not to exceed the load; The flow control mechanism is inserted into the kernel driver's job queue to maximize the performance by maximizing the parallelism on the auxiliary driver's I / O path, and using the level control technique, the flow rate of the job queue is based on the capacity of one device. Setting the maximum flow amount to prevent a waiting state on the message interface; This is done by resolving the system hang when placing the message interface at the bottom of the job queue, and by creating a daemon process to enable batch processing in consideration of event synchronization and not being part of the interrupt handler. It is.

Description

How to port Unix device drivers

The present invention relates to an algorithm design technique for device driver porting of an operating system that conforms to the concept of UNIX or UNIX device driver. In particular, the load inevitably encountered in a system in which resource elements limited to the original design must be added. The present invention relates to a UNIX device driver porting method that enables the parallelism and performance of a driver by blocking concentration and waiting state concentration.

When porting Unix to a system with a processor dedicated to I / O, the device driver must include code that conforms to the system's board-to-board messaging mechanism. This part requires careful design because it is not only an issue when porting a device driver, but can also be an important factor in determining the performance of the system.

Market-leading Unix systems are oriented towards open architectures, with one source code form offering multiple standards and different scalability. The device driver, which has the most porting content, should also be developed in accordance with the driver-kernel and driver-device standards in this respect. The general structure of the device driver is illustrated in FIG.

When porting such a structure to a multiprocessor structure using limited message delivery resources as shown in FIG. 3, the key point of porting is how to separate the structure as shown in FIG. 1 and properly distribute it to the kernel driver 30B and the auxiliary driver 30D. The problem is how to design and insert the message interfaces 31A and 31B at which position.

Here, a disk driver driven by using hardware protocols such as board-to-board interrupts and a software message data structure in a shared area is shown as an example of a general multiprocessor without a fully dedicated protocol for message delivery in hardware. In the case of such a structural change design, three problems generally affect performance as follows.

First, even if the message interfaces 31A and 31B are inserted at any point of the device, the concentration of the waiting state for the message resources cannot be avoided, and thus, the process transition overhead becomes large, resulting in a bottleneck. Some journaling file systems, etc., may not have this problem because they adjust their own I / O requests, but raw I / O and most file systems do not have this capability. Therefore, this problem must be found in the device driver itself.

Second, the job queue 13, which is a job queue, is a part of the source code that can be used as it is in the process of porting, and may be deleted by the kernel driver 30A when the port is moved to the auxiliary driver 30D area of FIG. have. However, it is not desirable to delete this part because the general porting tendency is to comply with the original code, and I / O flow control is possible through the operation of the job queue 13. The problem is a structural problem shown in FIG. 2. Usually, a driver creates a data structure for each physical device and manages a job in the form of an active queue. It may be introduced. However, whatever method is used, it should be designed to reflect the size and operation structure of the message system 30C corresponding to the shared area. Therefore, this part also needs to be redesigned by inserting a technique corresponding to the target system.

Lastly, as shown in FIG. 2, disk_strategy () in charge of I / O requests processes only one job each time it is called to avoid response time because the next event synchronization is required. In addition, disk_intr () is basically interrupt masked due to the property of an interrupt handler, so it cannot occupy a long time. Therefore, only one job is processed. As a result, there is no part that can be expected to improve performance by the bundle process. In order to solve this problem, the structure of the disk job queue and the operation structure design of the upper part of the kernel driver 30B in charge of its operation must be changed.

As described above, in the conventional UNIX device driver porting technology, when a driver is divided into two and an interface for message exchange is added in the middle, the standby state is concentrated around the message interface, and the load is not distributed. The system's performance was degraded due to the lack of bundle processing, which is a performance vulnerability of the driver itself.

Accordingly, the technical problem to be achieved by the present invention is to use a job queue structure in order to eliminate the overhead of process management by concentration of the standby state, and to maximize the performance by maximizing the parallelism on the input / output path of the auxiliary driver. It is to provide a Unix device driver porting method that inserts a flow control mechanism into the kernel driver's job queue and creates a daemon process to enable batch processing.

1 is a structural diagram of a disk device driver according to the prior art.

2 is a diagram illustrating a job queue structure and an operation mechanism of a disk driver according to the prior art.

3 is a structural diagram of an implanted disk driver.

4 is an explanatory diagram of the job queue structure and operation mechanism of the disk driver according to the present invention;

5A is a signal flow diagram of a disk strategy routine in accordance with the present invention.

5b is a signal flow diagram of a disk restart routine according to the present invention;

*** Description of the symbols for the main parts of the drawings ***

11: Basic Kernel 12: Disk Driver Entry Point

13: Job queue 14: I / O bus driver

15: physical I / O bus 30A: kernel

30B: Kernel Driver 30C: Message System

30D: Auxiliary Driver 31A, 31B: Message Interface

32: mini-kernel 33: message pool

Unix device driver porting method for achieving the object of the present invention comprises the steps of designing such that the maximum load of the job queue step does not exceed the message interface limit load in order to eliminate the process overhead due to the concentration of the standby state; The flow control mechanism is inserted into the kernel driver's job queue to maximize the performance by maximizing the parallelism on the auxiliary driver's I / O path, and using the level control technique, the flow rate of the job queue is based on the capacity of one device. Setting the maximum flow amount to prevent a waiting state on the message interface; When the message interface is placed at the bottom of the job queue, the daemon process is created to allow for batch processing in consideration of a system hang problem and a process that is not connected to event synchronization and is not part of an interrupt handler. Referring to Figures 3 to 5 attached to the operation of the present invention in detail as follows.

First, when the basic kernel 11 of FIG. 3 makes an I / O request through a function registered in the disk driver entry point 12, the upper routine of the kernel driver 30B except for event synchronization for some data matching. Most of the time, you can enter a wait state for events related to memory allocation. The former case is related to a special request that does not occur frequently, so no waiting state concentration occurs. The latter case uses the same memory allocation mechanism as the basic kernel 11, so subsequent requests are also blocked when memory resources are exhausted. As a result, no concentration of standby state occurs.

However, if the same memory allocation mechanism is used for the message pools 33 constructed in the shared area utilizing the system memory, the response time for the memory allocation of the driver in order to allocate the physically contiguous memory is increased. Longer problems arise. This is also difficult to design, because the kernel driver 30B and the secondary driver 30D must share the same MMU table to allow physically non-contiguous memory allocation, and in this case, the average response time is also long. none.

Therefore, the message pool 33 is generally composed of limited resources allocated in advance and designed to enter a standby state when the allocated resources are insufficient. The kernel driver 30B receives a message from the message pool 33, connects to a message data structure, and transmits a signal to the auxiliary driver 30D. After receiving the signal, the auxiliary driver 30D performs the operation by referring to the corresponding message and transmits the signal to the kernel driver 30B again. At this time, whether the message return subject is the kernel driver 30B or the auxiliary driver 30D is a design option and it is preferable to support both methods.

The level control for each queue with a separate disk data structure for each disk not only takes care of the disk throughput, but also overloads the resources of the message pool 33 with other disks. It also prevents starvation, which prevents the I / O flow of the disks from running smoothly, which greatly affects the overall performance of the system.

4 illustrates a structure of a job queue 13 of a disk driver and a driving mechanism thereof, and detailed flowcharts of disk_strategy () and disk_restart () are shown in FIGS. 5A and 5B. Since the contents of FIGS. 5A and 5B have a close correlation with the job queue 13 driving mechanism of FIG. 4, these will be collectively described.

First, a job queue 13 is allocated to each physical disk and set in a data structure called a disk. Each job is connected in the form of a linked list. The new request is connected to the tail of the list, and is taken from the head of the list when the request job is requested to the subordinate driver 30D. Each list takes into account the actual processing capacity of the disk and also takes into account the realistic maximum load of the system and the message system capacity to apply watermark control techniques to requests to the secondary driver 30D.

The disk_strategy () routine shown in the upper part of FIG. 4 performs I / O requests from the kernel 30A and performs both the operation of inserting a job into the queue and the operation of detaching from the queue, and the disk_restart ( ) Removes the job from the queue and performs only one-way jobs that request only the auxiliary driver 30D.

As shown in the disk_strategy signal flow diagram of FIG. 5A, when an I / O request from the kernel 30A occurs, the data structure such as a file system is checked if necessary, and the job data after checking the suitability of the logical and physical ranges. Takes a structure and attaches it to a disk queue. Investigate whether the number of jobs requested from the disk queue to the auxiliary driver 30D is greater than or equal to HWM (High_Water_Mark). The message is allocated and the necessary information from the contents of the job is written in the message and transmitted to the auxiliary driver 30D.

In other words, disk_strategy () may make one auxiliary driver 30D request for one I / O request, or it may update only the job queue 13 and do not make any request. We need an engine to ensure that it can be delivered as a work request, which is what Unix device drivers do for the interrupt handler. However, in Unix's design there is another rule that an interrupt handler must not enter a wait state, so in this architecture, which must be designed to allow a message to be allocated and enter a wait state, the engine cannot be placed in an interrupt handler.

To solve this problem, design a daemon process. First, the number of daemons matches the number of disk data structures to reduce the size of the engine and dynamically create the first time the disk is opened to prevent unnecessary engine creation. The name of the daemon is called disk_restart, which is shown in FIG. 5B.

The parent of disk_restart () must be created to be a system process, that is, process 0, to prevent the infinite waiting state of the user processor causing the creation. If disk_restart () is created as a kernel thread of a system process like this, the function can be performed with minimal performance overhead. As soon as it executes, disk_restart () enters the standby state and wakes up from the disk interrupt handler disk_intr (). It wakes up only when the number of I / O jobs requested by the auxiliary driver is below low_water_mark. This wakes up disk_restart (), which removes the jobs waiting in the disk queue one by one until the number of I / O jobs in the auxiliary driver becomes high_water_mark again or until there are no more jobs to run. Repeat to enter the standby state again. In this way, the kernel driver 30B can bundle the I / O requests, the amount of which is determined by the size of high_water_mark-low_water_mark. Moreover, this driver architecture is well-balanced for one-to-one requests by disk_strategy () and bundle requests by disk_restart (), which emphasizes the former when the I / O load is relatively small and the latter when the load is heavy. You will have multiple I / O responsiveness.

As described in detail above, the present invention solves the problem of portability performance when inserting an interface by a limited resource such as a message into a device driver of Unix. The parallelism of the O flow is improved and it can contribute to the performance of the system. This technique is also adaptable to other Unix device drivers other than disks. In particular, the daemon process's bundle handling techniques associated with job queue flow control apply to all Unix systems regardless of the architecture of the illustrated system, with or without a message interface. There is an effect that becomes possible.

Claims (4)

Designing such that the maximum load of the job queue step does not exceed the message interface limit load in order to eliminate the process overhead due to concentration of waiting states; The flow control mechanism is inserted into the kernel driver's job queue to maximize the performance by maximizing the parallelism on the auxiliary driver's I / O path, and using the level control technique, the flow rate of the job queue is based on the capacity of one device. Setting the maximum flow amount to prevent a waiting state on the message interface; It solves the system hang problem when the message interface is located at the bottom of the job queue, and creates the daemon process to enable the batch processing considering that it is not connected to the event synchronization process and is not part of the interrupt handler. UNIX device driver porting method. 2. The job queue of claim 1, wherein a job queue is allocated for each physical disk and set up in a data structure called disk, each job is connected in the form of a linked list, new requests are connected to the tail of the list, and a subordinate driver underneath the request job. The request is taken from the head of the list, and each list takes into account the actual processing capacity of the disk, and also applies the level control technique to the request to the auxiliary driver considering the system's realistic maximum load and message system capacity. Unix device driver porting method, characterized in that. 3. The job queue of claim 1, further comprising: a disk strategy (disk_strategy ()) routine for performing both a job of inserting a job into the queue and a job of removing from the queue; A method for porting a Unix device driver, comprising: a disk restart (disk_restart ()) routine that performs only a one-way operation by requesting an auxiliary driver from a queue. The method of claim 1, wherein when creating a daemon process, the number of daemons matches the number of disk data structures to reduce the size of the engine, and dynamically creates the first disk to prevent unnecessary engine generation. Unix device driver porting method, characterized in that.