Process Scheduling (4): Process Scheduling

Process Scheduling (4): Process Scheduling

Next to the previous article !!

(2) preemption and process context

Context switching refers to switching from an executable process to another executable process, which is processed by the context_switch () function defined in kernel/sched. c. This function mainly performs two basic tasks:

1: Call switch_mm () declared in asm/mmu_context.h. This function is responsible for switching the virtual memory from the previous process ing to the new process. 2: Call the switch_to () function declared in the asm/system. h file. This function switches from the processor status of the previous process to the processor status of the new process. This includes saving, restoring stack information and register information, and any other information related to the architecture. Each process must be managed and saved as an object.

Let's take a look at the code of the context_switch () function:

/** Context_switch-switch to the new MM and the new * thread's register state. ** context_switch-switch to a new MM (memory) and new process * Register status */static inline voidcontext_switch (struct rq * rq, struct task_struct * prev, struct task_struct * next) {struct mm_struct * mm, * oldmm; prepare_task_switch (rq, prev, next); trace_sched_switch (rq, prev, next); mm = next-> mm; oldmm = prev-> active_mm;/** For paravirt, this Is coupled with an exit in switch_to * combine the page table reload and the switch backend into * one hypercall. */arch_start_context_switch (prev); if (likely (! Mm) {next-> active_mm = oldmm; atomic_inc (& oldmm-> mm_count); enter_lazy_tlb (oldmm, next);} else switch_mm (oldmm, mm, next ); if (likely (! Prev-> mm) {prev-> active_mm = NULL; rq-> prev_mm = oldmm ;} /** Since the runqueue lock will be released by the next * task (which is an invalid locking op but in the case * of the scheduler it's an obvious special-case ), so we * do an early lockdep release here: */# ifndef _ ARCH_WANT_UNLOCKED_CTXSW spin_release (& rq-> lock. dep_map, 1, _ THIS_IP _); # endif/* Here we just switch the register state and the stack. */switch_to (prev, next, prev); // switch the processor status and save the previous process's processor status barrier (); /** this_rq must be evaluated again because prev may have moved * CPUs since it called schedule (), thus the 'rq' on its stack * frame will be invalid. */finish_task_switch (this_rq (), prev );}

Let's take a look at the calling and process of sleep and wakeup functions as a whole:

The kernel provides the need_resched variable to indicate whether the function needs to be rescheduled. The following is a function used to access and operate the need_resched variable.

The kernel will also check the need_reched flag when the user space is returned and the return from the interrupt. If the flag has been set, the kernel will call the scheduler before the execution continues.

Each process has a need_resched flag, because the value in the access process descriptor is faster than accessing a global variable.

1: User Preemption
When the kernel is about to return to the user space, if the need_resched flag is set, schedule () will be called and user preemption will occur.

User preemption occurs in the following situations:
1: when the user space is returned from the system call
2: When the interrupt handler returns the user space

2: kernel preemption

Linux fully supports kernel preemption. However, because kernel preemption may cause some security problems, it is very important to determine the kernel preemption time. So when is the re-scheduling secure? As long as there is no lock, the kernel can be preemptible.

To support kernel preemption, The preempt_count counter is introduced in thread_info. The initial value of the counter is 0. When the lock is used, this value is incremented by 1. When the lock is released, the value is reduced by 1. When the value is 0, the kernel can be preemptible. When the kernel space is returned from the interruption, the kernel checks the need_resched flag and the preempt_count counter. If the need_resched flag is set and the value of preempt_count is 0, the scheduler will be executed.

If the value of preempt_count is not 0 at this time, it indicates that the current task holds a lock, so the preemption is insecure. In this case, the kernel will directly return the current execution process from the interruption as usual. If all the locks held by the current execution process are released and the value of preempt_count is 0, the code for releasing the lock will check whether the need_resched flag is set. If yes, the scheduler is called.

Time when kernel preemption occurs:

1: The interrupt handler is being executed, and before returning the kernel space 2: When the kernel code is preemptible again 3: If the task displayed in the kernel calls the schedule () function 4: if the task in the kernel is blocked

(2): real-time scheduling policy
Linux provides two real-time scheduling policies: SCHED_FIFO and SCHED_RR. The common non-real-time scheduling policy is SCHED_NORMAL. These real-time scheduling policies are managed by special real-time schedulers and defined in kernel/sched_rt.c.

1: SCHED_FIFO

This is a first-in-first-out scheduling algorithm, which does not use time slices. SCHED_FIFO-level processes in a running state are scheduled first than any SCHED_NORMAL process. Once a SCHED_FIFO process is executable, it will continue to be executed. Only SCHED_FIFO and SCHED_RR tasks with higher priority can seize SCHED_FIFO tasks. If there are two or more SCHED_FIFO processes with the same priority, they will take turns, but they will exit only when they are willing to give up the processor. As long as a SCHED_FIFO-level process is being executed, other low-level processes can only be executed after it becomes unavailable.

2: SCHED_RR

SCHED_RR and SCHED_FIFO are roughly the same, but SCHED_RR-level processes are not executed after the time allocated to them is exhausted. That is to say, SCHED_RR is SCHED_FIFO with time slices, this is a real-time rotation scheduling algorithm. When the SCHED_RR task consumes its time slice, other real-time processes with the same priority are scheduled in turn. The time slice is only used to reschedule processes with the same priority. For SCHED_FIFO processes, high-priority processes always seize low-priority tasks immediately, but low-priority processes cannot seize SCHED_RR tasks, even if their time slice is exhausted.

Linux's real-time scheduling algorithm provides a soft real-time working method. Soft Real-time means that the kernel schedules a process and tries its best to run it before its limited time arrives, but the kernel cannot always meet the requirements of these processes.

The real-time priority ranges from 0 to MAX_RT_PRIO-1. By default, MAX_RT_PRIO is 100, so the default value range of real-time priority is 0-99.SCHED_NORMAL. nice values of processes share this value space, the value range is from MAX_RT_PRIO to (MAX_RT_PRIO + 40 ). That is to say, by default, the nice value ranges from-20 to + 19, which directly corresponds to the real-time priority range from 100-139.

(3) scheduling-related system calls
Linux provides a system invocation family for managing parameters related to the scheduler. Next let's take a look at the system call.

The Linux scheduler provides a processor affinity mechanism. That is to say, he allows users to forcibly specify that the process must be executed on these processors. This forced affinity is stored in the cpus_allowed mask in the task_struct structure of the process. Each bit of the mask identifier corresponds to a processor available in the system. By default, all bits are set and processes can be executed on all available processors in the system. You can use sched_setaffinity () to set different masks for one or more bits, and call sched_getaffinity () to return the current cpus_allowed mask.

Linux uses the sched_yield () system to call sched_yield (). It provides a mechanism for the process to display the processor time to other waiting processes.