Linux调度系统全景指南(下篇)

Posted 职场重生

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Linux调度系统全景指南(下篇)相关的知识,希望对你有一定的参考价值。













Linux调度系统全景指南(下篇)



| 导语本文主要是讲Linux的调度系统, 由于全部内容太多,分三部分来讲,本篇是下篇(主要线程和进程),上篇请看(CPU和中断):,调度可以说是操作系统的灵魂,为了让CPU资源利用最大化,Linux设计了一套非常精细的调度系统,对大多数场景都进行了很多优化,系统扩展性强,我们可以根据业务模型和业务场景的特点,有针对性的去进行性能优化,在保证客户网络带宽前提下,隔离客户互相之间的干扰影响,提高CPU利用率,降低单位运算成本,提高市场竞争力。欢迎大家相互交流学习!


                              目录

Linux调度系统全景指南(下篇)


Linux调度系统全景指南(下篇)


上篇请看(CPU和中断):

中篇请看(抢占和时钟):   

                        

                                   进程

Linux调度系统全景指南(下篇)



 一般定义是操作系统对一个正在运行的程序的一种抽象, 是运行资源的管理单位(虚拟内存空间,文件句柄,全局变量,信号等运行资源),是操作系统资源分配的最小单位。在linux系统下,无论是进程,还是线程,到了内核里面,我们统一都叫任务(Task),由一个统一的结构 task_struct 进行管理:


Linux调度系统全景指南(下篇)


详细结构:

Linux调度系统全景指南(下篇)


大体分为下面几类:

Linux调度系统全景指南(下篇)


进程运行空间

Linux 按照特权等级,把进程的运行空间分为内核空间和用户空间,分别对应着下图中, CPU 特权等级的 Ring 0 和 Ring 3。


Linux调度系统全景指南(下篇)


Linux调度系统全景指南(下篇)


  • 内核空间(Ring 0)具有最高权限,可以直接访问所有资源;

  • 用户空间(Ring 3)只能访问受限资源,不能直接访问内存等硬件设备,必须通过系统调用陷入到内核中,才能访问这些特权资源;

  • 进程既可以在用户空间运行,又可以在内核空间中运行。进程在用户空间运行时,被称为进程的用户态,而陷入内核空间的时候,被称为进程的内核态。

进程内存空间(x86_64)


Linux调度系统全景指南(下篇)

各个分区的意义:


内核空间:

在32位系统中,Linux会留1G空间给内核,用户进程是无法访问的,用来存放进程相关数据和内存数据,内核代码等;在64位系统里面,Linux会采用最低48位来表示虚拟内存,这可通过 /proc/cpuinfo 来查看address sizes :

address sizes :

stack栈区:

内存映射区:

包括文件映射和匿名内存映射, 应用程序的所依赖的动态库,会在程序执行时候,加载到内存这个区域,一般包括数据(data)和代码(text);通过mmap系统调用,可以把特定的文件映射到内存中,然后在相应的内存区域中操作字节来访问文件内容,实现更高效的IO操作;匿名映射,在glibc中malloc分配大内存的时候会用到匿名映射。这里所谓的“大”表示是超过了MMAP_THRESHOLD 设置的字节数,它的缺省值是 128 kB,可以通过 mallopt() 去调整这个设置值。还可以用于进程间通信IPC(共享内存)。

heap堆区:

BBS段和DATA段:

用于存放程序全局数据和静态数据,一般未初始化的放在BSS段(统一初始化为0,不占程序文件的空间),初始化的放在data段,只读数据放在rodata段(常量存储区)。

text段:

主要存放程序二进制代码。

 

进程调度


进程状态机

进程是一个动态的概念,是应用程序当前正在运行的一个实例, 在进程的整个生命周期中,它会处于不同的状态,并且在不同状态之间转化:


Linux调度系统全景指南(下篇)


R (TASK_RUNNING)--执行状态

只有在该状态的进程才可能在CPU上运行。而同一时刻可能有多个进程处于可执行状态,这些进程的task_struct结构(进程控制块)被放入对 应CPU的可执行队列中(一个task最多只能出现在一个CPU的可执行队列中)。进程调度器的任务就是从各个CPU的可执行队列中分别选择一个task在该 CPU上运行。很多操作系统教科书将正在CPU上执行的进程定义为RUNNING状态,而将可执行但是尚未被调度执行的进程定义为READY状态,这两种状态在linux下统一为 TASK_RUNNING状态。


