Linux-进程的管理与调度18(基于6.1内核)---Linux核心调度器scheduler_tick、主调度器schedule
一、 周期性调度器
周期性调度器在scheduler_tick中实现. 如果系统正在活动中, 内核会按照频率HZ自动调用该函数. 如果没有近曾在等待调度, 那么在计算机电力供应不足的情况下, 内核将关闭该调度器以减少能耗. 这对于嵌入式设备或者手机终端设备的电源管理是很重要的。
1.1、 周期性调度器主流程
scheduler_tick函数定义kernel/sched/core.c有两个主要任务:
-
更新相关统计量
管理内核中的与整个系统和各个进程的调度相关的统计量. 其间执行的主要操作是对各种计数器+1。
-
激活负责当前进程调度类的周期性调度方法
检查进程执行的时间是否超过了它对应的ideal_runtime,如果超过了,则告诉系统,需要启动主调度器(schedule)进行进程切换。(注意thread_info:preempt_count、thread_info:flags (TIF_NEED_RESCHED))。
/*
* This function gets called by the timer code, with HZ frequency.
* We call it with interrupts disabled.
*/
void scheduler_tick(void)
{
int cpu = smp_processor_id();
struct rq *rq = cpu_rq(cpu);
struct task_struct *curr;
struct rq_flags rf;
unsigned long thermal_pressure;
u64 resched_latency;
if (housekeeping_cpu(cpu, HK_TYPE_TICK))
arch_scale_freq_tick();
sched_clock_tick();
rq_lock(rq, &rf);
curr = rq->curr;
psi_account_irqtime(rq, curr, NULL);
update_rq_clock(rq);
thermal_pressure = arch_scale_thermal_pressure(cpu_of(rq));
update_thermal_load_avg(rq_clock_thermal(rq), rq, thermal_pressure);
curr->sched_class->task_tick(rq, curr, 0);
if (sched_feat(LATENCY_WARN))
resched_latency = cpu_resched_latency(rq);
calc_global_load_tick(rq);
sched_core_tick(rq);
task_tick_mm_cid(rq, curr);
rq_unlock(rq, &rf);
if (sched_feat(LATENCY_WARN) && resched_latency)
resched_latency_warn(cpu, resched_latency);
perf_event_task_tick();
if (curr->flags & PF_WQ_WORKER)
wq_worker_tick(curr);
#ifdef CONFIG_SMP
rq->idle_balance = idle_cpu(cpu);
trigger_load_balance(rq);
#endif
}
1.2、 更新统计量
|
函数 |
描述 |
|
update_rq_clock |
处理就绪队列时钟的更新, 本质上就是增加struct rq当前实例的时钟时间戳 |
|
update_cpu_load_active |
负责更新就绪队列的cpu_load数组, 其本质上相当于将数组中先前存储的负荷值向后移动一个位置, 将当前就绪队列的符合记入数组的第一个位置. 另外该函数还引入一些取平均值的技巧, 以确保符合数组的内容不会呈现太多的不联系跳读. |
|
calc_global_load_tick |
跟新cpu的活动计数, 主要是更新全局cpu就绪队列的calc_load_update |
1.3、 激活进程所属调度类的周期性调度器
由于调度器的模块化结构, 主体工程其实很简单, 在更新统计信息的同时, 内核将真正的调度工作委托给了特定的调度类方法。
内核先找到了就绪队列上当前运行的进程curr, 然后调用curr所属调度类sched_class的周期性调度方法task_tick。
即:curr->sched_class->task_tick(rq, curr, 0);
task_tick的实现方法取决于底层的调度器类, 例如完全公平调度器会在该方法中检测是否进程已经运行了太长的时间, 以避免过长的延迟, 注意此处的做法与之前就的基于时间片的调度方法有本质区别, 旧的方法我们称之为到期的时间片, 而完全公平调度器CFS中则不存在所谓的时间片概念.
目前我们的内核中的3个调度器类struct sched_entity, struct sched_rt_entity, 和struct sched_dl_entity dl, 我们针对当前内核中实现的调度器类分别列出其周期性调度函数task_tick
* 如果当前进程是完全公平队列中的进程, 则首先根据当前就绪队列中的进程数算出一个延迟时间间隔,大概每个进程分配2ms时间,然后按照该进程在队列中的总权重中占得比例,算出它该执行的时间X,如果该进程执行物理时间超过了X,则激发延迟调度;如果没有超过X,但是红黑树就绪队列中下一个进程优先级更高,即curr->vruntime-leftmost->vruntime > X,也将延迟调度。
延迟调度的真正调度过程在:schedule中实现,会按照调度类顺序和优先级挑选出一个最高优先级的进程执行。
- 如果当前进程是实时调度类中的进程:则如果该进程是SCHED_RR,则递减时间片[为HZ/10],到期,插入到队列尾部,并激发延迟调度,如果是SCHED_FIFO,则什么也不做,直到该进程执行完成。
如果当前进程希望被重新调度, 那么调度类方法会在task_struct中设置TIF_NEED_RESCHED标志, 以表示该请求, 而内核将会在接下来的适当实际完成此请求。
1.4、 定时器周期性的激活调度器
定时器是Linux提供的一种定时服务的机制. 它在某个特定的时间唤醒某个进程,来做一些工作。
在低分辨率定时器的每次时钟中断完成全局统计量更新后, 每个cpu在软中断中执行一下操作:
- 更新该cpu上当前进程内核态、用户态使用时间xtime_update
- 调用该cpu上的定时器函数
- 启动周期性定时器(scheduler_tick)完成该cpu上任务的周期性调度工作;
在支持动态定时器的系统中,可以关闭该调度器,从而进入深度睡眠过程;scheduler_tick查看当前进程是否运行太长时间,如果是,将进程的TIF_NEED_RESCHED置位,然后再中断返回时,调用schedule,进行进程切换操作:kernel/time/timer.c
/*
* Called from the timer interrupt handler to charge one tick to the current
* process. user_tick is 1 if the tick is user time, 0 for system.
*/
void update_process_times(int user_tick)
{
struct task_struct *p = current;
/* Note: this timer irq context must be accounted for as well. */
account_process_tick(p, user_tick);
run_local_timers();
rcu_sched_clock_irq(user_tick);
#ifdef CONFIG_IRQ_WORK
if (in_irq())
irq_work_tick();
#endif
scheduler_tick();
if (IS_ENABLED(CONFIG_POSIX_TIMERS))
run_posix_cpu_timers();
}
Linux6.1版本定时器中断处理采用了软中断机制而不是底半机制。时钟中断处理函数仍然为timer_interrup()-> do_timer_interrupt()-> do_timer_interrupt_hook()-> do_timer()。不过do_timer()函数的实现有所不同。kernel/time/timekeeping.c
/*
* Must hold jiffies_lock
*/
void do_timer(unsigned long ticks)
{
jiffies_64 += ticks;
calc_global_load();
}
二、 主调度器
在内核中的许多地方, 如果要将CPU分配给与当前活动进程不同的另一个进程, 都会直接调用主调度器函数schedule, 从系统调用返回后, 内核也会检查当前进程是否设置了重调度标志TLF_NEDD_RESCHED
例如, 前述的周期性调度器的scheduler_tick就会设置该标志, 如果是这样则内核会调用schedule, 该函数假定当前活动进程一定会被另一个进程取代。
2.1、 调度函数的__sched前缀
在详细论述schedule之前, 需要说明一下__sched前缀, 该前缀可能用于调用schedule的函数, 包括schedule本身.
__sched前缀的声明include/linux/sched/debug.h
/* Attach to any functions which should be ignored in wchan output. */
#define __sched __section(".sched.text")
#define __sched __section(".sched.text") 的主要目的是通过宏定义将 __sched 替换为 __section(".sched.text"),从而将与调度相关的函数或变量放置到 .sched.text 段中。这是一种在操作系统开发中常见的做法,用来控制代码在内存中的布局和优化,尤其是在性能要求较高的场景下。
2.2、 schedule函数
1、 schedule主框架
schedule就是主调度器的函数, 在内核中的许多地方, 如果要将CPU分配给与当前活动进程不同的另一个进程, 都会直接调用主调度器函数schedule。
该函数完成如下工作:
-
确定当前就绪队列, 并在保存一个指向当前(仍然)活动进程的task_struct指针。
-
检查死锁, 关闭内核抢占后调用__schedule完成内核调度。
-
恢复内核抢占, 然后检查当前进程是否设置了重调度标志TLF_NEDD_RESCHED, 如果该进程被其他进程设置了TIF_NEED_RESCHED标志, 则函数重新执行进行调度。
该函数定义kernel/sched/core.c
asmlinkage __visible void __sched schedule(void)
{
/* 获取当前的进程 */
struct task_struct *tsk = current;
/* 避免死锁 */
sched_submit_work(tsk);
do {
preempt_disable(); /* 关闭内核抢占 */
__schedule(false); /* 完成调度 */
sched_preempt_enable_no_resched(); /* 开启内核抢占 */
} while (need_resched()); /* 如果该进程被其他进程设置了TIF_NEED_RESCHED标志,则函数重新执行进行调度 */
}
EXPORT_SYMBOL(schedule);
该函数定义kernel/sched/core.c
static inline void sched_submit_work(struct task_struct *tsk)
{
/* 检测tsk->state是否为0 (runnable), 若为运行态时则返回,
* tsk_is_pi_blocked(tsk),检测tsk的死锁检测器是否为空,若非空的话就return
*/
unsigned int task_flags;
if (task_is_running(tsk))
return;
task_flags = tsk->flags;
if (task_flags & (PF_WQ_WORKER | PF_IO_WORKER)) {
if (task_flags & PF_WQ_WORKER)
wq_worker_sleeping(tsk);
else
io_wq_worker_sleeping(tsk);
}
/*
* spinlock and rwlock must not flush block requests. This will
* deadlock if the callback attempts to acquire a lock which is
* already acquired.
*/
SCHED_WARN_ON(current->__state & TASK_RTLOCK_WAIT);
/*
* If we are going to sleep and we have plugged IO queued,
* make sure to submit it to avoid deadlocks.
*/
blk_flush_plug(tsk->plug, true);/* 然后检测是否需要刷新plug队列,用来避免死锁 */
}
3、 preempt_disable和sched_preempt_enable_no_resched开关内核抢占
内核抢占
Linux除了内核态外还有用户态。用户程序的上下文属于用户态,系统调用和中断处理例程上下文属于内核态. 如果一个进程在用户态时被其他进程抢占了COU则成发生了用户态抢占, 而如果此时进程进入了内核态, 则内核此时代替进程执行, 如果此时发了抢占, 发生了内核抢占。
抢占内核的主要特点是:一个在内核态运行的进程,当且仅当在执行内核函数期间被另外一个进程取代。
这与用户态的抢占有本质区别。
内核为了支撑内核抢占, 提供了很多机制和结构, 必要时候开关内核抢占也是必须的include/linux/preempt.h
#define preempt_disable() \
do { \
preempt_count_inc(); \
barrier(); \
} while (0)
#define sched_preempt_enable_no_resched() \
do { \
barrier(); \
preempt_count_dec(); \
} while (0)
2.3、 __schedule开始进程调度
kernel/sched/core.c
static void __sched notrace __schedule(bool preempt)
{
struct task_struct *prev, *next;
unsigned long *switch_count;
unsigned long prev_state;
struct rq_flags rf;
struct rq *rq;
int cpu;
/* ==1==
找到当前cpu上的就绪队列rq
并将正在运行的进程curr保存到prev中 */
cpu = smp_processor_id();
rq = cpu_rq(cpu);
prev = rq->curr;
/*
* do_exit() calls schedule() with preemption disabled as an exception;
* however we must fix that up, otherwise the next task will see an
* inconsistent (higher) preempt count.
*
* It also avoids the below schedule_debug() test from complaining
* about this.
*/
if (unlikely(prev->state == TASK_DEAD))
preempt_enable_no_resched_notrace();
/* 如果禁止内核抢占,而又调用了cond_resched就会出错
* 这里就是用来捕获该错误的 */
schedule_debug(prev);
if (sched_feat(HRTICK))
hrtick_clear(rq);
/* 关闭本地中断 */
local_irq_disable();
/* 更新全局状态,
* 标识当前CPU发生上下文的切换 */
rcu_note_context_switch();
/*
* Make sure that signal_pending_state()->signal_pending() below
* can't be reordered with __set_current_state(TASK_INTERRUPTIBLE)
* done by the caller to avoid the race with signal_wake_up().
*/
smp_mb__before_spinlock();
/* 锁住该队列 */
raw_spin_lock(&rq->lock);
lockdep_pin_lock(&rq->lock);
rq->clock_skip_update <<= 1; /* promote REQ to ACT */
/* 切换次数记录, 默认认为非主动调度计数(抢占) */
switch_count = &prev->nivcsw;
/*
* scheduler检查prev的状态state和内核抢占表示
* 如果prev是不可运行的, 并且在内核态没有被抢占
*
* 此时当前进程不是处于运行态, 并且不是被抢占
* 此时不能只检查抢占计数
* 因为可能某个进程(如网卡轮询)直接调用了schedule
* 如果不判断prev->stat就可能误认为task进程为RUNNING状态
* 到达这里,有两种可能,一种是主动schedule, 另外一种是被抢占
* 被抢占有两种情况, 一种是时间片到点, 一种是时间片没到点
* 时间片到点后, 主要是置当前进程的need_resched标志
* 接下来在时钟中断结束后, 会preempt_schedule_irq抢占调度
*
* 那么我们正常应该做的是应该将进程prev从就绪队列rq中删除,
* 但是如果当前进程prev有非阻塞等待信号,
* 并且它的状态是TASK_INTERRUPTIBLE
* 我们就不应该从就绪队列总删除它
* 而是配置其状态为TASK_RUNNING, 并且把他留在rq中
/* 如果内核态没有被抢占, 并且内核抢占有效
即是否同时满足以下条件:
1 该进程处于停止状态
2 该进程没有在内核态被抢占 */
if (!preempt && prev->state)
{
/* 如果当前进程有非阻塞等待信号,并且它的状态是TASK_INTERRUPTIBLE */
if (unlikely(signal_pending_state(prev->state, prev)))
{
/* 将当前进程的状态设为:TASK_RUNNING */
prev->state = TASK_RUNNING;
}
else /* 否则需要将prev进程从就绪队列中删除*/
{
/* 将当前进程从runqueue(运行队列)中删除 */
deactivate_task(rq, prev, DEQUEUE_SLEEP);
/* 标识当前进程不在runqueue中 */
prev->on_rq = 0;
/*
* If a worker went to sleep, notify and ask workqueue
* whether it wants to wake up a task to maintain
* concurrency.
*/
if (prev->flags & PF_WQ_WORKER) {
struct task_struct *to_wakeup;
to_wakeup = wq_worker_sleeping(prev);
if (to_wakeup)
try_to_wake_up_local(to_wakeup);
}
}
/* 如果不是被抢占的,就累加主动切换次数 */
switch_count = &prev->nvcsw;
}
/* 如果prev进程仍然在就绪队列上没有被删除 */
if (task_on_rq_queued(prev))
update_rq_clock(rq); /* 跟新就绪队列的时钟 */
/* 挑选一个优先级最高的任务将其排进队列 */
next = pick_next_task(rq, prev);
/* 清除pre的TIF_NEED_RESCHED标志 */
clear_tsk_need_resched(prev);
/* 清楚内核抢占标识 */
clear_preempt_need_resched();
rq->clock_skip_update = 0;
/* 如果prev和next非同一个进程 */
if (likely(prev != next))
{
rq->nr_switches++; /* 队列切换次数更新 */
rq->curr = next; /* 将next标记为队列的curr进程 */
++*switch_count; /* 进程切换次数更新 */
trace_sched_switch(preempt, prev, next);
/* 进程之间上下文切换 */
rq = context_switch(rq, prev, next); /* unlocks the rq */
}
else /* 如果prev和next为同一进程,则不进行进程切换 */
{
rq_unpin_lock(rq, &rf);
__balance_callbacks(rq);
raw_spin_rq_unlock_irq(rq);
}
}
2、 pick_next_task选择抢占的进程
内核从cpu的就绪队列中选择一个最合适的进程来抢占CPU
next = pick_next_task(rq);
全局的pick_next_task函数会从按照优先级遍历所有调度器类的pick_next_task函数, 去查找最优的那个进程, 当然因为大多数情况下, 系统中全是CFS调度的非实时进程, 因而linux内核也有一些优化的策略。
其执行流程如下:
-
如果当前cpu上所有的进程都是cfs调度的普通非实时进程, 则直接用cfs调度, 如果无程序可调度则调度idle进程。
-
否则从优先级最高的调度器类sched_class_highest(目前是stop_sched_class)开始依次遍历所有调度器类的pick_next_task函数, 选择最优的那个进程执行。
kernel/sched/core.c
static struct task_struct *
pick_next_task(struct rq *rq, struct task_struct *prev, struct rq_flags *rf)
{
return __pick_next_task(rq, prev, rf);
}
/*
* Pick up the highest-prio task:
*/
static inline struct task_struct *
__pick_next_task(struct rq *rq, struct task_struct *prev, struct rq_flags *rf)
{
const struct sched_class *class;
struct task_struct *p;
/*
* Optimization: we know that if all tasks are in
* the fair class we can call that function directly:
*
* 如果待被调度的进程prev是隶属于CFS的普通非实时进程
* 而当前cpu的全局就绪队列rq中的进程数与cfs_rq的进程数相等
* 则说明当前cpu上的所有进程都是由cfs调度的普通非实时进程
*
* 那么我们选择最优进程的时候
* 就只需要调用cfs调度器类fair_sched_class的选择函数pick_next_task
* 就可以找到最优的那个进程p
*/
/* 如果当前所有的进程都被cfs调度, 没有实时进程 */
if (likely(prev->sched_class == class &&
rq->nr_running == rq->cfs.h_nr_running))
{
/* 调用cfs的选择函数pick_next_task找到最优的那个进程p*/
p = fair_sched_class.pick_next_task(rq, prev);
/* #define RETRY_TASK ((void *)-1UL)有被其他调度气找到合适的进程 */
if (unlikely(p == RETRY_TASK))
goto again; /* 则遍历所有的调度器类找到最优的进程 */
/* assumes fair_sched_class->next == idle_sched_class */
if (unlikely(!p)) /* 如果没有进程可被调度 */
p = idle_sched_class.pick_next_task(rq, prev); /* 则调度idle进程 */
return p;
}
/* 进程中所有的调度器类, 是通过next域链接域链接在一起的
* 调度的顺序为stop -> dl -> rt -> fair -> idle
* again出的循环代码会遍历他们找到一个最优的进程 */
again:
for_each_class(class)
{
p = class->pick_next_task(rq, prev);
if (p)
{
if (unlikely(p == RETRY_TASK))
goto again;
return p;
}
}
BUG(); /* the idle class will always have a runnable task */
}
进程中所有的调度器类, 是通过next域链接域链接在一起的, 调度的顺序为:
stop -> dl -> rt -> fair -> idle
其中for_each_class遍历所有的调度器类, 依次执行pick_next_task操作选择最优的进程。
它会从优先级最高的sched_class_highest(目前是stop_sched_class)查起, 依次按照调度器类的优先级从高到低的顺序调用调度器类对应的pick_next_task_fair函数直到查找到一个能够被调度的进程。
for_each_class定义kernel/sched/sched.h
#define sched_class_highest (&stop_sched_class)
#define for_each_class(class) \
for (class = sched_class_highest; class; class = class->next)
extern const struct sched_class stop_sched_class;
extern const struct sched_class dl_sched_class;
extern const struct sched_class rt_sched_class;
extern const struct sched_class fair_sched_class;
extern const struct sched_class idle_sched_class;
除了全局的pick_next_task函数, 每个调度器类都提供了pick_next_task函数用以查找对应调度器下的最优进程。
实际上,对于RT进程,put和pick并不操作运行队列。
对于FIFO和RR的区别,在scheduler_tick中通过curr->sched_class->task_tick进入到task_tick_rt的处理, 如果是非RR的进程则直接返回,否则递减时间片,如果时间片耗完,则需要将当前进程放到运行队列的末尾, 这个时候才操作运行队列(FIFO和RR进程,是否位于同一个plist队列?),时间片到点,会重新移动当前进程requeue_task_rt,进程会被加到队列尾,接下来set_tsk_need_resched触发调度,进程被抢占进入schedule。
2.4、 context_switch进程上下文切换
上下文切换(有时也称做进程切换或任务切换)是指CPU从一个进程或线程切换到另一个进程或线程
稍微详细描述一下,上下文切换可以认为是内核(操作系统的核心)在 CPU 上对于进程(包括线程)进行以下的活动:
-
挂起一个进程,将这个进程在 CPU 中的状态(上下文)存储于内存中的某处。
-
在内存中检索下一个进程的上下文并将其在 CPU 的寄存器中恢复。
-
跳转到程序计数器所指向的位置(即跳转到进程被中断时的代码行),以恢复该进程。
因此上下文是指某一时间点CPU寄存器和程序计数器的内容, 广义上还包括内存中进程的虚拟地址映射信息。
上下文切换只能发生在内核态中, 上下文切换通常是计算密集型的。也就是说,它需要相当可观的处理器时间,在每秒几十上百次的切换中,每次切换都需要纳秒量级的时间。所以,上下文切换对系统来说意味着消耗大量的 CPU 时间,事实上,可能是操作系统中时间消耗最大的操作。
Linux相比与其他操作系统(包括其他类 Unix 系统)有很多的优点,其中有一项就是,其上下文切换和模式切换的时间消耗非常少。
context_switch函数完成了进程上下文的切换, 其定义kernel/sched/core.c
context_switch( )函数建立next进程的地址空间。进程描述符的active_mm字段指向进程所使用的内存描述符,而mm字段指向进程所拥有的内存描述符。对于一般的进程,这两个字段有相同的地址,但是,内核线程没有它自己的地址空间而且它的 mm字段总是被设置为 NULL。
/*
* context_switch - switch to the new MM and the new thread's register state.
*/
static __always_inline struct rq *
context_switch(struct rq *rq, struct task_struct *prev,
struct task_struct *next, struct rq_flags *rf)
{
prepare_task_switch(rq, prev, next);
/*
* For paravirt, this is coupled with an exit in switch_to to
* combine the page table reload and the switch backend into
* one hypercall.
*/
arch_start_context_switch(prev);
/*
* kernel -> kernel lazy + transfer active
* user -> kernel lazy + mmgrab_lazy_tlb() active
*
* kernel -> user switch + mmdrop_lazy_tlb() active
* user -> user switch
*
* switch_mm_cid() needs to be updated if the barriers provided
* by context_switch() are modified.
*/
if (!next->mm) { // to kernel
enter_lazy_tlb(prev->active_mm, next);
next->active_mm = prev->active_mm;
if (prev->mm) // from user
mmgrab_lazy_tlb(prev->active_mm);
else
prev->active_mm = NULL;
} else { // to user
membarrier_switch_mm(rq, prev->active_mm, next->mm);
/*
* sys_membarrier() requires an smp_mb() between setting
* rq->curr / membarrier_switch_mm() and returning to userspace.
*
* The below provides this either through switch_mm(), or in
* case 'prev->active_mm == next->mm' through
* finish_task_switch()'s mmdrop().
*/
switch_mm_irqs_off(prev->active_mm, next->mm, next);
lru_gen_use_mm(next->mm);
if (!prev->mm) { // from kernel
/* will mmdrop_lazy_tlb() in finish_task_switch(). */
rq->prev_mm = prev->active_mm;
prev->active_mm = NULL;
}
}
/* switch_mm_cid() requires the memory barriers above. */
switch_mm_cid(rq, prev, next);
prepare_lock_switch(rq, next, rf);
/* Here we just switch the register state and the stack. */
switch_to(prev, next, prev);
barrier();
return finish_task_switch(prev);
}
switch_mm主要完成了进程prev到next虚拟地址空间的映射, 由于内核虚拟地址空间是不许呀切换的, 因此切换的主要是用户态的虚拟地址空间。
其主要工作就是切换了进程的CR3:
控制寄存器(CR0~CR3)用于控制和确定处理器的操作模式以及当前执行任务的特性
CR0中含有控制处理器操作模式和状态的系统控制标志;
CR1保留不用;
CR2含有导致页错误的线性地址;
CR3中含有页目录表物理内存基地址,因此该寄存器也被称为页目录基地址寄存器PDBR(Page-Directory Base address Register)。
执行环境的切换是在switch_to()中完成的, switch_to完成最终的进程切换,它保存原进程的所有寄存器信息,恢复新进程的所有寄存器信息,并执行新的进程
调度过程可能选择了一个新的进程, 而清理工作则是针对此前的活动进程, 请注意, 这不是发起上下文切换的那个进程, 而是系统中随机的某个其他进程, 内核必须想办法使得进程能够与context_switch例程通信, 这就可以通过switch_to宏实现. 因此switch_to函数通过3个参数提供2个变量。
内核在switch_to中执行如下操作:
-
进程切换, 即esp的切换, 由于从esp可以找到进程的描述符。
-
硬件上下文切换, 设置ip寄存器的值, 并jmp到__switch_to函数。
-
堆栈的切换, 即ebp的切换, ebp是栈底指针, 它确定了当前用户空间属于哪个进程。
2.5、 need_resched, TIF_NEED_RESCHED标识与用户抢占
1、 need_resched标识TIF_NEED_RESCHED
内核在即将返回用户空间时检查进程是否需要重新调度,如果设置了,就会发生调度, 这被称为用户抢占, 因此内核在thread_info的flag中设置了一个标识来标志进程是否需要重新调度, 即重新调度need_resched标识TIF_NEED_RESCHED。
并提供了一些设置可检测的函数:
|
函数 |
描述 |
|
set_tsk_need_resched |
设置指定进程中的need_resched标志 |
|
clear_tsk_need_resched |
清除指定进程中的need_resched标志 |
|
test_tsk_need_resched |
检查指定进程need_resched标志 |
而我们内核中调度时常用的need_resched()函数检查进程是否需要被重新调度其实就是通过test_tsk_need_resched实现的, 其定义如下所示:include/linux/sched.h
static __always_inline bool need_resched(void)
{
return unlikely(tif_need_resched());
}
2、 用户抢占和内核抢占
当内核即将返回用户空间时, 内核会检查need_resched是否设置,如果设置,则调用schedule(),此时,发生用户抢占。
一般来说,用户抢占发生几下情况:
-
从系统调用返回用户空间
-
从中断(异常)处理程序返回用户空间
当kerne(系统调用或者中断都在kernel中)l返回用户态时,系统可以安全的执行当前的任务,或者切换到另外一个任务。
当中断处理例程或者系统调用完成后, kernel返回用户态时, need_resched标志的值会被检查, 假如它为1, 调度器会选择一个新的任务并执行. 中断和系统调用的返回路径(return path)的实现在entry.S中(entry.S不仅包括kernel entry code,也包括kernel exit code)。
抢占时伴随着schedule()的执行, 因此内核提供了一个TIF_NEED_RESCHED标志来表明是否要用schedule()调度一次。
根据抢占发生的时机分为用户抢占和内核抢占。
用户抢占发生在内核即将返回到用户空间的时候。内核抢占发生在返回内核空间的时候。
| 抢占类型 | 描述 | 抢占发生时机 |
|---|---|---|
| 用户抢占 | 内核在即将返回用户空间时检查进程是否设置了TIF_NEED_RESCHED标志,如果设置了,就会发生用户抢占. | 从系统调用或中断处理程序返回用户空间的时候 |
| 内核抢占 | 在不支持内核抢占的内核中,内核进程如果自己不主动停止,就会一直的运行下去。无法响应实时进程. 抢占内核虽然牺牲了上下文切换的开销, 但获得 了更大的吞吐量和响应时间 2.6的内核添加了内核抢占,同时为了某些地方不被抢占,又添加了自旋锁. 在进程的thread_info结构中添加了preempt_count该数值为0,当进程使用一个自旋锁时就加1,释放一个自旋锁时就减1. 为0时表示内核可以抢占. | 从中断处理程序返回内核空间时,内核会检查preempt_count和TIF_NEED_RESCHED标志,如果进程设置了 TIF_NEED_RESCHED标志,并且preempt_count为0,发生内核抢占 2. 当内核再次用于可抢占性的时候,当进程所有的自旋锁都释 放了,释放程序会检查TIF_NEED_RESCHED标志,如果设置了就会调用schedule 3. 显示调用schedule时 4. 内核中的进程被堵塞的时候 |
三、 主调度总结
3.1、 schedule调度流程
schedule就是主调度器的函数, 在内核中的许多地方, 如果要将CPU分配给与当前活动进程不同的另一个进程, 都会直接调用主调度器函数schedule。
该函数完成如下工作:
-
确定当前就绪队列, 并在保存一个指向当前(仍然)活动进程的task_struct指针
-
检查死锁, 关闭内核抢占后调用__schedule完成内核调度
-
恢复内核抢占, 然后检查当前进程是否设置了重调度标志TLF_NEDD_RESCHED, 如果该进程被其他进程设置了TIF_NEED_RESCHED标志, 则函数重新执行进行调度
3.2、 __schedule如何完成内核抢占
-
完成一些必要的检查, 并设置进程状态, 处理进程所在的就绪队列
-
调度全局的pick_next_task选择抢占的进程
-
如果当前cpu上所有的进程都是cfs调度的普通非实时进程, 则直接用cfs调度, 如果无程序可调度则调度idle进程
-
否则从优先级最高的调度器类sched_class_highest(目前是stop_sched_class)开始依次遍历所有调度器类的pick_next_task函数, 选择最优的那个进程执行
-
-
context_switch完成进程上下文切换
-
调用switch_mm(), 把虚拟内存从一个进程映射切换到新进程中
-
调用switch_to(),从上一个进程的处理器状态切换到新进程的处理器状态。这包括保存、恢复栈信息和寄存器信息
-
3.3、 调度的内核抢占和用户抢占
内核在完成调度的过程中总是先关闭内核抢占, 等待内核完成调度的工作后, 再把内核抢占开启, 如果在内核完成调度器过程中, 这时候如果发生了内核抢占, 我们的调度会被中断, 而调度却还没有完成, 这样会丢失我们调度的信息.
而同样我们可以看到, 在调度完成后, 内核会去判断need_resched条件, 如果这个时候为真, 内核会重新进程一次调度, 此次调度由于发生在内核态因此仍然是一次内核抢占
need_resched条件其实是判断need_resched标识TIF_NEED_RESCHED的值, 内核在thread_info的flag中设置了一个标识来标志进程是否需要重新调度, 即重新调度need_resched标识TIF_NEED_RESCHED, 内核在即将返回用户空间时会检查标识TIF_NEED_RESCHED标志进程是否需要重新调度,如果设置了,就会发生调度, 这被称为用户抢占。
而内核抢占是通过自旋锁preempt_count实现的, 同样当内核可以进行内核抢占的时候(比如从中断处理程序返回内核空间或内核中的进程被堵塞的时候),内核会检查preempt_count和TIF_NEED_RESCHED标志,如果进程设置了 TIF_NEED_RESCHED标志,并且preempt_count为0,发生内核抢占。
95

被折叠的 条评论
为什么被折叠?



