深入理解Linux内核之进程睡眠之一

系统 Linux
无论是任务处于用户态还是内核态,经常会因为等待某些事件而睡眠(可能是等待IO读写完成,也可能等待其他内核路径释放一把锁等)。本文来探讨一下,任务处于睡眠中有哪些状态?

[[412145]]

1开场白

环境:

  • 处理器架构:arm64
  • 内核源码:linux-5.10.50
  • ubuntu版本:20.04.1
  • 代码阅读工具:vim+ctags+cscope

无论是任务处于用户态还是内核态,经常会因为等待某些事件而睡眠(可能是等待IO读写完成,也可能等待其他内核路径释放一把锁等)。本文来探讨一下,任务处于睡眠中有哪些状态?睡眠对于任务来说究竟意味着什么?内核是如何管理睡眠的任务的?我们会结合内核源代码来分析任务的睡眠,力求全方位角度来剖析。

注:由于篇幅问题,文章分为上下两篇,且这里不区分进程和任务,统一使用任务来表示进程。

主要讲解以下内容:

  • 睡眠的三种状态
  • 睡眠的内核原理
  • 用户态睡眠
  • 内核态睡眠
  • 总结

2. 睡眠的三种状态

任务睡眠有三种状态:

  • 浅度睡眠
  • 中度睡眠
  • 深度睡眠

2.1 浅度睡眠

进程描述符的state使用TASK_INTERRUPTIBLE表示这种状态。

为可中断的睡眠状态,这里可中断是可以被信号所打断(唤醒)。

这里给出被信号打断/唤醒的代码路径:

  1. kernel/signal.c 
  2. SYSCALL_DEFINE2(kill, pid_t, pid, int, sig) 
  3. ->kill_something_info 
  4.     ->__kill_pgrp_info 
  5.         ->group_send_sig_info 
  6.             ->do_send_sig_info 
  7.                 ->send_signal 
  8.                     ->__send_signal   
  9.                         ->complete_signal 
  10.                             ->signal_wake_up 
  11.                                  -> signal_wake_up_state(t, resume ? TASK_WAKEKILL : 0)  
  12.                                     ->wake_up_state(t, state | TASK_INTERRUPTIBLE) 
  13.                                         ->try_to_wake_up 

可以看到在信号传递的时候,会通过signal_wake_up唤醒从处于可中断睡眠状态的任务。

2.2 中度睡眠

进程描述符的state使用TASK_KILLABLE表示这种状态。

可以被致命信号所打断。

这里给出被致命信号打断/唤醒的代码路径:

  1. include/linux/sched.h 
  2. #define TASK_KILLABLE                   (TASK_WAKEKILL | TASK_UNINTERRUPTIBLE) 
  3.  
  4. kernel/signal.c 
  5. SYSCALL_DEFINE2(kill, pid_t, pid, int, sig) 
  6. ->kill_something_info 
  7.     ->__kill_pgrp_info 
  8.         ->group_send_sig_info 
  9.             ->do_send_sig_info 
  10.                 ->send_signal 
  11.                     ->__send_signal   
  12.                         ->complete_signal 
  13.                          -> 
  14.                                 if (sig_fatal(p, sig) && 
  15.                             ¦   !(signal->flags & SIGNAL_GROUP_EXIT) && 
  16.                             ¦   !sigismember(&t->real_blocked, sig) && 
  17.                             ¦   (sig == SIGKILL || !p->ptrace)) {  //致命信号 
  18.                              
  19.                                     ... 
  20.                                     signal_wake_up(t, 1); 
  21.                                        -> signal_wake_up_state(t, resume ? TASK_WAKEKILL : 0)  // resume == 1 
  22.                                            -> wake_up_state(t, state | TASK_INTERRUPTIBLE) 
  23.                                                 ->try_to_wake_up 
  24.                                     ... 
  25.                             } 

2.3 深度睡眠

进程描述符的state使用TASK_UNINTERRUPTIBLE表示这种状态。

为不可中断的睡眠状态,不能被任何信号所唤醒(特定条件没有满足发生信号唤醒可能导致数据不一致等问题,这种场景使用这种睡眠状态,如等待IO读写完成)。

3. 睡眠的内核原理

睡眠都是主动发生调度,即主动调用主调度器。

睡眠的主要步骤如下:

1)设置任务状态为睡眠状态

2)记录睡眠的任务

3)发起主动调度

下面我们来详细解读下这几个步骤:

3.1 设置任务状态为睡眠状态

这一步很有必要,一来标识进入了睡眠状态,二来是主调度器会根据睡眠标志将任务从运行队列删除。

注:睡眠状态描述见上一小节!

3.2 记录睡眠的任务

这一步也非常有必要,内核会将即将睡眠的任务记录下来,要么加入到链表中管理,要么使用数据结构记录。

如延迟睡眠场景,内核将即将睡眠的任务记录在定时器相关的数据结构中;可睡眠的信号量场景中,内核将即将睡眠的任务加入到信号量的相关链表中。

记录的目的在于:当唤醒条件满足时,唤醒函数能够找到想要唤醒的任务。