S (TASK_INTERRUPTIBLE)--可中断的睡眠状态

处于这个状态的进程因为等待某个事件的发生(比如等待socket连接、等待信号量,等待锁),而被挂起。这些进程的task_struct结构被放入对应事件的等待队列中。当这些事件发生时(由外部中断触发、或由其他进程触发),对应的等待队列中的一个或多个进程将被唤醒。通过ps命令我们会看到,一般情况下,进程列表中的绝大多数进程都处于TASK_INTERRUPTIBLE状态(除非机器的负载很高)。毕竟CPU就一两个,进程动辄几十上百个,如果不是绝大多数进程都在睡眠,CPU又怎么响应得过来。


T (TASK_STOPPED or TASK_TRACED)--暂停状态或跟踪状态

向进程发送一个SIGSTOP信号,它就会因响应该信号而进入TASK_STOPPED状态(除非该进程本身处于TASK_UNINTERRUPTIBLE状态而不响应信号)。(SIGSTOP与SIGKILL信号一样,是非常强制的。不允许用户进程通过signal系列的系统调用重新设置对应的信号处理函数。)向进程发送一个SIGCONT信号,可以让其从TASK_STOPPED状态恢复到TASK_RUNNING状态。


Z (TASK_DEAD - EXIT_ZOMBIE)--退出状态

进程成为僵尸进程。当父进程遗漏了用wait()函数等待已终止的子进程时,子进程就会进入一种无父进程的状态,此时子进程就是僵尸进程。


D (TASK_UNINTERRUPTIBLE)--不可中断的睡眠状态

TASK_INTERRUPTIBLE状态类似,进程处于睡眠状态,但是此刻进程是不可中断的。不可中断,指的并不是CPU不响应外部硬件的中断,而是指进程不响应异步信号。绝大多数情况下,进程处在睡眠状态时,总是应该能够响应异步信号的。否则你将惊奇的发现,kill -9竟然杀不死一个正在睡眠的进程了!于是我们也很好理解,为什么ps命令看到的进程几乎不会出现TASK_UNINTERRUPTIBLE状态,而总是 TASK_INTERRUPTIBLE状态。而TASK_UNINTERRUPTIBLE状态存在的意义就在于,内核的某些处理流程是不能被打断的。如果响应异步信号,程序的执行流程中就会被插入一段用于处理异步信号的流程(这个插入的流程可能只存在于内核态,也可能延伸到用户态),于是原有的流程就被中断了。


进程上下文切换

上下文切换(有时也称做进程切换或任务切换):是指CPU从一个进程或线程切换到另一个进程或线程。简洁描述一下,上下文切换可以认为是内核(操作系统的核心)在 CPU 上对于进程(包括线程)进行以下的活动:

  1. 挂起一个进程,将这个进程在CPU 中的状态(上下文)存储于内存中的某处;

  2. 在内存中检索下一个进程的上下文并将其在CPU 的寄存器中恢复;

  3. 跳转到程序计数器所指向的位置(即跳转到进程被中断时的代码行),以恢复该进程。


进程优先级

  1. 进程的优先级有动态优先级和静态优先级决定;

  2. 它是决定进程在CPU的执行顺序的数字;

  3. 优先级越高被CPU执行的概率越大;

  4. 内核采用启发式算法决定是开启或者关闭动态优先级,可以通过修改nice级别直接修改进程的静态优先级,而获取更多CPU执行时间;

  5. Linux支持的nice级别从19(最低优先级)到-20(最高优先级),默认只是0。只有root身份的用户才能把进程的nice级别调整为负数(让其具备较高优先级)。

时间片

  • 时间片(timeslice)又称为“量子(quantum)”或“处理器片(processor slice)”是分时操作系统分配给每个正在运行的进程微观上的一段CPU时间(在抢占内核中是:从进程开始运行直到被抢占的时间);

  • 时间片由操作系统内核的调度程序分配给每个进程。首先,内核会给每个进程分配相等的初始时间片,然后每个进程轮番地执行相应的时间,当所有进程都处于时间片耗尽的状态时,内核会重新为每个进程计算并分配时间片,如此往复;

  • 时间片设得太短会导致过多的进程切换,降低了CPU效率;而设得太长又可能引起对短的交互请求的响应变差,不同调度算法,对时间片管理不一样;

  • 通常状况下,一个系统中所有的进程被分配到的时间片长短并不是相等的,尽管初始时间片基本相等(在Linux系统中,初始时间片也不相等,而是各自父进程的一半),系统通过测量进程处于“睡眠”和“正在运行”状态的时间长短来计算每个进程的交互性,交互性和每个进程预设的静态优先级(Nice值)的叠加即是动态优先级,动态优先级按比例缩放就是要分配给那个进程时间片的长短。一般地,为了获得较快的响应速度,交互性强的进程(即趋向于IO消耗型)被分配到的时间片要长于交互性弱的(趋向于处理器消耗型)进程。


