The process scheduling time for Linux (when the schedule function is invoked) __oracle

How Linux is scheduled in many processes, this involves the Linux process scheduling concept, the Linux kernel in the schedule () function to determine whether the process to switch, if you want to switch, switch to which process and so on.

The timing of Linux process scheduling is mainly as follows:

1, the process of state transition time: Process termination, process sleep;

2. The time slice of the current process is run out (current->counter=0);

3. Device driver

4, the process from interrupts, exceptions and system calls to return to the user state;

Time 1, the process to call the sleep () or exit () functions such as state transitions, these functions will actively invoke the scheduler for process scheduling;

Time 2, because the time slice of the process is updated by the clock interrupt, so this situation is the same as timing 4.

Timing 3, call the scheduler directly when the task is repeated by the device driver. In each recurring loop, the driver checks the value of the need_resched and, if necessary, invokes the scheduler schedule () to voluntarily discard the CPU.

Timing 4, as mentioned before, whether from interrupts, exceptions, or system calls, eventually calls Ret_from_sys_call (), which detects the dispatch flags, and invokes the scheduler if necessary. So, why do you call the scheduler when you return from a system call? This is of course from efficiency considerations. Returning from the system call means leaving the kernel state and returning to the user state, while the state conversion takes a certain amount of time, so before returning to the user state, the system will complete all the things that should be done in the kernel state.

We do not discuss the timing of executing the scheduler directly, as we will describe the scheduler's work process later. Before we discussed the clock interrupt, know the important role of clock interruption, we will briefly look at each clock interrupt when the kernel to do the work, first of all the most frequent scheduling time has a general understanding, and then detailed discussion of the scheduling process of the specific work process.

When each clock interrupt (timer interrupt) occurs, three functions work together to complete process selection and switching, which are: Schedule (), Do_timer (), and Ret_form_sys_call (). Let's explain these three functions first:

Schedule (): Process scheduling function, by which to complete the process of selection (scheduling);

Do_timer (): For the time being called the clock function, which is called in the clock Interrupt service program, is the main component of the clock Interrupt service program, the frequency that the function is called is the clock interrupt frequency namely 100 times per second (abbreviation 100 Hz or 100HZ);

Ret_from_sys_call (): System call return function. When a system call or interrupt completes, the function is invoked to handle some finishing work, such as signal processing, core tasks, and so on.

How do these three functions work in coordination?

Before we see, the clock interrupt is a interrupt service program, its main component is the clock function Do_timer (), by this function completes the system time update, the process time slice's update and so on work, the updated process time slice counter as the main basis for the dispatch.

To invoke the function Ret_from_sys_call () when the clock is returned, we have discussed this function in the preceding line, and in this function there are several lines:

Cmpl $, _need_resched

Jne Reschedule

......

Restore_all:

Restore_all

Reschedule:

Call Symbol_name (Schedule)

JMP Ret_from_sys_call

The meaning of these lines is obvious: detect the need_resched flag, if this flag is not 0, then go to reschedule to call the Scheduler schedule () for process selection. The Scheduler schedule () selects the next process that should run in the run queue according to the specific criteria. When returned from the scheduler, if a dispatch flag is found to be set, then the scheduler is invoked until the dispatch flag is 0, at which point the environment of the selected process is restored by Restore_all from the scheduler and returned to the user space of the selected process to enable it to run.

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

In addition, the tif_need_resched setting time:

There are two functions to set this flag: Resched_task (), set_tsk_need_resched (). The main is resched_task, and Resched_task caller Check_preempt_curr is through: Try_to_wake_up/wake_up_new_task/pull_task/__migrate_task These widely used functions, thus distributing in the kernel a large number of checkpoints that have the opportunity to preempt processes.

Finally, the system call return function Ret_from_sys_call () is a function that is usually called from system call, exception, and interrupt return functions, but it is not necessarily called, and for those interrupt request signals that are to be frequently answered and processed as soon as possible, in order to reduce system overhead, Ret_from_sys_call () is not invoked when processing is complete (since it is clear that the user space returned from these interrupt handlers is definitely the interrupted process, no need to be selected), and that they do as little as possible because the response frequency is too high.

Linux process scheduling differs from other UNIX process scheduling, especially in the "nice level" prioritization process, unlike priority scheduling (the priority process runs first), Linux uses a time slice rotation schedule (Round robing), But it also ensures that high-priority processes run fast and long (both sooner and longer). The standard UNIX Scheduler uses a multi-level process queue. Most implementations use a level two priority queue: a standard queue and a real-time ("Real Time") queue. Typically, if a process in a live queue is not blocked, they are executed before the process in the standard queue, and the "nice level" process in each queue is executed first. Overall, the Linux scheduling process has performed well in interactivity, and, of course, at the expense of a portion of "throughput".