Linux scheduler (iii) -- Periodic scheduler and CFS

Note: Each internal function is not analyzed in detail here. If you want to understand these details, you can refer toOther CFS class APIAndThe main internal functions of CFS.
The periodic scheduler is completed by scheduler_tick in the scheduling framework: this function is triggered once every CPU clock cycle. It updates the clock and load of the running queue, then, call the periodic scheduling function of the scheduler class of the current process.

Update_rq_clock (RQ);/* update the running queue clock RQ-> clock */update_cpu_load_active (RQ);/* update the running queue load, the essence is to move the load value previously stored in the array to a backward position and record the current load to the first position of the array */curr-> sched_class-> task_tick (RQ, curr, 0 );

Let's take a look at the periodic scheduling function (task_tick_fair) of the CFS scheduler class ), this function is an encapsulation of the entity_tick group scheduling (because only the real task se runs on the CPU, and the group se does not run on the CPU, so the se parameter here is a task, and then all groups from it to the root of the group in which it is located
Se calls entity_tick), so let's take a look at the entity_tick function:

Update_curr (cfs_rq); // the execution time of the Current Se (this se can be a task or group), the virtual time, the corresponding time of the cfs_rq, and the update of statistics: curr-> exec_start = now; curr-> sum_exec_runtime + = delta_exec; and curr-> vruntime + = calc_delta_fair (); Update min_vruntime of cfs_rq. delta_exec indicates the actual execution time, while calc_delta_fair calculates the virtual time corresponding to delta_exec, that is, delta_fair = {if Se-> load. weight! = Nice_0_load return delta_exec; else return delta_exec * nice_0_load/SE. load-> weight}, you can see that when the SE is 0 priority, then its virtual time is equal to the physical time of the actual execution, otherwise, the larger the load of the SE, the smaller the virtual time, this is also why a process with a larger load can run more time-its virtual time increases slowly-update_entity_shares_tick (cfs_rq); // This function only works for SMP, so here we will not analyze # ifdef config_sched_hrtick // hrtick. I don't know why if (queued) {resched_task (rq_of (cfs_rq)-> curr); return;} If (! Sched_feat (double_tick) & hrtimer_active (& rq_of (cfs_rq)-> hrtick_timer) return; # endifif (cfs_rq-> nr_running> 1 |! Sched_feat (wakeup_preempt) // the value that can be run is greater than 1 or does not support wakeup_preempt. Later versions of this condition have removed check_preempt_tick (cfs_rq, curr ); // This function is used to check whether the current process has been running for a long enough time (the actual running time is longer than the ideal running time of sched_slice or the current waiting time of the SE on the far left of the current running queue has exceeded curr's ideal running time ), if the preceding problem occurs, call resched_task to set the process to tif_need_resched. If the running time is earlier than sysctl_sched_min_granularity) or the kernel does not allow wakeup_preempt (the scheduling feature allowed by the kernel is defined in/proc/sys/kernel/sched_features and wakeup_preempt uses 3rd bits), then the system will return directly. Note that the order of each judgment condition here is very important (more important): 1. if the process has been running longer than its ideal running time, it will be resched_task unconditionally; 2. if wakeup_preempt is not supported, the current resched_task is not directly returned; 3. if the running time is less than sysctl_sched_min_granularity, the system returns the result directly. 4. the leftmost waiting time is greater than the ideal running time when resched_task (curr), that is, if 4 is satisfied, the current execution time must be less than the ideal running time, and supports wakeup_preempt and running at least sysctl_sched_min_granularity. The waiting time is later than the ideal running time.

We can see that each clock updates the actual execution time and virtual execution time of the current running se, and finally checks whether the process is running for a long enough time, if yes, set it to tif_need_resched for the master scheduling to switch at the appropriate time. It can be seen that the periodic scheduler is relatively simple and does not involve real scheduling tasks. It just sets a flag for re-scheduling requests. Let's look at the main scheduler, that is, it is used to respond to the _need_resched of the periodic scheduler.

Figure CFS and periodic Scheduler