Shulou(Shulou.com)06/01 Report--

How to analyze the timing of Linux process scheduling, in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

How Linux is scheduled in many processes, which involves the concept of Linux process scheduling timing, the function of Schedule () in the Linux kernel determines whether to switch processes, if so, which process to switch to, and so on.

The main timing of Linux process scheduling is:

1. The moment of process state transition: process termination, process sleep

2. When the time slice of the current process runs out (current- > counter=0)

3. Device driver

4. When a process returns to the user state from interrupts, exceptions, and system calls

Opportunity 1, the process will call functions such as sleep () or exit () for state transition, and these functions will actively call the scheduler to schedule the process.

Timing 2, because the time slices of the process are updated by clock interrupts, this is the same as timing 4.

Opportunity 3, when the device driver executes a long and repetitive task, the scheduler is called directly. In each iteration, the driver checks the value of need_resched and, if necessary, calls the scheduler schedule () to actively abandon CPU.

Timing 4, as mentioned earlier, whether it is returned from an interrupt, exception, or system call, eventually calls ret_from_sys_call (), which detects the scheduling flag and, if necessary, calls the scheduler. So why call the scheduler when you return from the system call? This is, of course, in terms of efficiency. Returning from the system call means leaving the kernel state and returning to the user state, and the state transition takes a certain amount of time, so the system does all the things that should be handled in the kernel state before returning to the user state.

We will not discuss the timing of executing the scheduler directly, because we will describe the working process of the scheduler later. Earlier, we discussed clock interrupts and knew the important role of clock interrupts. Let's take a brief look at what the kernel does when each clock interrupt occurs. First of all, we have a general understanding of this most frequent scheduling time. Then we will discuss the specific working process of the scheduler in detail.

When each clock interrupt (timer interrupt) occurs, three functions work together to complete the process selection and switching, they are: schedule (), do_timer () and ret_form_sys_call (). Let's first explain these three functions:

Schedule (): process scheduling function, which completes process selection (scheduling)

Do_timer (): temporarily called a clock function, this function is called in the clock interrupt service program and is the main component of the clock interrupt service program. The frequency at which this function is called is the frequency of clock interrupts per second (100Hz or 100Hz).

Ret_from_sys_call (): the system call returns the function. When a system call or interrupt is completed, this function is called to handle some finishing touches, such as signal processing, core tasks, and so on.

How do these three functions work together?

As we saw earlier, the clock interrupt is an interrupt service program, and its main component is the clock function do_timer (), which updates the system time and the process time slice, and the updated process time slice counter serves as the main basis for scheduling.

When the clock interrupt returns, call the function ret_from_sys_call (), which we discussed earlier, with the following lines:

Cmpl $0, _ need_resched

Jne reschedule

……

Restore_all:

RESTORE_ALL

Reschedule:

Call SYMBOL_NAME (schedule)

Jmp ret_from_sys_call

The meaning of these lines is clear: detect the need_resched flag, and if the flag is non-zero, then go to reschedule and call the scheduler schedule () to select the process. The scheduler schedule () selects the next process that should run in the run queue according to the specific criteria. When returning from the scheduler, if it is found that another scheduling flag is set, the scheduler is called again until the scheduling flag is 0. At this time, the environment of the selected process is restored by RESTORE_ALL when returning from the scheduler, and the environment of the selected process is returned to the user space of the selected process to run.

The above is the most frequent scheduling time for clock interruptions. The main purpose of this discussion is to give the reader a general understanding of timing 4.

* to be clear, the system call return function ret_from_sys_call () is the function that is usually called from the system call, exception, and interrupt return function, but it is not necessary to call. For those interrupt request signals that need to be responded frequently and processed as soon as possible, in order to reduce system overhead, ret_from_sys_call () is not called after processing (because obviously The user space returned from these interrupt handlers must be the interrupted process without re-selection, and they should do as little work as possible because the frequency of response is too high.

Linux process scheduling is different from other UNIX process scheduling, especially in the processing of "nice level" priority. Unlike priority scheduling (priority high-level processes * running), Linux uses time slice round robin scheduling (Round Robing), but at the same time ensures that high-priority processes run fast and both sooner and longer. Standard UNIX schedulers use multi-level process queues. Most implementations use second-level priority queues: a standard queue and a real-time ("real time") queue. In general, if the processes in the real-time queue are not blocked, they are executed before the processes in the standard queue, and the processes with high "nice level" are executed first in each queue.

Overall, Linux scheduling routines perform well in terms of interactivity, of course, at the expense of some "throughput".

This is the answer to the question about how to analyze the timing of Linux process scheduling. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.