Process scheduling (iv)

Immediately after the previous article!!

(ii) preemption and process context

Context switching, which is the process of switching from one executable process to another, is handled by the Context_switch () function defined in KERNEL/SCHED.C, which mainly accomplishes two basic tasks:

?1：调用声明在asm/mmu_context.h中的switch_mm()，该函数负责把虚拟内存从上一个进程映射切换到新进程中。?2：调用声明在asm/system.h文件中的switch_to()函数，该函数负责从上一个进程的处理器状态切换到新进程的处理器状态。这包括保存，恢复栈信息和寄存器信息，还有其他任何与体系结构相关的信息，都必须以每一个进程为对象进行管理和保存。

Let's take a look at the code for the Function Context_switch ():

/* * Context_switch-switch toTheNewMm andTheNew* thread ' s register state. * * context_switch-Switch to the register status of a new mm (memory) and new process * *Static inline voidContext_switch (structRQ *rq,structTask_struct *prev,structTask_struct *next) {structMm_struct *mm, *OLDMM;    Prepare_task_switch (RQ, Prev, next);    Trace_sched_switch (RQ, Prev, next);    MM = next->mm;    OLDMM = prev->active_mm; /* * For Paravirt, the IS coupled withAn exitinchSwitch_to to* Combine the page table reload andThe 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); }ElseSWITCH_MM (OLDMM, MM, next);if(Likely (!PREV->MM))        {prev->active_mm = NULL;    rq->prev_mm = OLDMM; }/* * Since the Runqueue lock would be a released by the next * task (which was an invalid locking op butinchThe case * ofThe scheduler it ' s an obvious special-case), so we * DoAn 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 andThe stack. */switch_to (prev, Next, prev);//Switch processor State and save the processor state of the previous processBarrier (); /* * THIS_RQ must be evaluated again because Prev could have moved * CPUs since it called schedule (), thus the ' RQ '     On its stack * frame would be invalid. */Finish_task_switch (THIS_RQ (), prev);}

Let's take a holistic look at the function calls and procedures for hibernation and wakeup:

The kernel provides a need_resched variable to indicate whether the function needs to be dispatched again, and the following function is used to access and manipulate the need_resched variable.

The kernel also checks the NEED_RECHED flag when returning the user space and returning from the interrupt, and if it has been set, the kernel will invoke the scheduler before proceeding.

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

? 1: User preemption
User preemption occurs when the kernel is about to return to user space, and if the need_resched flag is set, it causes schedule () to be called.

User preemption occurs under the circumstances:
? 1: When the user space is returned from the system call
? 2: When returning user space from the interrupt handling function

2: Kernel preemption

Linux full support kernel preemption, however, because kernel preemption will have some security issues, then the kernel preemption timing is very important to determine, then when to reschedule is safe? As long as there is no lock, kernel-in can be preempted.

In order to support kernel preemption, Linux introduced the Preempt_count counter in Thread_info. The counter has an initial value of 0, and when the lock is used, the value is incremented by 1, and when the lock is released, the value is reduced by 1, and when the value is 0, the kernel can preempt. When the kernel space is returned from the interrupt, the kernel checks the need_resched flag and the Preempt_count counter. If the need_resched flag is set and the Preempt_count value is 0, the scheduler is executed.

If the preempt_count at this time is not 0, the current task holds the lock, so preemption is not secure. At this point, the kernel will return the current execution process directly from the interrupt as usual. If all locks held by the current execution process are freed and the Preempt_count value is 0, the code that releases the lock checks to see if the need_resched flag is set, and the scheduler is invoked if it is set.

Time the kernel preemption occurred:

?1：中断处理程序正在执行，且返回内核空间之前?2：内核代码再一次具有可抢占性的时候?3：如果内核中的任务显示的调用schedule()函数?4：如果内核中的任务阻塞                                   

(b): Real-time scheduling strategy
Linux offers two real-time scheduling strategies: Sched_fifo and SCHED_RR, while normal, non-real-time scheduling strategies are sched_normal. These real-time scheduling strategies are managed by a special real-time scheduler, defined in KERNEL/SCHED_RT.C.

? 1:sched_fifo

? This is a first-in, first-out scheduling algorithm that does not use time slices. Sched_fifo-level processes that are in a running state are dispatched more than any sched_normal process. Once a sched_fifo process is in an executable state, it continues to execute, and only higher-priority sched_fifo and SCHED_RR tasks can preempt the Sched_fifo task. If there are two or more sched_fifo-level processes with the same priority, they will take turns, but they will only exit when they are willing to give up the processor. As long as there is a sched_fifo-level process in progress, other lower-level processes can only wait for him to become non-operational until the opportunity is executed.

? 2:sched_rr

SCHED_RR and Sched_fifo are roughly the same, except that the SCHED_RR-level process is not continuing after exhausting the time allotted to him beforehand, i.e. SCHED_RR is a sched_fifo with time slices, which is a real-time rotation scheduling algorithm. When the SCHED_RR task runs out of his time slices, other real-time processes at the same priority are scheduled in turn. A time slice is only used to reschedule a process of the same priority. For the SCHED_FIFO process, the high-priority process always immediately preempted the low priority, but the low priority must never preempt the SCHED_RR task, even if his time slice is exhausted.

The real-time scheduling algorithm of Linux provides a soft real-time working mode. The implication of soft real-time is that the kernel dispatches the process and tries to make the process run before his limited time, but the kernel does not guarantee that the requirements of these processes can always be met.

The real-time priority range is from 0 to max_rt_prio-1. By default, Max_rt_prio is 100, so the default real-time priority range is 0-99. The nice value of the Sched_normal-level process shares this value space, and his value range is from Max_rt_prio to (MAX_RT_PRIO+40). That is, by default, the nice value from 20 to +19 corresponds directly to the real-time priority range from 100-139.

(iii): Scheduling-related system calls
Linux provides a family of system calls to manage the parameters associated with the scheduler. Let's take a look at the system call.

The Linux Scheduler provides a mandatory processor binding (processor affinity) mechanism. That is, he allows the user to force the specified "This process must be performed on these processors". This forced affinity is stored in the cpus_allowed in the TASK_STRUCT structure of the process. Each bit of the mask flag corresponds to a system-available processor. By default, all bits are set and the process can be executed on all available processors in the system. The user can set a mask for different combinations of one or more bits by sched_setaffinity (), while calling Sched_getaffinity () returns the current cpus_allowed bitmask.

Linux is called through the Sched_yield () system, providing a mechanism for the process to display the processor time to other waiting-execution processes.

Process scheduling (iv)