Linux Kernel scheduling mechanism

Linux Kernel scheduling mechanism

Preemptible and non-preemptible kernels
Relationship between preemptible Linux kernel and Real-Time System

A good system process scheduling mechanism must meet the requirements of three different applications:

1. Interactive applications. This application focuses on the system response speed. When a large number of processes coexist in the system (multiple users), each user must have an acceptable response speed, without obvious latency. When the latency exceeds 150 milliseconds, the user will obviously feel it.

2. batch processing application. Batch Processing applications are often "back-end jobs" with no requirements for response speed, but the "average speed" must be taken into account"

3. Real-time applications. This is the most time demanding. We should not only consider the average speed of process execution, but also the "Instant Speed". We should not only consider the response speed (from an event to the system to respond to this, and start to execute the time required between the degree of relevance), but also consider whether the relevant program (Note program) can be completed within the specified time. In real-time applications, we focus on the "predictability" of program execution ".

When designing a process scheduling mechanism, consider the following issues:

1. Scheduling time: under what circumstances and when? [Under what circumstances and when to replace the CPU-consuming process. Where to call the schedule function]

2. "policy" policy: select the next running process based on the criteria. [Find a process in the running process queue to occupy the CPU and run it ].

3. Scheduling Method: "preemptive" or "nonpreemptive ). [A process proactively gives up the CPU. The process calls schedule in the user or kernel state. The other is to forcibly deprive the process of its right to use. In the event of interruptions, exceptions, or system calls, schedule is called by the kernel on the eve of kernel state return to user State.]

Scheduling time:

Voluntary

1. In the kernel, the process can start a scheduling by Schedule () or schedule_timeout. You can call pause () or sleep (s) in the user space. [This is a visible method of active delivery. This means that the programmer can see that the programmer voluntarily gives way during programming .]

2. When you use open (), read (), write (), and more than N system calls involving peripherals, they may all be blocked. In this case, it is invisible to voluntarily give up running in the kernel. [The programmer thinks it is blocked. In fact, it is to let the CPU out, enter the waiting queue, wait for a signal, soft interruption, or hardware interruption]

It is not voluntary, that is, it occurs forcibly on the eve of each return from the system call, and on the eve of every return from the interruption or exception handling to the user space. Note: It is critical to return to the user space. This means that scheduling is only triggered when the user space (when the CPU is running in the user space) is interrupted or an exception occurs. (Interruptions or exceptions in the kernel space do not cause scheduling. Linux2.4)

[In this way, we are often referred to as "non-preemptible kernel" or "User preemption ". In fact, it can only be called "semi-preemptible kernel" or "Conditional preemption ". This method is implemented in linux2.4. This was modified in linux2.6. We are used to calling the linux2.6 kernel "preemptible kernel ".]

Preemptible Kernel

The following is an English description of "preemptible kernel.

Kernel preemption is a method used mainly in monolithic and hybrid kernels where all or most device drivers are run in kernel space, whereby the scheddevice is permitted

Forcibly perform a context switch (ie, preemptively schedule; on behalf of a runnable and higher priority process) on a driver or other part of the kernel during its execution,

Rather than co-operatively wait for the driver or kernel function (such as a system call) to complete its execution and return control of the processor to the schedvel.

There are two main benefits to this method in monolithic and hybrid kernels, and answer one of the main criticisms of monolithic kernels from microkernel advocates,

Which is that;

1 A device driver can enter an infinite loop or other unrecoverable state, crashing the whole system

2 Some drivers and system cballs on monolithic kernels are slow to execute, and can't return control of the processor to the schedute or other program until they complete

Execution.

Source: http://en.wikipedia.org/wiki/Kernel_preemption

Understanding of "non-preemptible kernel" and "preemptible kernel.

