26个版本linux内核的性能对比测试_图文_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
26个版本linux内核的性能对比测试
&&26个版本linux内核的性能对比测试,不知道该选择哪个内核使用的,请下载这个吧!
阅读已结束，下载文档到电脑
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，方便使用
还剩11页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢0}{else}no-cache{/if}" />
linux内核信号是如何处理的？看完全懂了……
linux内核信号是如何处理的？看完全懂了……
电子设计 发表于
当前没有评论，快来抢沙发
linux内核信号是如何处理的？看完全懂了……
电子设计 发表于
本文简单介绍下Linux信号处理机制，为介绍二进制翻译下信号处理机制做一个铺垫。
本文主要参考书目《Linux内核源代码情景分析》《独辟蹊径品内核:Linux内核源代码导读》
首先，先说一下什么是信号。信号本质上是在软件层次上对中断机制的一种模拟，其主要有以下几种来源：
程序错误：除零，非法内存访问&
外部信号：终端Ctrl-C产生SGINT信号，定时器到期产生SIGALRM&
显式请求：kill函数允许进程发送任何信号给其他进程或进程组。
在Linux下，可以通过以下命令查看系统所有的信号：
可以通过类似下面的命令显式的给一个进程发送一个信号：
kill&-2&pid
上面的命令将2号信号发送给进程id为pid的进程。不存在编号为0的信号。
目前Linux支持64种信号。信号分为非实时信号(不可靠信号)和实时信号（可靠信号）两种类型，对应于 Linux 的信号值为 1-31 和 34-64。信号是异步的，一个进程不必通过任何操作来等待信号的到达，事实上，进程也不知道信号到底什么时候到达。本文着重于Linux的信号处理机制，对信号更多的介绍可以参考这里。
一般情况下一个进程接受到信号后，会有如下的行为：
进程对信号的响应
忽略信号：大部分信号可被忽略，除SIGSTOP和SIGKILL信号外（这是超级用户杀掉或停掉任意进程的手段）。
捕获信号：注册信号处理函数，它对产生的特定信号做处理。
让信号默认动作起作用：unix内核定义的默认动作，有5种情况：
a) 流产abort：终止进程并产生core文件。
b) 终止stop：终止进程但不生成core文件。
c) 忽略：忽略信号。
d) 挂起suspend：挂起进程。
e) 继续continue：若进程是挂起的，则resume进程，否则忽略此信号。
注册信号处理函数
如果想要进程捕获某个信号，然后作出相应的处理，就需要注册信号处理函数。同中断类似，内核也为每个进程准备了一个信号向量表,信号向量表中记录着每个信号所对应的处理机制，默认情况下是调用默认处理机制。当进程为某个信号注册了信号处理程序后，发生该信号时，内核就会调用注册的函数。
注册信号处理函数是通过系统调用signal()、sigaction()。其中signal()在可靠信号系统调用的基础上实现, 是库函数。它只有两个参数，不支持信号传递信息，主要是用于前32种非实时信号的安装；而sigaction()是较新的函数（由两个系统调用实 现：sys_signal以及sys_rt_sigaction），有三个参数，支持信号传递信息，主要用来与 sigqueue() 系统调用配合使用，当然，sigaction()同样支持非实时信号的安装。sigaction()优于signal()主要体现在支持信号带有参数。关于这方面的内容，如果想获取更多，也可参考这里。
Linux下信号处理机制
进程如何发现和接受信号？
我们知道，信号是异步的，一个进程不可能等待信号的到来，也不知道信号会到来，那么，进程是如何发现和接受信号呢？实际上，信号的接收不是由用户进程来完成的，而是由内核代理。当一个进程P2向另一个进程P1发送信号后，内核接受到信号，并将其放在P1的信号队列当中。当P1再次陷入内核态时，会检查信号队列，并根据相应的信号调取相应的信号处理函数。如下图所示：
其中，动作c：发现和捕捉信号
信号检测和响应时机
刚才我们说，当P1再次陷入内核时，会检查信号队列。那么，P1什么时候会再次陷入内核呢？陷入内核后在什么时机会检测信号队列呢？
当前进程由于系统调用、中断或异常而进入系统空间以后，从系统空间返回到用户空间的前夕。
当前进程在内核中进入睡眠以后刚被唤醒的时候（必定是在系统调用中），或者由于不可忽略信号的存在而提前返回到用户空间。
进入信号处理函数
发现信号后，根据信号向量，知道了处理函数，那么该如何进入信号处理程序，又该如何返回呢？
我们知道，用户进程提供的信号处理函数是在用户态里的，而我们发现信号，找到信号处理函数的时刻处于内核态中，所以我们需要从内核态跑到用户态去执行信号处理程序，执行完毕后还要返回内核态。这个过程如下图所示：
如图中所见，处理信号的整个过程是这样的：进程由于& 系统调用或者中断& 进入内核，完成相应任务返回用户空间的前夕，检查信号队列，如果有信号，则根据信号向量表找到信号处理函数，设置好&frame&后，跳到用户态执行信号处理函数。信号处理函数执行完毕后，返回内核态，设置&frame&，再返回到用户态继续执行程序。
在上面这段话中，我提到&frame&，frame是什么？那么为什么要设置frame？为什么在执行完信号处理函数后还要返回内核态呢？
什么叫Frame？
在调用一个子程序时，堆栈要往下（逻辑意义上是往上）伸展，这是因为需要在堆栈中保存子程序的返回地址，还因为子程序往往有局部变量，也要占用堆栈中的空间。此外，调用子程序时的参数也是在堆栈中。子程序调用嵌套越深，则堆栈伸展的层次也越多。在堆栈中的每一个这样的层次，就称为一个&框架&，即frame。
一般来说，当子程序和调用它的程序在同一空间中时，堆栈的伸展，也就是堆栈中框架的建立，过程主要如下：
call指令将返回地址压入堆栈（自动）
用push指令压入调用参数
调整堆栈指针来分配局部变量
为什么以及怎么设置frame？
我们知道，当进程陷入内核态的时候，会在堆栈中保存中断现场。因为用户态和内核态是两个运行级别，所以要使用两个不同的栈。当用户进程通过系统调用刚进入内核的时候，CPU会自动在该进程的内核栈上压入下图所示的内容：（图来自《Linux内核完全注释》）
在处理完系统调用以后，就要调用do_signal()函数进行设置frame等工作。这时内核堆栈的状态应该跟下图左半部分类似（系统调用将一些信息压入栈了）：
在找到了信号处理函数之后，do_signal函数首先把内核堆栈中存放返回执行点的eip保存为old_eip，然后将eip替换为信号处理函数的地址，然后将内核中保存的&原ESP&（即用户态栈地址）减去一定的值，目的是扩大用户态的栈，然后将内核栈上的内容保存到用户栈上，这个过程就是设置frame.值得注意的是下面两点：
之所以把EIP的值设置成信号处理函数的地址，是因为一旦进程返回用户态，就要去执行信号处理程序，所以EIP要指向信号处理程序而不是原来应该执行的地址。
之所以要把frame从内核栈拷贝到用户栈，是因为进程从内核态返回用户态会清理这次调用所用到的内核栈（类似函数调用），内核栈又太小，不能单纯的在栈上保存另一个frame（想象一下嵌套信号处理），而我们需要EAX（系统调用返回值）、EIP这些信息以便执行完信号处理函数后能继续执行程序，所以把它们拷贝到用户态栈以保存起来。
以上这些搞清楚之后，下面的事情就顺利多了。这时进程返回用户空间，就会根据内核栈中的EIP值执行信号处理函数。那么，信号处理程序执行完后，怎么返回程序继续执行呢？
信号处理函数执行完后怎么办？
信号处理程序执行完毕之后，进程会主动调用sigreturn()系统调用再次回到内核，查看有没有其他信号需要处理，如果没有，这时内核就会做一些善后工作，将之前保存的frame恢复到内核栈，恢复eip的值为old_eip，然后返回用户空间，程序就能够继续执行。至此，内核遍完成了一次（或几次）信号处理工作。
文章来源专栏关于mount选项
本文所属图书&>&
经过近20年的发展，Linux操作系统已经成为当今最成功的开源软件之一，使用广泛，影响深远。随着Linux操作系统功能的不断丰富和完善，Linux内核的源代码也从最初的几万行增加到如今的数百万行，庞大无比，对于Lin...&&
ext4中增加了很多功能。这些功能多数都可以在生成文件时或挂载时选择启用/禁用。这里介绍可以在挂载中设置的一部分选项（见表3-3）。
mount选项的详细内容请参考mount命令的操作指南或内核文档（Documentation/filesystems/ext4.txt）。
表3-3　ext4的挂载选项
选　　项&说　　明&默　　认&ext4特有
data=writeback&将日志模式设置为writeback&―&―
data=ordered&将日志模式设置为ordered&〇&―
data=journal&将日志模式设置为journal&―&―
journal_checksum&为要写入日志的事务添加校验和&―&〇
journal_async_commit&非同步地将记录写入日志&―&〇
barrier=1&启用写入屏障（barrier）&〇&―
barrier=0&禁用写入屏障&―&―
discard&向下级块设备通知块已释放&―&―
nodiscard&不向下级块设备通知块已释放&〇&―
delalloc&写入时使用延迟分配&〇&〇
nodelalloc&写入时不使用延迟分配。在出现写入请求的当时确保块&―&〇
auto_da_alloc&通过rename进行文件替换、通过truncate后的写入进行文件替换时，不使用延迟分配功能，而是在当时立刻确保块&〇&〇
noauto_da_alloc&rename和truncate处理时也使用延迟分配&―&〇
您对本文章有什么意见或着疑问吗？请到您的关注和建议是我们前行的参考和动力&&
您的浏览器不支持嵌入式框架，或者当前配置为不显示嵌入式框架。
文章下载读书Linux Driver（194）

