深入理解Linux内核之进程睡眠
1开场白
环境:
-
处理器架构:arm64
-
内核源码:linux-5.10.50
-
ubuntu版本:20.04.1
-
代码阅读工具:vim+ctags+cscope
无论是任务处于用户态还是内核态,经常会因为等待某些事件而睡眠(可能是等待IO读写完成,也可能等待其他内核路径释放一把锁等)。本文来探讨一下,任务处于睡眠中有哪些状态?睡眠对于任务来说究竟意味着什么?内核是如何管理睡眠的任务的?我们会结合内核源代码来分析任务的睡眠,力求全方位角度来剖析。
注:由于篇幅问题,文章分为上下两篇,且这里不区分进程和任务,统一使用任务来表示进程。
主要讲解以下内容:
-
睡眠的三种状态
-
睡眠的内核原理
-
用户态睡眠
-
内核态睡眠
-
总结
2. 睡眠的三种状态
任务睡眠有三种状态:
浅度睡眠
中度睡眠
深度睡眠
2.1 浅度睡眠
进程描述符的state使用 TASK_INTERRUPTIBLE 表示这种状态。
为可中断的睡眠状态,这里可中断是可以被信号所打断(唤醒)。
这里给出被信号打断/唤醒的代码路径:
kernel/signal.c SYSCALL_DEFINE2(kill, pid_t, pid, int, sig) ->kill_something_info ->__kill_pgrp_info ->group_send_sig_info ->do_send_sig_info ->send_signal ->__send_signal ->complete_signal ->signal_wake_up -> signal_wake_up_state(t, resume ? TASK_WAKEKILL : 0) ->wake_up_state(t, state | TASK_INTERRUPTIBLE) ->try_to_wake_up
可以看到在信号传递的时候,会通过signal_wake_up唤醒从处于可中断睡眠状态的任务。
2.2 中度睡眠
进程描述符的state使用 TASK_KILLABLE 表示这种状态。
可以被致命信号所打断。
这里给出被致命信号打断/唤醒的代码路径:
include/linux/sched.h #define TASK_KILLABLE (TASK_WAKEKILL | TASK_UNINTERRUPTIBLE) kernel/signal.c SYSCALL_DEFINE2(kill, pid_t, pid, int, sig) ->kill_something_info ->__kill_pgrp_info ->group_send_sig_info ->do_send_sig_info ->send_signal ->__send_signal ->complete_signal -> if (sig_fatal(p, sig) && ¦ !(signal->flags & SIGNAL_GROUP_EXIT) && ¦ !sigismember(&t->real_blocked, sig) && ¦ (sig == SIGKILL || !p->ptrace)) { //致命信号 ... signal_wake_up(t, 1); -> signal_wake_up_state(t, resume ? TASK_WAKEKILL : 0) // resume == 1 -> wake_up_state(t, state | TASK_INTERRUPTIBLE) ->try_to_wake_up ... }
2.3 深度睡眠
进程描述符的state使用 TASK_UNINTERRUPTIBLE 表示这种状态。
为不可中断的睡眠状态,不能被任何信号所唤醒(特定条件没有满足发生信号唤醒可能导致数据不一致等问题,这种场景使用这种睡眠状态,如等待IO读写完成)。
3. 睡眠的内核原理
睡眠都是主动发生调度,即主动调用主调度器。
睡眠的主要步骤如下:
1)设置任务状态为睡眠状态
2)记录睡眠的任务
3)发起主动调度
下面我们来详细解读下这几个步骤:
3.1 设置任务状态为睡眠状态
这一步很有必要,一来标识进入了睡眠状态,二来是主调度器会根据睡眠标志将任务从运行队列删除。
注:睡眠状态描述见上一小节!
3.2 记录睡眠的任务
这一步也非常有必要,内核会将即将睡眠的任务记录下来,要么加入到链表中管理,要么使用数据结构记录。
如延迟睡眠场景,内核将即将睡眠的任务记录在定时器相关的数据结构中;可睡眠的信号量场景中,内核将即将睡眠的任务加入到信号量的相关链表中。
记录的目的在于:当唤醒条件满足时,唤醒函数能够找到想要唤醒的任务。
3.3 发起主动调度
这一步是真正进行睡眠的操作,主要是调用主调度器来发起主动调度让出处理器。
下面我们来看下主调度器为任务睡眠所作的处理:
kernel/sched/core.c __schedule -> prev_state = prev->state; //获得前一个任务状态 if (!preempt && prev_state) { //如果是主动调度 且任务状态不为0 if (signal_pending_state(prev_state, prev)) { //有挂起的信号 prev->state = TASK_RUNNING; //设置状态为可运行 } else { deactivate_task(rq, prev, DEQUEUE_SLEEP | DEQUEUE_NOCLOCK); //cpu运行队列中删除任务 } } next = pick_next_task(rq, prev, &rf); //选择下一个任务 context_switch //进行上下文切换
来看下deactivate_task对于睡眠任务做的主要工作:
deactivate_task ->deactivate_task(rq, prev, DEQUEUE_SLEEP | DEQUEUE_NOCLOCK) ->p->on_rq = (flags & DEQUEUE_SLEEP) ? 0 : TASK_ON_RQ_MIGRATING; //设置任务的on_rq 为0 标识是睡眠 dequeue_task(rq, p, flags); ->p->sched_class->dequeue_task(rq, p, flags) ->dequeue_task_fair ->dequeue_entity ... if (se != cfs_rq->curr) //不是cpu当前 任务 __dequeue_entity(cfs_rq, se); //cfs运行队列删除 ->se->on_rq = 0; //标识调度实体不在运行队列!!! ->if (!(flags & DEQUEUE_SLEEP)) se->vruntime -= cfs_rq->min_vruntime; //调度实体的虚拟运行时间 减去 cfs运行队列的最小虚拟运行时间
deactivate_task会设置任务的on_rq 为0来 标识是睡眠 ,然后 调用到调度类的dequeue_task方法,在cfs中设置se->on_rq = 0标识调度实体不在cfs队列。
可以看到,发起主动调度的时候,在主调度器中会做判断:如果是主动调度且任务状态不为0 (即为不是可运行的TASK_RUNNING)时,如果没有挂起的信号,就会将任务从cpu的运行队列中“删除”,然后选择下一个任务,进行上下文切换。
将即将睡眠的任务从cpu的运行队列中“删除”意义重大:主调度器再次选择下一个任务的时候不会在选择睡眠的任务(因为主调度器总是在运行队列中选择任务运行,除非任务被唤醒,重新加入运行队列)。
注意:1.这里的删除指的是设置对应标志如p->on_rq=0,se->on_rq = 0,当选择下一个任务的时候不会在加入运行队列中。2.即将睡眠的任务是cpu上的当前任务(curr指向)。3.调用主调度器后,即将睡眠的任务不会再次加入cpu运行队列,除非被唤醒。
再来看下选择下一个任务的时候会做哪些事情和睡眠有关(暂不考虑组调度情况):
pick_next_task ->class->pick_next_task ->pick_next_task_fair //kernel/sched/fair.c ->if (prev) put_prev_task(rq, prev); //对前一个任务处理 se = pick_next_entity(cfs_rq, NULL); //选择下一个任务 set_next_entity(cfs_rq, se);
主要看下put_prev_task:
put_prev_task ->prev->sched_class->put_prev_task(rq, prev) ->put_prev_task_fair ->put_prev_entity -> if (prev->on_rq) { //前一个任务的调度实体on_rq不为0? update_stats_wait_start(cfs_rq, prev); /* Put 'current' back into the tree. */ __enqueue_entity(cfs_rq, prev); //重新加入cfs运行队列 /* in !on_rq case, update occurred at dequeue */ update_load_avg(cfs_rq, prev, 0); } cfs_rq->curr = NULL; //设置cfs运行队列的curr为NULL
put_prev_task所做的主要工作就是将前一个任务从cfs运行队列中删除,在这里就是通过调用__enqueue_entity将对应的调度实体重新加入cfs队列的红黑树,但是对于即将睡眠的任务之前在主调度器中通过deactivate_task将prev->on_rq设置为0了,所以对于 即将睡眠的任务来说,它对应的调度实体不会在重新加入cfs运行队列的红黑树 。
下面来看下睡眠图示:
4.用户 态 睡眠
以sleep为例来说明任务在用户态是如何睡眠的。
首先我们通过strace工具来看下其调用的系统调用:
$ strace sleep 1
...
close(3) = 0
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, NULL) = 0
close(1) = 0
...
可以发现sleep主要调用clock_nanosleep系统调用来进行睡眠(也就是说用户态任务睡眠需要调用系统调用陷入内核)。
下面我们来研究下clock_nanosleep的实现(这里集中到睡眠的实现,先忽略掉定时器等诸多的技术细节):
kernel/time/posix-timers.c
SYSCALL_DEFINE4(clock_nanosleep
->const struct k_clock *kc = clockid_to_kclock(which_clock); //根据时钟类型得到内核时钟结构
return kc->nsleep(which_clock, flags, &t); //调用内核时钟结构的nsleep回调
我们传递过来的时钟类型为CLOCK_REALTIME,则调用链为:
kc->nsleep(CLOCK_REALTIME, flags, &t)
->clock_realtime.nsleep
->common_nsleep
->hrtimer_nanosleep //kernel/time/hrtimer.c
->hrtimer_init_sleeper_on_stack
->__hrtimer_init_sleeper
->__hrtimer_init(&sl->timer, clock_id, mode); //初始化高精度定时器
sl->timer.function = hrtimer_wakeup; //设置超时回调函数
sl->task = current;.//设置超时时要唤醒的任务
->do_nanosleep //睡眠操作
可以看到,睡眠函数最终调用到hrtimer_nanosleep,它调用了两个主要函数:__hrtimer_init_sleeper和do_nanosleep,前者主要设置高精度定时器,后者就是真正的睡眠,主要来看下 do_nanosleep:
kernel/time/hrtimer.c
do_nanosleep
->
do {
set_current_state(TASK_INTERRUPTIBLE); //设置可中断的睡眠状态
hrtimer_sleeper_start_expires(t, mode); //开启高精度定时器
if (likely(t->task))
freezable_schedule(); //主动调度
hrtimer_cancel(&t->timer);
mode = HRTIMER_MODE_ABS;
} while (t->task && !signal_pending(current)); //是否记录的有任务且没有挂起的信号
__set_current_state(TASK_RUNNING); //设置为可运行状态
do_nanosleep函数是睡眠的核心实现:首先设置任务的状态为可中断的睡眠状态,然后开启了之前设置的高精度定时器,随即调用freezable_schedule进行真正的睡眠。
来看下freezable_schedule:
//include/linux/freezer.h
freezable_schedule
->schedule()
->__schedule(false);
可以看到最终调用主调度器__schedule进行主动调度。
当任务睡眠完成,定时器超时,会调用之前在__hrtimer_init_sleeper设置的超时回调函数hrtimer_wakeup将睡眠的任务唤醒(关于进程唤醒在这里就不在赘述,在后面的进程唤醒专题文章在进行详细解读),然后就可以再次获得处理器的使用权了。
总结:处于用户态的任务,如果想要睡眠一段时间必须向内核请求服务(如调用clock_nanosleep系统调用),内核中会设置一个高精度定时器,来记录要睡眠的任务,然后设置任务状态为可中断的睡眠状态,紧接着发生主动调度,这样任务就发生睡眠了。
5.内核态睡眠
当任务处于内核态时,有时候也需要睡眠一段时间,不像任务处于用户态需要发生系统调用来请求内核进行睡眠,在内核态可以直接调用睡眠函数。当然,内核态中,睡眠有两种场景:一种是睡眠特定的时间的延迟操作(唤醒条件为超时),一种是等待特定条件满足(如IO读写完成,可睡眠的锁被释放等)。
下面分别以msleep和mutex锁为例讲解内核态睡眠:
5.1 msleep
msleep做ms级别的睡眠延迟。
//kernel/time/timer.c
void msleep(unsigned int msecs)
{
unsigned long timeout = msecs_to_jiffies(msecs) + 1; //ms时间转换为jiffies
while (timeout)
timeout = schedule_timeout_uninterruptible(timeout); //不可中断睡眠
}
下面看下schedule_timeout_uninterruptible:
这里涉及到一个重要数据结构process_timer
struct process_timer {
struct timer_list timer; //定时器结构
struct task_struct *task; //定时器到期要唤醒的任务
};
schedule_timeout_uninterruptible
-> __set_current_state(TASK_UNINTERRUPTIBLE); //设置任务状态为不可中断睡眠
return schedule_timeout(timeout);
->expire = timeout + jiffies; //计算到期时的jiffies值
timer.task = current; //记录定时器到期要唤醒的任务 为当前任务
timer_setup_on_stack(&timer.timer, process_timeout, 0); //初始化定时器 超时回调为process_timeout
__mod_timer(&timer.timer, expire, MOD_TIMER_NOTPENDING); //添加定时器
schedule(); //主动调度
再看下超时回调为process_timeout:
process_timeout
->struct process_timer *timeout = from_timer(timeout, t, timer); //通过定时器结构获得process_timer
wake_up_process(timeout->task); //唤醒其管理的任务
可以看到,msleep实现睡眠也是通过定时器,首先设置当前任务状态为不可中断睡眠,然后设置定时器超时时间为传递的ms级延迟转换的jiffies,超时回调为process_timeout,然后将定时器添加到系统中,最后调用schedule发起主动调度,当定时器超时的时候调用process_timeout来唤醒睡眠的任务。
5.2 mutex锁
mutex锁是可睡眠锁的一种,当申请mutex锁时发现其他内核路径已经持有这把锁,当前任务就会睡眠等待在这把锁上。
下面我们来看他的实现,主要看睡眠的部分:
kernel/locking/mutex.c
mutex_lock
->__mutex_lock_slowpath
->__mutex_lock(lock, TASK_UNINTERRUPTIBLE, 0, NULL, _RET_IP_) //睡眠的状态为不可中断睡眠
->__mutex_lock_common
->
...
waiter.task = current; //记录需要唤醒的任务为当前任务
set_current_state(state); //设置睡眠状态
for (;;) {
if (__mutex_trylock(lock)) //尝试获得锁
goto acquired;
schedule_preempt_disabled();
->schedule(); //主动调度
}
acquired:
__set_current_state(TASK_RUNNING);//设置状态为可运行状态
可以看到mutex锁实现睡眠套路和之前是一样的:申请mutex锁的时候,如果其他内核路径已经持有这把锁,首先通过mutex锁的相关结构来记录下当前任务,然后设置任务状态为不可中断睡眠,接着在一个for循环中调用schedule_preempt_disabled发生主动调度,于是当前任务就睡眠在这把锁上。当其他内核路径释放了这把锁,就会唤醒等待在这把锁上的任务,当前任务就获得了这把锁,然后进入锁的临界区,唤醒操作就完成了(关于唤醒的技术细节,后面的唤醒专题会详细讲解)。
6.总结
进程睡眠按照应用场景可以分为:延迟睡眠和等待某些特定条件而睡眠,实际上都可以归于等待某些特定条件而睡眠,因为延迟特定时间也可以作为特定条件。进程睡眠按照进程所处的特权级别可以分为:用户态进程睡眠和内核态进程睡眠,用户态进程睡眠需要进程通过系统调用陷入内核来发起睡眠请求。对于进程睡眠,内核主要需要做三大步操作:1.设置任务状态为睡眠状态 2.记录睡眠的任务 3.发起主动调度。这三大步操作都是非常有必要,第一步设置睡眠状态为后面调用主调度器做必要的标识准备;第二步记录下睡眠的任务是为了以后唤醒任务来准备的;第三步是睡眠的主体部分,这里会将睡眠的任务从运行队列中踢出,选择下一个任务运行。
- eBPF 概述:第 1 部分:介绍
- 图解 | Linux内存性能优化核心思想
- 一文看懂 | fork 系统调用
- 手把手教你|如何编写一个Linux内核模块
- 网最硬核TOP技术号集结
- Linux 中的各种栈:进程栈 线程栈 内核栈 中断栈
- 介绍一下我认识的几位技术大拿
- 图解 | Linux是如何进行函数调用的?
- 我认识的一些技术大牛
- 图解 | Linux内存回收之LRU算法
- Good Good Study,Day Day Up!!!
- 如何持续学习?
- 一文看懂|分布式系统之CAP理论
- 一文读懂 | coredump文件是如何生成的
- 深入理解Linux内核之进程睡眠
- 33 张图详解 TCP 和 UDP :打通网络和应用的中间人
- posix是什么都不知道,就别说你懂Linux了!
- 图解 | 计算机网络协议
- Linux 内核调试利器 | kprobe 的使用
- CPU使用率到100%了?