调度框架

实际上进程是资源管理的单位,线程才是调度的单位,内核统称为任务调度。操作系统最重要的任务就是把系统中的task调度到各个CPU上去执行, 不同的任务有不同的需求,因此我们需要对任务进行分类:一种是普通进程,另外一种是实时进程。对于实时进程,毫无疑问快速响应的需求是最重要的,而对于普通进程,我们需要兼顾前三点的需求。相信你也发现了,这些需求是互相冲突的,对于这些time-sharing的普通进程如何平衡设计呢?这里需要进一步将普通进程细分为交互式进程(interactive processs)和批处理进程(batch process)。交互式进程需要和用户进行交流,因此对调度延迟比较敏感,而批处理进程属于那种在后台默默干活的,因此它更注重throughput的需求。当然,无论如何,分享时间片的普通进程还是需要兼顾公平,不能有人大鱼大肉,有人连汤都喝不上。为了达到这些设计目标,调度器必须要考虑某些调度因素,比如说“优先级”、“时间片”等。在Linux内核中,优先级就是实时进程调度的主要考虑因素。而对于普通进程,如何细分时间片则是调度器的核心思考点。过大的时间片会严重损伤系统的响应延迟,让用户明显能够感知到延迟,卡顿,从而影响用户体验。较小的时间片虽然有助于减少调度延迟,但是频繁的切换对系统的throughput会造成严重的影响。因为这时候大部分的CPU时间用于进程切换,而忘记了它本来的功能其实就是推动任务的执行。由于Linux是一个通用操作系统,它的目标是星辰大海,既能运行在嵌入式平台上,又能在服务器领域中获得很好的性能表现,此外在桌面应用场景中,也不能让用户有较差的用户体验。Linux任务调度算法核心就是解决调度优化问题:


(1)公平:对于time-sharing的进程,保证每个进程得到合理的CPU时间。

(2)高效:使CPU保持忙碌状态,即总是有进程在CPU上运行。

(3)响应时间:使交互用户的响应时间尽可能短。

(4)周转时间:使批处理用户等待输出的时间尽可能短。

(5)吞吐量:使单位时间内处理的进程数量尽可能多。


Linux调度器采用了模块化设计的思想,从而把进程调度的软件分成了两个层次,一个是core scheduler layer,另外一个是specific scheduler layer:

                        

Linux调度系统全景指南(下篇)


从功能层面上看,进程调度仍然分成两个部分,第一个部分是通过负载均衡模块将各个runnable task根据负载情况平均分配到各个CPU runqueue上去。第二部分的功能是在各个CPU的Main scheduler和Tick scheduler的驱动下进行单个CPU上的调度。调度器处理的task各不相同,有RT task,有normal task,有Deal line task,但是无论哪一种task,它们都有共同的逻辑,这部分被抽象成Core scheduler layer,同时各种特定类型的调度器定义自己的sched_class,并以链表的形式加入到系统中。这样的模块化设计可以方便用户根据自己的场景定义specific scheduler,而不需要改动Core scheduler layer的逻辑。


2个调度器

可以用两种方法来激活调度:

  • 主调度器 :一种是直接的, 比如进程打算睡眠或出于其他原因放弃CPU;

  • 周期性调度器:通过周期性的机制, 以固定的频率运行, 不时的检测是否有必要。

调度策略

linux内核目前实现了6种调度策略(即调度算法),用于对不同类型的进程进行调度, 或者支持某些特殊的功能:

  • SCHED_NORMAL和SCHED_BATCH调度普通的非实时进程;

  • SCHED_FIFO和SCHED_RR和SCHED_DEADLINE则采用不同的调度策略调度实时进程;

  • SCHED_IDLE则在系统空闲时调用idle进程;

  • stop任务是系统中优先级最高的任务,它可以抢占所有的进程并且不会被任何进程抢占,其专属调度器类即stop-task;

  • idle-task调度器类与CFS里要处理的SCHED_IDLE没有关系;

  • idle任务会被任意进程抢占,其专属调度器类为idle-task;

  • idle-task和stop-task没有对应的调度策略;

  • 采用SCHED_IDLE调度策略的任务其调度器类为 CFS。