When we see these two terms, the first thing we feel is that this is a kernel with different scheduling methods. After some knowledge, I found some problems with this understanding. The meaning of "non-preemptible kernel" is that the scheduling mode of the kernel state cannot be preemptible. Of course, this method is related to kernel implementation, but it focuses on what kind of scheduling method. ForKernel preemptionWe can translate it into "kernel preemptive scheduling mode" or "preemptible kernel scheduling mode ".

Differences between preemptible and semi-preemptible kernels

Linux2.4 only implements conditional preemptible scheduling. Its disadvantage is that the scheduling time is limited when the process is in the kernel state. Only on the eve of XXX. For example, when an external interruption occurs and the program is interrupted, a user process B needs to process the process (response to IP packet data ). Process a enters the kernel state using the system call. Then, when a is returned from the system call, it is possible for B to run only when the kernel is scheduled. Assume that the CPU usage of System Call A is T. This T is later than the response time required by the user. The system is not real-time enough.

To improve the real-time performance of Linux. Introduced in linux2.6"Kernel preemption (kernel preemption scheduling mode). This problem is well solved. In a word, the preemptible kernel can be preemptible when the process is in the kernel state.

Of course, preemptible kernels cannot be preemptible in the following situations:

1. When the kernel runs the interrupt handler and exception handler, the process in the Linux Kernel cannot preemptively interrupt, and scheduling is not allowed in the Interrupt Routine. Schedule, a process scheduling function, determines whether an error is returned if it is called during an interruption.

2. When a process runs code in the critical zone in the kernel state, it cannot be preemptible. These critical sections are protected by the spin lock spin_lock. [However, when a process uses a spin_lock and is locked and spin, it can be scheduled .]

3. When the kernel is processing bottom half (the bottom half of the interrupt), it cannot be preemptible. [Do not understand]

4. When the kernel is executing the scheduler, it cannot be preemptible.

5. When the kernel is operating on each CPU "private" data structure (per CPU date structures), it cannot be preemptible. In SMP, the per-CPU data structure is not protected by spinlocks because these data structures are implicitly protected.

When and where does the preemptible kernel call the schedule function?

When an interrupt occurs and the interrupt processing is completed, you can schedule it as needed when returning the previously interrupted process.

The preempt_count variable is introduced to the task_struct structure of each process in the preemptible kernel, which is called the kernel preemptible lock. When a process enters the preceding five states, preempt_count plus 1 indicates that it cannot be preemptible. When you exit the preceding five statuses, preempt_count is reduced by 1. Each time you perform preemptible scheduling, you must first determine the preempt_count and 0 values. preempt_count <0 indicates that preemptible is supported. Preempt_count> 0 indicates that it cannot be preemptible.

Preemptible scheduler function: preempt_schedule; preempt_schedule_irq. Schedule is called to complete scheduling.

Relationship between real-time operating system and preemptible Kernel

The real-time operating system requires that requests from external sources be processed in a timely manner. To what extent is the real-time operating system? This is not clearly defined, because the user's requirements for response time are different.

We can say that in the same hardware conditions, the real-time performance of linux2.4 is not high, or the real-time performance of linux2.6 is not as high. There are many ways to improve the system's real-time performance, increase the CPU speed and increase the CPU core. Optimize the operating system. Therefore, the important contribution of Linux in improving the system's real-time performance is the introduction of the "kernel preemptive scheduling mode ". We can also say that Linux supports real-time performance.

References:

1 Linux kernel preemption Analysis

Http://wenku.baidu.com/view/835905768e9951e79b89272f.html

2 preemptible Linux Kernel

Http://www.yuanma.org/data/2008/0508/article_3037.htm

3. Research and Implementation of Linux preemptible Kernel

Http://www.docin.com/p-74007197.html

4. Differences between preemptible and non-preemptible kernels

Http://hi.baidu.com/zhangkai008/blog/item/eee55d208f420e49ad34de87.html

5. Linux kernel Scenario Analysis

Note: This article references a large number of other online articles and some papers. Therefore, this post can only be reprinted.