这个问题挺大的。
2.6 时代跨度非常大，从2.6.1 (2003年12月发布) 到 2.6.39(2011年5月发布), 跨越了 39 个大版本。
3.0(原计划的 2.6.40, 2011年7月发布) 到 3.19（2015年2月发布）。
4.0（2015年4月发布）到4.2（2015年8月底发布）。
总的来说，从进入2.6之后，每个大版本跨度开发时间大概是 2 - 3 个月。2.6.x , 3.x, 4.x，数字的递进并没有非常根本性，非常非常非常引人注目的大变化，但每个大版本中都有一些或大或小的功能改变。主版本号只是一个数字而已。不过要直接从 2.6.x 升级 到 3.x, 乃至 4.x，随着时间间隔增大，出问题的机率当然大很多。
个人觉得 Linux 真正走入严肃级别的高稳定性，高可用性，高可伸缩性的工业级别内核大概是在 2003 年后吧。一是随着互联网的更迅速普及，更多的人使用、参与开发。二也是社区经过11年发展，已经慢慢摸索出一套很稳定的协同开发模式，一个重要的特点是 社区开始使用版本管理工具进入管理，脱离了之前纯粹手工（或一些辅助的简陋工具）处理代码邮件的方式，大大加快了开发的速度和力度。
因此，我汇总分析一下从 2.6.12 (2005年6月发布，也就是社区开始使用 git 进行管理后的第一个大版本），到 4.2 (2015年8月发布)这中间共
51个大版本，时间跨度10年的主要大模块的一些重要的变革。
个人时间，精力，能力有限, 有问题欢迎指出，交流。
慢慢更新，保证填完所有坑，借此机会做个整理 ;-)
调度子系统(scheduling)
概述：Linux 是一个遵循 POSIX 标准的类 Unix 操作系统(然而它并不是 Unix 系统[1])，POSIX 1003.1b 定义了调度相关的一个功能集合和 API 接口[2]。调度器的任务是分配 CPU 运算资源，并以协调效率和公平为目的。效率可从两方面考虑: 1) 吞吐量(throughput) 2)延时(latency)。不做精确定义，这两个有相互矛盾的衡量标准主要体现为两大类进程：一是 CPU 密集型，少量 IO 操作，少量或无与用户交互操作的任务（强调吞吐量，对延时不敏感，如高性能计算任务
HPC), 另一则是 IO 密集型, 大量与用户交互操作的任务(强调低延时，对吞吐量无要求，如桌面程序)。公平在于有区分度的公平，多媒体任务和数值计算任务对延时和限定性的完成时间的敏感度显然是不同的。
为此， POSIX 规定了操作系统必须实现以下调度策略(scheduling policies), 以针对上述任务进行区分调度：
- SCHED_FIFO
- SCHED_RR
这两个调度策略定义了对实时任务，即对延时和限定性的完成时间的高敏感度的任务。前者提
供 FIFO 语义，相同优先级的任务先到先服务，高优先级的任务可以抢占低优先级的任务；后 者提供 Roound-Robin 语义，采用时间片，相同优先级的任务当用完时间片会被放到队列尾
部，以保证公平性，同样，高优先级的任务可以抢占低优先级的任务。不同要求的实时任务可
以根据需要用 sched_setscheduler() API 设置策略。
- SCHED_OTHER
此调度策略包含除上述实时进程之外的其他进程，亦称普通进程。采用分时策略，根据动态优
先级(可用 nice() API设置），分配 CPU 运算资源。 注意：这类进程比上述两类实时进程优先
级低，换言之，在有实时进程存在时，实时进程优先调度。
Linux 除了实现上述策略，还额外支持以下策略：
- SCHED_IDLE 优先级最低，在系统空闲时才跑这类进程(如利用闲散计算机资源跑地外文明搜索，蛋白质结构分析等任务，是此调度策略的适用者）
- SCHED_BATCH 是 SCHED_OTHER 策略的分化，与 SCHED_OTHER 策略一样，但针对吞吐量优化
- SCHED_DEADLINE 是新支持的实时进程调度策略，针对突发型计算，且对延迟和完成时间高度敏感的任务适用。
除了完成以上基本任务外，Linux 调度器还应提供高性能保障，对吞吐量和延时的均衡要有好的优化；要提供高可扩展性(scalability)保障，保障上千节点的性能稳定；对于广泛作为服务器领域操作系统来说，它还提供丰富的组策略调度和节能调度的支持。
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*　重要功能和时间点　-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
- 抢占支持(preemption): 2.6 时代开始支持(具体时间难考，是在 2.5 这个奇数版本中引入，可看此文章[3], 关于 Linux 版本规则，可看我文章[4]).
可抢占性，对一个系统的调度延时具有重要意义。2.6 之前，一个进程进入内核态后，别的进程无法抢占，只能等其完成或退出内核态时才能抢占, 这带来严重的延时问题，2.6 开始支持内核态抢占。
- 普通进程调度器(SCHED_OTHER)之纠极进化史:
Linux 一开始，普通进程和实时进程都是基于优先级的一个调度器, 实时进程支持 100 个优先级，普通进程是优先级小于实时进程的一个静态优先级，所有普通进程创建时都是默认此优先级，但可通过
nice() 接口调整动态优先级(共40个). 实时进程的调度器比较简单，而普通进程的调度器，则历经变迁[5]:
　 1) O(1) 调度器: 2.6 时代开始支持(2002年引入)。顾名思义，此调度器为O(1)时间复杂度。该调度器以修正之间的O(n) 时间复杂度调度器，以解决扩展性问题。为每一个动态优先级维护队列，从而能在常数时间内选举下一个进程来执行。
2)) 夭折的 RSDL（The Rotating Staircase Deadline Scheduler)调度器, 2007 年 4 月提出，预期进入 2.6.2２, 后夭折。
O(1) 调度器存在一个比较严重的问题: 复杂的交互进程识别启发式算法- 为了识别交互性的和批处理型的两大类进程，该启发式算法融入了睡眠时间作为考量的标准，但对于一些特殊的情况，经常判断不准，而且是改完一种情况又发现一种情况。
Con Kolivas (八卦：这家伙白天是个麻醉医生)为解决这个问题提出RSDL（The Rotating Staircase Deadline Scheduler)算法。该算法的亮点是对公平概念的重新思考:
交互式(A)和批量式(B)进程应该是被完全公平对待的，对于两个动态优先级完全一样的 A, B 进程，它们应该被同等地对待，至于它们是交互式与否(交互式的应该被更快调度),　应该从他们对分配给他们的时间片的使用自然地表现出来，而不是应该由调度器自作高明地根据他们的睡眠时间去猜测。这个算法的核心是Rotating Staircase, 是一种衰减式的优先级调整，不同进程的时间片使用方式不同，会让它们以不同的速率衰减(在优先级队列数组中一级一级下降，这是下楼梯这名字的由来),
从而自然地区分开来进程是交互式的(间歇性的少量使用时间片)和批量式的(密集的使用时间片)。具体算法细节可看这篇文章:
3) 完全公平的调度器(CFS), 2.6.23(2007年10月发布)
Con Kolivas 的完全公平的想法启发了原 O(1)调度器作者 Ingo Molnar, 他重新实现了一个新的调度器，叫 CFS。新调度器的核心同样是完全公平性,
即平等地看待所有普通进程，让它们自身行为彼此区分开来，从而指导调度器进行下一个执行进程的选举。
具体说来，此算法基于一个理想模型。想像你有一台无限个 相同计算力的 CPU, 那么完全公平很容易，每个 CPU 上跑一个进程即可。但是，现实的机器 CPU 个数是有限的，超过 CPU 个数的进程数不可能完全同时运行。因此，算法为每个进程维护一个理想的运行时间，及实际的运行时间，这两个时间差值大的，说明受到了不公平待遇，更应得到执行。
至于这种算法如何区分交互式进程和批量式进程，很简单。交互式的进程大部分时间在睡眠，因此它的实际运行时间很小，而理想运行时间是随着时间的前进而增加的，所以这两个时间的差值会变大。与之相反，批量式进程大部分时间在运行，它的实际运行时间和理想运行时间的差距就较小。因此，这两种进程被区分开来。
CFS 的测试性能比 RSDS 好，并得到更多的开发者支持，所以它最终替代了 RSDL 在 2.6.23 进入内核，一直使用到现在。可以八卦的是，Con Kolivas 因此离开了社区，不过他本人否认是因为此事，心生龃龉。后来，2009 年，他对越来越庞杂的 CFS 不满意，认为 CFS 过分注重对大规模机器，而大部分人都是使用少 CPU 的小机器，开发了 BFS 调度器[6], 这个在 Android 中有使用，没进入 Linux 内核。
- 有空时再跑 SCHED_IDLE, 2.6.23(2007年10月发布)
此调度策略和 CFS 调度器在同一版本引入。系统在空闲时，每个 CPU 都有一个 idle 线程在跑，它什么也不做，就是把 CPU 放入硬件睡眠状态以节能(需要特定CPU的driver支持), 并等待新的任务到来，以把 CPU 从睡眠状态中唤醒。如果你有任务想在 CPU 完全 idle 时才执行，就可以用sched_setscheduler()
API 设置此策略。
-吭哧吭哧跑计算 SCHED_BATCH, 2.6.16(2006年3月发布)
概述中讲到 SCHED_BATCH 并非 POSIX 标准要求的调度策略，而是 Linux 自己额外支持的。
它是从 SCHED_OTHER 中分化出来的, 和 SCHED_OTHER 一样，不过该调度策略会让采用策略的进程比 SCHED_OTHER 更少受到 调度器的重视。因此，它适合非交互性的，CPU 密集运算型的任务。如果你事先知道你的任务属于该类型，可以用
sched_setscheduler() API 设置此策略。
在引入该策略后，原来的 SCHED_OTHER 被改名为 SCHED_NORMAL, 不过它的值不变，因此保持 API 兼容，之前的 SCHED_OTHER 自动成为 SCHED_NORMAL, 除非你设置 SCHED_BATCH。
- 十万火急，限期完成 SCHED_DEADLINE, 3.14(2014年3月发布)
此策略支持的是一种实时任务。对于某些实时任务，具有阵发性(sporadic),　它们阵发性地醒来执行任务，且任务有 deadline 要求，因此要保证在 deadline 时间到来前完成。为了完成此目标，采用该 SCHED_DEADLINE 的任务是系统中最高优先级的，它们醒来时可以抢占任何进程。
如果你有任务属于该类型，可以用 sched_setscheduler() 或 sched_setattr() API 设置此策略。
更多可参看此文章：
- 普通进程的组调度支持(Fair Group Scheduling), 2.6.24(2008年１月发布)
2.6.23 引入的 CFS 调度器对所有进程完全公平对待。但这有个问题，设想当前机器有２个用户，有一个用户跑着 9个进程，还都是 CPU 密集型进程；另一个用户只跑着一个 X 进程，这是交互性进程。从 CFS 的角度看，它将平等对待这 10 个进程，结果导致的是跑 X 进程的用户受到不公平对待，他只能得到约 10% 的 CPU 时间，让他的体验相当差。
基于此，组调度的概念被引入[6]。CFS 处理的不再是一个进程的概念，而是调度实体(sched entity), 一个调度实体可以只包含一个进程，也可以包含多个进程。因此，上述例子的困境可以这么解决：分别为每个用户建立一个组，组里放该用户所有进程，从而保证用户间的公平性。
该功能是基于控制组(control group, cgroup)的概念，需要内核开启 CGROUP 的支持才可使用。关于 CGROUP ，以后可能会写。
- 实时进程的组调度支持(RT Group Scheduling), 2.6.25(2008年4月发布)
该功能同普通进程的组调度功能一样，只不过是针对实时进程的。
- 组调度带宽控制((CFS bandwidth control) , 3.2(2012年1月发布)
组调度的支持，对实现多租户系统的管理是十分方便的，在一台机器上，可以方便对多用户进行 CPU 均分．然后，这还不足够，组调度只能保证用户间的公平，但若管理员想控制一个用户使用的最大 CPU 资源，则需要带宽控制．3.2 针对 CFS组调度，引入了此功能[8], 该功能可以让管理员控制在一段时间内一个组可以使用 CPU 的最长时间．
- 极大提高体验的自动组调度(Auto Group Scheduling), 2.6.38(2011年3月发布)
试想，你在终端里熟练地敲击命令，编译一个大型项目的代码，如 Linux内核，然后在编译的同时悠闲地看着电影等待，结果电脑却非常卡，体验一定很不爽．
2.6.38 引入了一个针对桌面用户体验的改进，叫做自动组调度．短短400多行代码[9], 就很大地提高了上述情形中桌面使用者体验，引起不小轰动．
其实原理不复杂，它是基于之前支持的组调度的一个延伸．Unix 世界里，有一个会话(session) 的概念，即跟某一项任务相关的所有进程，可以放在一个会话里，统一管理．比如你登录一个系统，在终端里敲入用户名，密码，然后执行各种操作，这所有进程，就被规划在一个会话里．
因此，在上述例子里，编译代码和终端进程在一个会话里，你的浏览器则在另一个会话里．自动组调度的工作就是，把这些不同会话自动分成不同的调度组，从而利用组调度的优势，使浏览器会话不会过多地受到终端会话的影响，从而提高体验．
该功能可以手动关闭．
- 基于调度域的负载均衡, 2.6.7(2004年6月发布)
计算机依靠并行度来突破性能瓶颈，CPU个数也是与日俱增。最早的是 SMP(对称多处理), 所以 CPU共享内存，并访问速度一致。随着 CPU 个数的增加，这种做法不适应了，因为 CPU 个数的增多，增加了总线访问冲突，这样 CPU 增加的并行度被访问内存总线的瓶颈给抵消了，于是引入了 NUMA(非一致性内存访问)的概念。机器分为若干个node, 每个node(其实一般就是一个 socket)有本地可访问的内存，也可以通过 interconnect 中介机构访问别的 node 的内存，但是访问速度降低了，所以叫非一致性内存访问。Linux
2.5版本时就开始了对 NUMA 的支持[7]。
而在调度器领域，调度器有一个重要任务就是做负载均衡。当某个 CPU 出现空闲，就要从别的 CPU 上调整任务过来执行; 当创建新进程时，调度器也会根据当前负载状况分配一个最适合的 CPU 来执行。然后，这些概念是大大简化了实际情形。
在一个 NUMA 机器上，存在下列层级：
　１.每一个 NUMA node 是一个 CPU socket(你看主板上CPU位置上那一块东西就是一个 socket).
2.每一个socket上，可能存在两个核，甚至四个核。
　3.每一个核上，可以打开硬件多纯程(HyperThread)。
如果一个机器上同时存在这三人层级，则对调度器来说，它所见的一个逻辑 CPU其实是一人 HyperThread．处理同一个core 中的CPU , 可以共享L1, 乃至 L2 缓存，不同的 core 间，可以共享 L3 缓存(如果存在的话)．
基于此，负载均衡不能简单看不同 CPU 上的任务个数，还要考虑缓存，内存访问速度．所以，2.6.7 引入了调度域(sched domain)
的概念，把 CPU 按上述层级划分为不同的层级，构建成一棵树，叶子节点是每个逻辑 CPU, 往上一层，是属于 core 这个域，再往上是属于 socket 这个域，再往上是 NUMA 这个域，包含所有 CPU.
当进行负载均衡时，将从最低一级域往上看，如果能在 core 这个层级进行均衡，那最好；否则往上一级，能在socket 一级进行均衡也还凑合；最后是在 NUMA node 之间进行均衡，这是代价非常大的，因为跨 node 的内存访问速度会降低，也许会得不偿失，很少在这一层进行均衡．
这种分层的做法不仅保证了均衡与性能的平衡，还提高了负载均衡的效率．
关于这方面，可以看这篇文章：
- 更精确的调度时钟(HRTICK), 2.6.25(2008年4月发布)
CPU的周期性调度，和基于时间片的调度，是要基于时钟中断来触发的．一个典型的 1000 HZ 机器，每秒钟产生 1000 次时间中断，每次中断到来后，调度器会看看是否需要调度．
然而，对于调度时间粒度为微秒(10^-6)级别的精度来说，这每秒 1000 次的粒度就显得太粗糙了．
2.6.25引入了所谓的高清嘀哒(High Resolution Tick), 以提供更精确的调度时钟中断．这个功能是基于高清时钟(High Resolution Timer)框架，这个框架让内核支持可以提供纳秒级别的精度的硬件时钟(将会在时钟子系统里讲).
- 自动 NUMA 均衡(Automatic NUMA balancing), 3.8(2013年2月发布)
NUMA 机器一个重要特性就是不同 node 之间的内存访问速度有差异，访问本地 node 很快，访问别的 node 则很慢．所以进程分配内存时，总是优先分配所在 node 上的内存．然而，前面说过，调度器的负载均衡是可能把一个进程从一个 node 迁移到另一个 node 上的，这样就造成了跨 node 的内存访问；Linux 支持 CPU 热插拔，当一个 CPU 下线时，它上面的进程会被迁移到别的 CPU 上，也可能出现这种情况．
调度者和内存领域的开发者一直致力于解决这个问题．由于两大系统都非常复杂，找一个通用的可靠的解决方案不容易，开发者中提出两套解决方案，各有优劣，一直未能达成一致意见．3.8内核中，内存领域的知名黑客 Mel Gorman 基于此情况，引入一个叫自动 NUMA 均衡的框架，以期存在的两套解决方案可以在此框架上进行整合; 同时，他在此框架上实现了简单的策略：每当发现有跨 node 访问内存的情况时，就马上把该内存页面迁移到当前 node 上．
不过到 4.2 ，似乎也没发现之前的两套方案有任意一个迁移到这个框架上，倒是，在前述的简单策略上进行更多改进．
如果需要研究此功能的话，可参考以下几篇文章：
－介绍 3.8 前两套竞争方案的文章：
- 介绍 3.8 自动 NUMA 均衡 框架的文章：
- 介绍 3.8 后进展的两篇文章，细节较多，建议对调度／内存代码有研究后才研读：
－CPU 调度与节能
从节能角度讲，如果能维持更多的 CPU 处于深睡眠状态，仅保持必要数目的 CPU 执行任务，就能更好地节约电量，这对笔记本电脑来说，尤其重要．然而这不是一个简单的工作，这涉及到负载均衡，调度器，节能模块的并互，Linux 调度器中曾经有相关的代码，但后来发现问题，在3.5, 3.6 版本中，已经把相关代码删除．整个问题需要重新思考．
在前不久，一个新的 patch 被提交到 Linux 内核开发邮件列表，这个问题也许有了新的眉目，到时再来更新此小节．可阅读此文章：
========== 调度子系统 结束分割线　==========
内存管理子系统(memory management) [内容多且庞杂，陆续更新，时间待定]时间子系统(timer)中断子系统(interrupt)同步机制子系统(synchronization)文件子系统(VFS, block layer, etc)网络子系统(networking)调试和追踪子系统(debugging, tracing)多核及可伸缩性(SMP, NUMA, scalability)虚拟化子系统(kvm)其他? (想到再补充)
[2] POSIX 关于调度规范的文档:
[5] IBM developworks 上有一篇综述文章，值得一读 :
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1330504次
积分：23710
积分：23710
排名：第337名
原创：725篇
转载：1234篇
评论：71条
(21)(59)(41)(19)(18)(22)(15)(52)(20)(22)(11)(19)(16)(7)(40)(22)(23)(6)(23)(14)(10)(12)(15)(3)(20)(14)(14)(5)(6)(7)(48)(25)(7)(6)(15)(24)(15)(22)(17)(15)(2)(22)(29)(26)(6)(17)(31)(15)(16)(23)(25)(20)(25)(18)(20)(20)(43)(41)(54)(62)(85)(63)(97)(59)(58)(86)(64)(45)(61)(27)(9)(13)(3)(6)