3.3 发起主动调度

这一步是真正进行睡眠的操作,主要是调用主调度器来发起主动调度让出处理器。

下面我们来看下主调度器为任务睡眠所作的处理:

  1. kernel/sched/core.c 
  2.  
  3. __schedule 
  4. -> 
  5.     prev_state = prev->state;     //获得前一个任务状态 
  6.     if (!preempt && prev_state) {  //如果是主动调度   且任务状态不为0                          
  7.             if (signal_pending_state(prev_state, prev)) {   //有挂起的信号 
  8.                     prev->state = TASK_RUNNING;       //设置状态为可运行       
  9.             } else {                                         
  10.                   deactivate_task(rq, prev, DEQUEUE_SLEEP | DEQUEUE_NOCLOCK);  //cpu运行队列中删除任务 
  11.             } 
  12.     } 
  13.      
  14.    next = pick_next_task(rq, prev, &rf);  //选择下一个任务 
  15.  
  16.    context_switch  //进行上下文切换 

来看下deactivate_task对于睡眠任务做的主要工作:

  1. deactivate_task 
  2. ->deactivate_task(rq, prev, DEQUEUE_SLEEP | DEQUEUE_NOCLOCK) 
  3.     ->p->on_rq = (flags & DEQUEUE_SLEEP) ? 0 : TASK_ON_RQ_MIGRATING;  //设置任务的on_rq 为0  标识是睡眠 
  4.     dequeue_task(rq, p, flags); 
  5.     ->p->sched_class->dequeue_task(rq, p, flags) 
  6.         ->dequeue_task_fair 
  7.             ->dequeue_entity 
  8.              
  9.                 ... 
  10.                 if (se != cfs_rq->curr)        //不是cpu当前 任务 
  11.                       __dequeue_entity(cfs_rq, se); //cfs运行队列删除 
  12.  
  13.                 ->se->on_rq = 0;  //标识调度实体不在运行队列!!! 
  14.                  
  15.                 ->if (!(flags & DEQUEUE_SLEEP)) 
  16.                        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运行队列,除非被唤醒。

再来看下选择下一个任务的时候会做哪些事情和睡眠有关(暂不考虑组调度情况):

  1. pick_next_task 
  2. ->class->pick_next_task 
  3.     ->pick_next_task_fair  //kernel/sched/fair.c 
  4.         ->if (prev)                           
  5.            put_prev_task(rq, prev);   //对前一个任务处理 
  6.           se = pick_next_entity(cfs_rq, NULL); //选择下一个任务 
  7.         set_next_entity(cfs_rq, se);         

主要看下put_prev_task:

  1. put_prev_task 
  2. ->prev->sched_class->put_prev_task(rq, prev) 
  3.     ->put_prev_task_fair 
  4.         ->put_prev_entity 
  5.             ->  if (prev->on_rq) { //前一个任务的调度实体on_rq不为0? 
  6.                 update_stats_wait_start(cfs_rq, prev); 
  7.                 /* Put 'current' back into the tree. */ 
  8.                 __enqueue_entity(cfs_rq, prev);   //重新加入cfs运行队列 
  9.                 /* in !on_rq caseupdate occurred at dequeue */ 
  10.                 update_load_avg(cfs_rq, prev, 0); 
  11.               } 
  12.            cfs_rq->curr = NULL; //设置cfs运行队列的curr为NULL 

put_prev_task所做的主要工作就是将前一个任务从cfs运行队列中删除,在这里就是通过调用__enqueue_entity将对应的调度实体重新加入cfs队列的红黑树,但是对于即将睡眠的任务之前在主调度器中通过deactivate_task将prev->on_rq设置为0了,所以对于即将睡眠的任务来说,它对应的调度实体不会在重新加入cfs运行队列的红黑树。

下面来看下睡眠图示:

 

责任编辑:武晓燕 来源: Linux内核远航者
相关推荐

2021-07-26 07:47:36

数据库

2021-12-09 08:09:31

Linux内核脏页

2021-05-19 07:56:26

Linux内核抢占

2022-11-09 08:12:07

2020-09-28 08:44:17

Linux内核

2021-07-05 06:51:45

Linux内核调度器

2021-07-02 06:54:44

Linux内核主调度器

2021-02-17 11:25:33

前端JavaScriptthis

2023-02-10 08:11:43

Linux系统调用

2022-09-05 22:22:00

Stream操作对象

2019-03-18 09:50:44

Nginx架构服务器

2014-12-04 14:01:54

openstacknetworkneutron

2018-12-27 12:34:42

HadoopHDFS分布式系统

2013-06-20 10:25:56

2021-08-31 10:32:11

LinuxPage Cache命令

2022-02-14 09:17:46

Linux端口服务器

2010-06-01 15:25:27

JavaCLASSPATH

2016-12-08 15:36:59

HashMap数据结构hash函数

2020-07-21 08:26:08

SpringSecurity过滤器

2014-12-03 13:10:10

openstacknetworkneutron
点赞
收藏

51CTO技术栈公众号