标签：style blog http 使用 os 文件 2014 问题 代码
MINIX3 内核整体架构回顾及内核定
性分析
12.1 注意事项
由于本文档不对 I/O 文件系统做出分析，所以在此不对 MINIX3 整体做出一个分 析，本章主要是针对内核进程分析.并且这里的模型建立是非常理想化的。
12.2 MINIX3 架构
MINIX3 的设计理念就是设计一个比当前主流的系统更加稳定和可靠系统。从而
MINIX3 也就是提出一个非常经典的模式：就是系统服务器进程的概念。这些系
统服务器进程是外核的一部分，但是可以和内核通信。最为重要的设计理念是这
些服务器进程既然作为用户进程的一部分，那么他们具有绝对的独立性，每一个
进程都是相互独立存在的。每一个进程都是运行在可靠的内核上。如下图所示：
这种设计理念和传统的 LINUX/UNIX 的设计方法是不一样的。在 LUNIX/UNIX
中，设计是将服务器进程都移到内核中，也就是服务器进程之间就会产生绝对的
联系，就是一个单核系统。传统 LINUX/UNIX 的设计理念就会导致一个非常重
要的问题：就是内核 bug。代码量越大，内核 bug 就会越多，这个是无法避免的。
所以 MINIX3 就从设计方法来改变这个问题。也就是提出了上面的设计方法。
同时,MINIX3 设计者也是保持用一些直白的技术保持代码的简单性，而不会为了
这个所谓的目标资源优化而做出复杂的代码。事实上,MINIX3 就是用了非常简单
188
的 MMU 机制（在这个版本的内核中，MMU 其实非常小，小道不会单独出一个 服务进程来，而是附属在 PM 进程），甚至都没有虚拟内存的概念。这个也主要 体现了一种设计简单性的理念。
对于内核部分，我们从前面章节的也能够分析出来，微内核主要就是上图所示的 时钟任务，中断异常处理机制，进程通信，系统任务，调度机制。这几个都是一 个操作系统内核所必须具备的。必须要在内核中。
对于用户态的进程而言，MINIX3 所赋予的进程功能也是非常丰富的，就前面章 节的分析而言，它具备了很多内容，比如进程间的通信，通过调用内核消息机制 原语。拥有自己的独立地址空间等。而进程间的通信也是通过相应的消息机制实 现，这种消息机制也能够实现一个非常完美的异步过程。如果没有接受消息，就 阻塞自己。这也就表明了一个非常基本点：进程可以实现异步。同样系统进程间 还提出了一个通知，这个通知是为了提供一个更加高效的消息通信而设立的。 对于服务器进程，为了能够和 POSIX 接上轨，在服务器进程端提供了符合 POSIX 标准的系统调用，等待准备接受用户的调用。
事实上，MINIX3 的服务器进程还提供了自我修复的功能，具体内容需要参考相 关文献。
Minix3 设计者提出 MINIX3 的设计非常可靠的是点理由[1],简要在这里描述一
下：
1 运行在内核态模式下的代码数量是非常小的，真正内核态的模式下的代码就只 要几千行，和 LINUNX/UNIX/WINIDOWS 的几千万行相比，差距还是非常大的。 MINIX3 能够保证单独一个程序员能够阅读完整个内核。
2 尽管将服务器移到内核外，不能避免 bug，但是有一点，它可以大大的减少 bug 的存在。
比如一个驱动进程 如果是在内核态的话，它可以执行关开中断命令，只要有一 个语句出问题，就可能毁掉整个内核。
3（I/O 我们没有接受，但是这点好理解）我们认为驱动器是运行在用户态，也就 没有办法执行关中断 开中断这种特权指令。这也就为提供一种保护而做出了不 朽的努力。
4 进程间的通信是通过使用固定格式的消息模式，这样对于分配固定的空间是很 有用的，这样也是提供了一种安全的方法。（当然，我个人认为这种方法会导致 了一种呆板）
5 中断和消息传递都是非常简单的，中断发生时，相关驱动器就会被通知，如果
驱动器等待，则就接受，不等待，就阻塞。这种简单的模式也是提供一种安全的
方法
剩余几点就参看[1],主要是由于剩余几点都涉及到驱动那一块，在这里就不给予 分析。
12.3MINIX3 的系能分析
单独将 MINIX3 和 LINUX/UNIX 比较，MINIX3 是呈现弱势的，但是究竟是因
为核而导致的吗？这个不能完全肯定，比如在服务器进程中，MINIX3 和
LINUX/UNIX 是采用不同的文件系统，不同的内存管理，这个很难去比较核的
内容。事实上，如果要单独比较核，外核算法完全一致。事实上，这种情况是不
189
可能实现的。所以就性能的比较还是和以前的版本比较比较好：
这里我附录衣服图[1]呈现出 MINIX2 和 MINIX3 的一个性能比较：
我们可以看到，MINIX3 和 MINIX2 相比较，的确要慢，大概要慢 1.12%，但是 MINIX2 的设计理念和 MINIX3 有很大的差别。MINIX3 的安全性得到很大的提 高。MINIX3 的设计者也认为，用这种速度的降低来换取安全，是值得的。MINIX3 的设计理念就是可靠性。
MINIX3 单独内核模块的分析：
整体而言，每一个模块都不是相对独立的，都是相互调用的，相互产生联系的， 就相当于一个有向连通图。整体而言，如下图所示：
190
这里的内核中心可能是上面四种的任何一个部分。体现了一种间的反应。 我们现在来比较详细的看看这几个模块的相互发生怎么样的联系：
191
这个图明显是一个有向有环图，没有始发点，就随便跳出一个分析：
从时钟任务开始把：时钟任务由硬件触发，准确的说是时钟硬件触发时钟中断，
也就是到了中断机制，之后中断机制进行相关处理触发到消息机制，消息机制触
发时钟机制运行。时钟机制又会调用调度算法，调度算法，调度算法可能会触发
消息机制，消息机制也就触发了系统任务调用相关函数。这里从时钟机制遍历了
图的大部分。
调度机制： 调度机制的话，与外界的接口就是 enqueue/dequeue 函数，时钟任务 和消息机制都会触发整个调度机制，调度机制相对比较隔离，最多就是想调用系 统函数，通过消息机制向系统任务发送。
中断机制：中断机制是内外接口的一个非常重要的机制，在内核部分，主要可能 就是由时钟触发，中断机制会导致什么内核动作呢？如果我把这里的中断机制包 括了陷入，那么他就会触发_sys_call，这里会触发消息机制，消息机制自然可能 从各个出口出去。如果仅仅就是中断机制，它所完成的动作非常的简单，就是做 出一些处理，就返回。
系统任务：主要就是接受消息机制的调用，它的功能也是相对比较独立，接口就
是调用消息机制所传来的向量号，之后调用相关的函数，之后就完成了它的任务。
这就是内核的微观的分析。这里讲解的比较简单，具体还是要参考各个章节分析。
12.4 MINIX3 内核部分定量分析尝试
进程 U1，U2,„„„„Un 为用户进程
系统内核进程有 CLOCK,SYSTEM 记为：CP,SP,
中断系统 通信机制系统,调度机制不隶属任何一个进程。记中断系统为 IP,通信机 制记作为 IPC,调度机制记 SC
记一个单元花费时间通用记号为：T
为了建立一个合适的理想模型：我们认为单位时间内服务器进程或者是用户进程 会有 N1
次中断请求，发送 N2 次消息。消息处理通用平均处理时间记为 TIPC,调度机制 通用处理时间为 TSC,时钟内核通用处理时间为 TCP,系统任务通用处理时间为 TSP.中断通用处理程序耗时是 TIP,剩下的变量就会遇到时就给予介绍！
192
定理一：有 N 次消息进入内核，则内核一定会调用 N 次调度通用处理函数。
证明分析：试想下消息机制的原理，如果一个进程发送一个消息，如果对方处于 阻塞状态，则自己就会调用一次 enqueue，如果对方在就就绪状态，则自己就会 调用一次 dequeue。一个进程的接受过程也是这样处理的。所以 N 此消息进入内 核，则内核一定调用 N 次调用函数。
定理二：N 次消息进入内核，这 N 次消息都是使得 SYSTEM 进程进入调度队列 证明分析：内核中只有 2 个进程，消息机制就是从 A 进程发到 B 进程，并且 CLOCK 进程只接受时钟硬件中断，所以最终进入内核的消息机制只会进入 SYSTEM 进程。
引理：由 N 次消息进入内核会导致触发 N 次消息。
分析：由定理 2 知，N 次消息进入内核都是到了 SYSTEM 进程，由 SYSTEM 进 程源码知最终会发送一个 lock_send()进程，也就是说，其会触发 N 次消息
引理：N 次外核中断会触发 N 次内核中断处理程序。
这个引理非常的显然，就此忽略。
现在我们从内核的角度来分析：内核的相互触发过程最核心的就是时钟硬件产生
193
的中断。在这里，我们同样定义几个变量：
单位时间内，时钟产生硬件中断的次数是 H1，触发消息机制的次数是 H2 ，这 H2 会触发 H3 次调度算法函数。
只分析整个内核消耗的总平均时间＄
定理 3：
＄=N1*TIP+N2*（TSP+2*TIPC*TSC*2）+（H1*TCP+H2*TIPC+H3*TSC）
证明：整体内核消耗时间是包括处理外核发来的消息，外核产生的中断，以及内 核产生的时钟中断。每次外核产生的中断导致了耗时 TIP。所以这一部分等于 N1*TIP。每次外核发送消息到内核，其会产生一个消息处理耗时，一个调度函数 消耗，一个消息发送耗时，以及这个消息发送耗时导致的调度函数消耗，还有一 个系统通用处理程序耗时。也就是 TSP+2*TIPC+2*TSC
内核时间中断，就以 H1 次为例，H1 触发 H1 次时间中断处理通用程序耗时，其 中有 H2 次触发消息机制，这 H2 次中又会触发 H3 次调度函数。所以耗时就是 H1*TCP+H2*TIPC+H3*TSC
最终＄=＄=N1*TIP+N2*（TSP+2*TIPC*TSC*2）+（H1*TCP+H2*TIPC+H3*TSC）
证毕
最后结束语：这个章节只是一个常识性的分析，特别是在量化方面，量化方面非 常难，这里很多问题都没有考虑到，建立的模型是非常理想化的。但是真正的实 际的 MINIX3 投入真正的使用时，会比这个要复杂的多。但是这种尝试的量化分 析对进一步了解内核各个怎么相互作用和相互调度有非常大的帮助！最后祝读者 能够有个轻松快乐的内核之旅！
标签：style blog http 使用 os 文件 2014 问题 代码
原文地址：http://www.cnblogs.com/sfwtoms/p/3929470.html
