Linux process switch (2) synchronous processing

First, preface

This paper mainly describes the synchronous processing in the main scheduler (schedule function).

Ii. Introduction of process scheduling

There are two kinds of process switching, one is that when a process cannot continue because it needs to wait for a resource, it can only suspend itself (call the schedule function) and raise a task scheduling process. The other is that the process is preempted. The so-called preemption (preempt) is when the current process is performing happily, terminating its CPU resource usage and switching to another higher priority process execution. Process preemption is often due to the occurrence of various scheduling events:

1. Time Slice run out

2. Waking other higher priority processes in the context of interrupts

3. Awaken other higher-priority processes in the context of other processes.

4. Modify the scheduling parameters of other processes in the context of other processes

5, ...

In the scenario where the current process is preempted, scheduling does not occur immediately, but deferred execution, the specific method is to set the current process need_resched equals 1, and then silently wait for the recent dispatch point, when the dispatch point arrives, the kernel will call the schedule function, Preempt the execution of the current task.

In addition, we need to understand the basic preemption control knowledge. In the thread info of a process, there is a member of the Preempt_count to control preemption, when the member equals 0 to allow preemption, in this article we use preempt counter, HARDIRQ counter and SOFTIRQ Counter represents the bit field. A more detailed description can refer to the description of the relevant document

Iii. What synchronization mechanisms are used by the schedule function

The code framework for the schedule function is as follows:

Asmlinkage __visible void __sched schedule (void)
{
    do {
    ;     preempt_disable ();-----------------a

                 Raw_spin_lock_irq (&rq->lock);--------b

                Select Next task

                Cut to next task execution

               RAW_SPIN_UNLOCK_IRQ (&rq->lock); -------c
        sched_preempt_enable_no_resched ();--------d
    } while (need_resched ()); ---------------E
}

We describe the use of the synchronization mechanism in the schedule function as an example of the X process switching to the Y process. In the context of the X process, the a point first closes the preemption, and the X task's preempt counter adds 1. Then at B Point will hold the CPU Runqueue spinlock, of course, in this process will disable CPU interrupt processing, while the X task preempt counter again add 1, this time X task preempt counter should be equal to 2.

Open x Task preemption is when the re-Dispatch x on a CPU execution, this time, in the above code in the C and D points to decrement preempt counter, when entering the e point, preempt counter is equal to 0.

Because of the operation of switching over long design runqueue queues, it is necessary to spin lock to protect it. However, during the process switching process, runqueue spin lock is a different process to work together. We still use the X process to switch to the Y process for example. In the x process, a lock is held at point B and a local interrupt is disable, while the release of Spin lock is done in the Y process (point C), and a CPU interrupt is also turned on while releasing spin lock.

Four, can prohibit the preemption when call schedule function

is the following call sequence possible in the context of the process?

Preempt_disable

.... Schedule .....

Preempt_enable

No matter what the scene, disable preempt then call schedule is a very strange thing: Originally you have forbidden to preempt, but also show the call schedule function, you this is not schizophrenia? What does the schedule function do with this schizophrenic task? Before calling the schedule function, it is no doubt expected that preempt count equals 0, only the current task's preempt count equals 0 to justify preemption. However, during the whole process switching process, preemption is forbidden first at point A, which ensures that the relationship between the CPU and the current task is constant (the CPU is unchanged, the present task is unchanged, and the runqueue is unchanged). In this way, the call check for caller between A and B is better carried out, as follows:

static inline void Schedule_debug (struct task_struct *prev)
{

if (Unlikely (In_atomic_preempt_off ())) {
__schedule_bug (prev);
Preempt_count_set (preempt_disabled);
}
}

In_atomic_preempt_off This macro is the current preempt count test, when the correct preempt counter should be equal to 1, the other bit field, such as Softirq counter, HARDIRQ Count and so on are all 0. Specific about the preempt count of the bit field description can refer to the site soft-interrupted documents. If you do not set the correct preempt_count to call the schedule function, then the error in the atomic context of the dispatch, __schedule_bug will print out the relevant information, convenient debugging.

Although the schedule function was called in the wrong scenario, the kernel still struggled, so this would modify the value of preempt count to Preempt_disabled, which is the correct posture to enter the schedule function.

V. Can I close interrupt call schedule function?

is the following call sequence possible in the context of the process?

Local_irq_disable

.... Schedule .....

Local_irq_enable

Of course, this may not be a direct call to the schedule function, many of the kernel interface API will implicitly call the schedule function, so you may intentionally or unintentionally write the above pattern of code.

First, you need to be clear: when you switch from the x process to the Y process, if you turn off the interrupt in the X process and then switch to the y process, the y process will execute until Y's own conscience is found, yielding the CPU. This, of course, is not allowed. Therefore, when calling schedule for process switching, the interrupt is closed at point B regardless of whether the caller closes the interrupt (note that the previous interrupt state is not logged). When you cut into the Y process, the CPU interrupt is opened explicitly at point C. Therefore, the above code is not recommended, but it will not have too much impact on scheduling.

Vi. can the prohibition of interruption prohibit preemption?

The prohibition of interrupts does equal the prohibition of preemption, but does not mean that they are two identical, because during the invocation of the preempt disable---preempt enable, there is a preemption point when the preemption is opened, and the kernel control path checks the preemption here. If a preemption condition is met, the schedule function is immediately dispatched for process switching, but the local IRQ disable---local IRQ enable call does not show a preemption checkpoint, of course, the interrupt is a bit special, because once the interrupt is turned on, Then the pending interrupt will come in, and the preemption will be checked when the breakpoint is returned, but perhaps the following scenario will be powerless. The following sequence is called in the context of the process:

(1) Local IRQ disable

(2) Wake Up-level priority task

(3) Local IRQ enable

When the wake-up high priority process is dispatched to this CPU execution, it is supposed that this high-priority process should immediately preempt the current process, but this scenario cannot be done. When calling Try_to_wake_up, the need resched flag is set and the preemption is checked, but the schedule is not called immediately because of the interrupt disable, but at step (3), because there is no check preemption, The high-priority process that should have been preempted at this time will have serious scheduling delays .... Until the next preemption point arrives.

Linux process switch (2) synchronous processing