调度器类

  • CFS (Completely_Fair_Scheduler)

  • Real-Time Scheduler

  • stop-task (sched_class_highest) Scheduler

  • Deadline Scheduler: Earliest Deadline First (EDF) + Constant Bandwidth Server (CBS)

  • Idle-task Scheduler

调度类顺序

  • 优先级顺序:stop-task --> deadline --> real-time --> fair --> idle

  • 在各调度器类定义的时候通过next指针定义好了下一级调度器类;

  • stop-task是通过宏#define sched_class_highest (&stop_sched_class)指定的;

  • 编译时期就已决定,不能动态扩展。

调度实体

这种一般性要求调度器不直接操作进程,而是处理可调度实体, 因此需要一个通用的数据结构描述这个调度实体,即seched_entity结构, 其实际上就代表了一个调度对象,可以是一个进程,也可以是一个进程组,linux中针对当前可调度的实时和非实时进程,定义了类型为seched_entity的3个调度实体:

  • sched_dl_entity 采用EDF算法调度的实时调度实体;

  • sched_rt_entity 采用Roound-Robin或者FIFO算法调度的实时调度实体;

  • sched_entity 采用CFS算法调度的普通非实时进程的调度实体。

调度类算法


CFS(Completely Fair Scheduler)算法(完全公平调度器,对于普通进程)

  • 设定一个调度周期(sched_latency_ns),目标是让每个进程在这个周期内至少有机会运行一次。就是每个进程等待CPU的时间最长不超过这个调度周期;

  • 根据进程的数量,大家平分这个调度周期内的CPU使用权,由于进程的优先级即nice值不同,分割调度周期的时候要加权;

  • 每个进程的经过加权后的累计运行时间保存在自己的vruntime字段里;

  • 哪个进程的vruntime最小(红黑树pick_next)就获得本轮运行的权利。


Realtime Scheduler(实时)

实时系统是这样的一种计算系统:当事件发生后,它必须在确定的时间范围内做出响应。在实时系统中,产生正确的结果不仅依赖于系统正确的逻辑动作,而且依赖于逻辑动作的时序。换句话说,当系统收到某个请求,会做出相应的动作以响应该请求,想要保证正确地响应该请求,一方面逻辑结果要正确,更重要的是需要在最后期限(deadline)内作出响应。如果系统未能在最后期限内进行响应,那么该系统就会产生错误或者缺陷。在多任务操作系统中(如Linux),实时调度器(realtime scheduler)负责协调实时任务对CPU的访问,以确保系统中所有的实时任务在其deadline内完成,为了满足实时任务的调度需求,Linux提供了两种实时调度器:POSIX realtime scheduler(后文简称RT调度)和deadline scheduler(后文简称DL调度器)。

  • Linux 支持SCHED_RR和SCHED_FIFO两种实时调度策略。

    • 先进先出(SCHED_FIFO): 没有时间片,被调度器选择后只要不被抢占,阻塞,或者自愿放弃处理器,可以运行任意长的时间。

    • 轮转调度(SCHED_RR): 有时间片,其值在进程运行时会减少。时间片用完后,该值重置,进程置于队列末尾。

  • 两种调度策略都是静态优先级,内核不为这两种实时进程计算动态优先级。

  • 这两种实现都属于 软实时

  • 实时优先级的范围:0 ~ MAX_RT_PRIO-1

    • MAX_RT_PRIO默认值为 100

    • 故默认实时优先级范围:0 ~ 99。

实时进程的优先级范围[0~99]都高于普通进程[100~139],始终优先于普通进程得到运行,为了防止普通进程饥饿,Linux kernel有一个RealTime Throttling机制,就是为了防止CPU消耗型的实时进程霸占所有的CPU资源而造成整个系统失去控制。它的原理很简单,就是保证无论如何普通进程都能得到一定比例(默认5%)的CPU时间,可以通过两个内核参数来控制:

  • /proc/sys/kernel/sched_rt_period_us
    缺省值是1,000,000 μs (1秒),表示实时进程的运行粒度为1秒。(注:修改这个参数请谨慎,太大或太小都可能带来问题)。

  • /proc/sys/kernel/sched_rt_runtime_us
    缺省值是 950,000 μs (0.95秒),表示在1秒的运行周期里所有的实时进程一起最多可以占用0.95秒的CPU时间。
    如果sched_rt_runtime_us=-1,表示取消限制,意味着实时进程可以占用100%的CPU时间(慎用,有可能使系统失去控制)。


Deadline Task Scheduling

  • DL调度器是根据任务的deadline来确定调度的优先顺序的:deadline最早到来的那个任务最先调度执行。对于有M个处理器的系统,优先级最高的前M个deadline任务(即deadline最早到来的前M个任务)将被选择在对应M个处理器上运行。

  • Linux DL调度器还实现了constant bandwidth server(CBS)算法,该算法是一种CPU资源预留协议。CBS可以保证每个任务在每个period内都能收到完整的runtime时间。在一个周期内,DL进程的“活”来的时候,CBS会重新补充该任务的运行时间。在处理“活”的时候,runtime时间会不断的消耗;如果runtime使用完毕,该任务会被DL调度器调度出局。在这种情况下,该任务无法再次占有CPU资源,只能等到下一次周期到来的时候,runtime重新补充之后才能运行。因此,CBS一方面可以用来保证每个任务的CPU时间按照其定义的runtime参数来分配,另外一方面,CBS也保证任务不会占有超过其runtime的CPU资源,从而防止了DL任务之间的互相影响。

  • 为了避免DL任务造成系统超负荷运行,DL调度器有一个准入机制,在任务配置好了period、runtime和deadline参数之后并准备加入到系统的时候,DL调度器会对该任务进行评估。这个准入机制保证了DL任务将不会使用超过系统的CPU时间的最大值。这个最大值在sched_rt_runtime_us和kernel.sched_rt_period_us sysctl参数中指定。默认值是950000和1000000,表示在1s的周期内,CPU用于执行实时任务(DL任务和RT任务)的最大时间值是950000µs。对于单个核心系统,这个测试既是必要的,也是充分的。这意味着:既然接受了该DL任务,那么CPU有信心可以保证其在截止日期之前能够分配给它需要的runtime长度的CPU时间。

  • deadline调度器是仅仅根据实时任务的时序约束进行调度的,从而保证实时任务正确的逻辑行为。虽然在多核系统中,全局deadline调度器会面临Dhall效应(把若干个任务分配给若干个处理器执行其实是一个NP-hard问题(本质上是一个装箱问题),由于各种异常场景,很难说一个调度算法会优于任何其他的算法),不过我们仍然可以对系统进行分区来解决这个问题。具体的做法是采用cpusets的方法把CPU利用率高的任务放置到指定的cpuset上。开发人员也可以受益于deadline调度器:他们可以通过设计其应用程序与DL调度器交互,从而简化任务的时序控制行为。

  • 在linux中,DL任务比实时任务(RR和FIFO)具有更高的优先级。这意味着即使是最高优先级的实时任务也会被DL任务延迟执行。因此,DL任务不需要考虑来自实时任务的干扰,但实时任务必须考虑DL任务的干扰。

Stop_Sched_Class

stop_sched_class用于停止CPU, 一般在SMP系统上使用, 用以实现负载平衡和CPU热插拔. 这个类有最高的调度优先级,stop调度器类实现了Unix的stop_machine 特性, stop_machine 是一个通信信号 : 在SMP的情况下相当于暂时停止其他的CPU的运行, 它让一个 CPU 继续运行,而让所有其他CPU空闲。在单CPU的情况下这个东西就相当于关中断。一般来说,内核会在如下情况下使用stop_machine技术:


Linux调度系统全景指南(下篇)


Idle_Sched_Class

idle任务会被任意进程抢占,其专属调度器类为idle-task,当CPU没有任务空闲时,默认的idle实现是hlt指令,hlt指令使CPU处于暂停状态,等待硬件中断发生的时候恢复,从而达到节能的目的。即从处理器C0态变到 C1态(见 ACPI标准),让CPU置为WFI(Wait for interrupt)低功耗状态,以节省功耗,多cpu系统中每个cpu一个idle进程。


组调度

linux内核实现了control group功能(cgroup,since linux 2.6.24),可以支持将进程分组,然后按组来划分各种资源。比如:group-1拥有30%的CPU和50%的磁盘IO、group-2拥有10%的CPU和20%的磁盘IO、等等。cgroup支持很多种资源的划分,CPU资源就是其中之一,这就引出了组调度,

linux内核中,传统的调度程序是基于进程来调度的, 以进程为单位来瓜分CPU资源,如果我们想把进程进行分组,以进程组进行瓜分CPU资源,Linux实现了组调度架构来实现这个需求:


Linux调度系统全景指南(下篇)

                          Linux组调度实现架构


  • 在linux内核中,使用task_group结构来管理组调度的组。所有存在的task_group组成一个树型结构(与cgroup的目录结构相对应),task_group可以包含具有任意调度类别的进程(具体来说是实时进程和普通进程两种类别),于是task_group需要为每一种调度策略提供一组调度结构。这里所说的一组调度结构主要包括两个部分,调度实体和运行队列(两者都是每CPU一份的)。调度实体会被添加到运行队列中,对于一个task_group,它的调度实体会被添加到其父task_group的运行队列,因为被调度的对象有task_group和task两种,所以需要一个抽象的结构来代表它们。如果调度实体代表task_group,则它的my_q字段指向这个调度组对应的运行队列;否则my_q字段为NULL,调度实体代表task。在调度实体中与my_q相对的是X_rq(具体是针对普通进程的cfs_rq和针对实时进程的rt_rq),前者指向这个组自己的运行队列,里面会放入它的子节点;后者指向这个组的父节点的运行队列,也就是这个调度实体应该被放入的运行队列;

  • 调度发生的时候,调度程序从根task_group的运行队列中选择一个调度实体。如果这个调度实体代表一个task_group,则调度程序需要从这个组对应的运行队列继续选择一个调度实体。如此递归下去,直到选中一个进程。除非根task_group的运行队列为空,否则递归下去一定能找到一个进程。因为如果一个task_group对应的运行队列为空,它对应的调度实体就不会被添加到其父节点对应的运行队列中;


组的调度策略


组调度的主要针对rt(实时调度)和cfs(完全公平调度)两种类别:


实时进程的组调度

实时进程是对CPU有着实时性要求的进程,它的优先级是跟具体任务相关的,完全由用户来定义的。调度器总是会选择优先级最高的实时进程来运行,发展到组调度,组的优先级就被定义为“组内最高优先级的进程所拥有的优先级。


普通进程的组调度支持(Fair Group Scheduling)

2.6.23 引入的 CFS 调度器对所有进程完全公平对待。但是依然有个问题:设想当前机器有2个用户,有一个用户跑着9个进程,且都是CPU 密集型进程;另一个用户只跑着一个 X 进程,是交互性进程。从 CFS 的角度看,它将平等对待这 10 个进程,结果导致的是跑 X 进程的用户受到不公平对待,他只能得到约 10% 的 CPU 时间,让他的体验相当差。基于此,组调度的概念被引入[6]。CFS 处理的不再是一个进程的概念,而是调度实体(sched entity),一个调度实体可以只包含一个进程,也可以包含多个进程。因此,上述例子的困境可以这么解决:分别为每个用户建立一个组,组里放该用户所有进程,从而保证用户间的公平性。该功能是基于控制组(control group, cgroup)的概念,需要内核开启 CGROUP 的支持才可使用。


信号处理

信号机制是进程之间相互传递消息的一种方法,信号全称为软中断信号,也有人称作软中断。从它的命名可以看出,它的实质和使用很像中断。所以,信号可以说是进程控制的一部分:

Linux调度系统全景指南(下篇)


  • 软中断信号(signal,又简称为信号)用来通知进程发生了异步事件。进程之间可以互相通过系统调用kill发送软中断信号。内核也可以因为内部事件而给进程发送信号,通知进程发生了某个事件。注意,信号只是用来通知某进程发生了什么事件,并不给该进程传递任何数据;

  • 当信号发送到某个进程中时,操作系统会中断该进程的正常流程,并进入相应的信号处理函数执行操作,完成后再回到中断的地方继续执行;

  • 信号分类处理,  第一种是类似中断的处理程序,对于需要处理的信号,进程可以指定处理函数,由该函数来处 理。第二种方法是,忽略某个信号,对该信号不做任何处理,就象未发生过一样。第三种方法是,对该信号的处理保留系统的默认值,这种缺省操作,对大部分的信 号的缺省操作是使得进程终止。进程通过系统调用signal来指定进程对某个信号的处理行为;

  • 在进程表的表项中有一个软中断信号域,该域中每一位对应一个信号,当有信号发送给进程时,对应位置位。由此可以看出,进程对不同的信号可以同时保留,但对于同一个信号,进程并不知道在处理之前来过多少个;


信号分类:

(1) 与进程终止相关的信号。当进程退出,或者子进程终止时,发出这类信号。 
(2) 与进程例外事件相关的信号。如进程越界,或企图写一个只读的内存区域(如程序正文区),或执行一个特权指令及其他各种硬件错误。 
(3) 与在系统调用期间遇到不可恢复条件相关的信号。如执行系统调用exec时,原有资源已经释放,而目前系统资源又已经耗尽。 
(4) 与执行系统调用时遇到非预测错误条件相关的信号。如执行一个并不存在的系统调用。 
(5) 在用户态下的进程发出的信号。如进程调用系统调用kill向其他进程发送信号。 
(6) 与终端交互相关的信号。如用户关闭一个终端,或按下break键等情况。 
(7) 跟踪进程执行的信号。 


多线程信号处理:

  1. 不要在线程的信号掩码中阻塞不能被忽略处理的两个信号 SIGSTOP 和 SIGKILL。

  2. 不要在线程的信号掩码中阻塞 SIGFPE、SIGILL、SIGSEGV、SIGBUS。

  3. 确保 sigwait() 等待的信号集已经被进程中所有的线程阻塞。

  4. 在主线程或其它工作线程产生信号时,必须调用 kill() 将信号发给整个进程,而不能使用 pthread_kill() 发送某个特定的工作线程,否则信号处理线程无法接收到此信号。

  5. 因为 sigwait()使用了串行的方式处理信号的到来,为避免信号的处理存在滞后,或是非实时信号被丢失的情况,处理每个信号的代码应尽量简洁、快速,避免调用会产生阻塞的库函数。

                             


                                        线程

Linux调度系统全景指南(下篇)

    



Linux调度系统全景指南(下篇)

                              线程和进程的关系

根据操作系统内核是否对线程可感知,可以把线程分为内核线程和用户线程


Linux调度系统全景指南(下篇)


分类的标准主要是线程的调度者在核内还是在核外。前者更利于并发使用多处理器的资源,而后者则更多考虑的是上下文切换开销。Linux内核只提供了轻量进程的支持,限制了更高效的线程模型的实现,但Linux着重优化了进程的调度开销,一定程度上也弥补了这一缺陷。目前最流行的线程机制LinuxThreads所采用的就是“线程-进程”一对一模型(还存在多对一,多对多模型)用户级实现一个包括信号处理在内的线程管理机制。


Linux调度系统全景指南(下篇)

        Linux 线程实现采用内核级线程”一对一”模型



内核线程


内核线程是直接由内核本身启动的进程。内核线程实际上是将内核函数委托给独立的进程,它与内核中的其他进程”并行”执行。内核线程经常被称之为内核守护进程,他们执行下列任务:

  • 周期性地将修改的内存页与页来源块设备同步;

  • 如果内存页很少使用,则写入交换区;

  • 管理延时动作, 如2号进程接手内核进程的创建;

  • 实现文件系统的事务日志;

内核线程主要有两种类型:

  • 线程启动后一直等待,直至内核请求线程执行某一特定操作。

  • 线程启动后按周期性间隔运行,检测特定资源的使用,在用量超出或低于预置的限制时采取行动。

内核线程由内核自身生成,其特点在于:

  • 它们在CPU的内核态执行,而不是用户态;

Linux在内核线程架构设计中,内核线程建立和销毁都是由操作系统负责、通过系统调用完成的。在内核的支持下运行,无论是用户进程的线程,或者是系统进程的线程,他们的创建、撤销、切换都是依靠内核实现的。线程管理的所有工作由内核完成,应用程序没有进行线程管理的代码,只有一个到内核级线程的编程接口. 内核为进程及其内部的每个线程维护上下文信息,调度也是在内核基于线程架构的基础上完成。内核线程驻留在内核空间,它们是内核对象。


内核线程就是内核的分身,一个分身可以处理一件特定事情。Linux内核使用内核线程来将内核分成几个功能模块,像kworker,  kswapd, ksoftirqd,  migration , rcu_bh,rcu_schd, watchdog等(内核线程都用[] 括起来)。这在处理异步事件如异步IO,阻塞任务,延后任务处理时特别有用。内核线程的使用是廉价的,唯一使用的资源就是内核栈和上下文切换时保存寄存器的空间,内核线程只运行在内核态,不受用户态上下文的拖累,在多核系统中,很多内核线程都是per cpu运行粒度。



用户线程



LinuxThreads是用户空间的线程库,所采用的是“线程-进程”1对1模型(即一个用户线程对应一个轻量级进程,而一个轻量级进程对应一个特定的内核线程),将线程的调度等同于进程的调度,调度交由内核完成, 有了内核线程,每个用户线程被映射或绑定到一个内核线程。用户线程在其生命期内都会绑定到该内核线程。调度器管理、调度并分派这些线程。运行时库为每个用户级线程请求一个内核级线程。而线程的创建、同步、销毁由核外线程库完成(LinuxThtreads已绑定到 GLIBC中发行)。  在LinuxThreads中,由专门的一个管理线程处理所有的线程管理工作。当进程第一次调用pthread_create()创建线程时就会先 创建(clone())并启动管理线程。后续进程pthread_create()创建线程时,都是管理线程作为pthread_create()的调用者的子线程,通过调用clone()来创建用户线程,并记录轻量级进程号和线程id的映射关系,因此用户线程其实是管理线程的子线程。LinuxThreads只支持调度范围为PTHREAD_SCOPE_SYSTEM的调度,默认的调度策略是SCHED_OTHER。 用户线程调度策略也可修改成SCHED_FIFO或SCHED_RR方式,这两种方式支持优先级为0-99,而SCHED_OTHER只支持0。  

           

Linux调度系统全景指南(下篇)

                            Linux 轻量级进程实现


LinuxThtreads的设计存在一些局限性,导致后面Linux实现了新的线程库NPTL,或称为 Native POSIX Thread Library,是 Linux 线程的一个新实现,它克服了 LinuxThreads 的缺点,同时也符合 POSIX 的需求。与 LinuxThreads 相比,它在性能和稳定性方面都提供了重大的改进。与 LinuxThreads 一样,NPTL 也实现了一对一的模型。


轻量级进程具有局限性:


  • 首先,大多数LWP的操作,如建立、析构以及同步,都需要进行系统调用。系统调用的代价相对较高:需要在user mode和kernel mode中切换。

  • 其次,每个LWP都需要有一个内核线程支持,因此LWP要消耗内核资源(内核线程的栈空间)。因此一个系统不能支持大量的LWP。

优点:

(1)运行代价:LWP只有一个最小的执行上下文和调度程序所需的统计信息。

(2)处理器竞争:因与特定内核线程关联,因此可以在全系统范围内竞争处理器资源。

(4)调度:像普通进程一样调度。


协程

以上描述的不管是中断,进程,线程(内核线程,用户线程(轻量级进程实现))的调度都是由内核掌控,用户并不能直接干预,要在用户态实现对逻辑调度控制,需要实现类似用户级线程,用户级线程是完全建立在用户空间的线程库,用户线程的创建、调度、同步和销毁全部库函数在用户空间完成,不需要内核的帮助。因此这种线程是极其低消耗和高效的。协程本质上也是一种用户级线程实现,在一个线程(内核执行单元)内,协程通过主动放弃时间片交由其他协程执行来协作,故名协程。协程的一些关键点:

  • 任何代码执行都需要上下文(CPU),协程也有自己的上下文,协程切换只涉及基本的CPU上下文切换, 完全在用户空间进行,没有模式切换,所以比线程切换要小,开源libco 的协程切换的汇编代码,也就是二十来条汇编指令,一般切换代价: 协程 < 线程 < 系统调用 < 进程 ;


  • 在多核多线程系统中,线程切换代价比较高(cache miss等),为了减少线程切换,希望在同一个线程内进行不同逻辑的伪并行(实际上还是串行),这样降低了代码逻辑切换代价,但这样并没有拥有真正并发带来的高性能,选择合适的使用场景;


  • 协程存在兼容性问题,协程分为有栈协程和无栈协程实现,对不同系统和处理器要进行兼容,但不同系统对上下文实现,异常等不一样,这样就可能产生不兼容情况,一般用户态的代码都不关心底层差别,而使用协程后的代码兼容性变差。


 

本期结束,我们下期再见!

Linux调度系统全景指南(下篇)

                                       

Linux调度系统全景指南(下篇)

往期推荐

Linux调度系统全景指南(下篇)


           

Linux调度系统全景指南(下篇)

扫码二维码

获取更多精彩内容


以上是关于Linux调度系统全景指南(下篇)的主要内容,如果未能解决你的问题,请参考以下文章

Linux性能优化的全景指南

[QNX 自适应分区用户指南]9.1 线程调度器的注意事项

Linux系统的进程调度

Linux系统进程调度

[QNX 自适应分区用户指南]5 线程调度器详解

linux调度算法的核心思想是啥?