基于服务体的操作系统体系结构

基于服务体的操作系统体系结构基于服务体的操作系统体系结构 李宏 1 吴明桥 龚育昌 赵振西 中国科学技术大学计算机科学技术系 合肥 230027 Email hil 摘要 在分析微内核模型特点的基础上 提出了基于服务体的操作系统体系结构 引入了 执行流和服务体等新的系统抽象以及服务体间通信等相应机制 服务体模型具有微内核模 型的优点 克服了其效率低下的不足 为融合单内核模型和微内核模型提供了一种途径 除了传统多地址空间操作系统外 服务体模型还可应用在单地址空间操作系统中 关键词 微内核 服务体 执行流 中图分类法 TP316 文献标识码 A Server Block Based Operating System Architecture Li Hong Wu Ming Qiao Gong Yu Chang Zhao Zhen Xi Department Of Computer Science And Technology Of USTC He Fei 230027 Abstract Server Block based operating system architecture is presented on the base of analysis of the traditional microkernel introducing some new system abstraction and policy such as server block executive stream and the communication between server blocks Server Block model overcome the poor performance of microkernel and provide a unified approach to microkernel and macokernel Beside the traditional multiply address operating system the new model can also be used to implement the single address operating system Key words microkernel server block executive stream 1 研究背景研究背景 操作系统内核模型主要分为单内核和微内核两种 单内核模型效率高但结构性 可扩 展性 可维护性均存在较大的不足 微内核模型目标是以统一的形式在一个系统内兼容多 个不同操作系统 降低操作系统开发维护的开销 微内核模型以线程为系统基本抽象 以 IPC 为通讯手段 良好的体系结构使得该核模易于维护 易于分布式扩展并且可以模拟其 他操作系统的语义 用户级进程 线程作为系统功能的提供者也给操作系统的调试带来莫大 的方便 可以较为容易构建用户态操作系统的模拟调试环境 微内核的主要缺点是过大的 运行开销 主要集中于过于频繁的上下文切换以及由于进程空间的隔离所带来的进程间通 讯的开销 1 直接使用微内核模型构造实际应用的操作系统是不现实的 使用内核级服务 器代替用户级服务器作为一种改进的思路被提出并重新考虑微内核模型为系统的鲁棒性所 带来的好处 2 在这种思想的影响下微内核模型的典型代表 Mach 的商用版本实现中 文 件 网络以及内存管理等关键代码重新被收到内核中运行在特权模式下 微内核的一种改 进是使用 外核 Exokernel 3 思想将内核服务进一步简化 对外只提供 虚拟机 抽象 基金项目 本项目受到国家自然科学基金项目 60273042 和安徽省自然科学基金项目 03042203 支持 作者介绍 李宏 男 博士研究生 1975 研究方向操作系统 吴明桥 男 博士研究生 1978 研究 方向操作系统 龚育昌 女 博士生导师 1945 研究方向数据库 算法 操作系统 超媒体 赵振西 男 博士生导师 1937 研究方向体系结构 超媒体 操作系统 开放性固件 低功耗 文件 网络 缓存等机制由用户库完成 减少了上下文切换和信息交换的开销具有很高的 效率 MIT 开发的 Aegis 就是在这种思想指导下设计实现的操作系统 单地址空间操作系 统模型 4 8 则从另一个角度避免上下文切换以及信息共享所带来的开销 单地址空间模型 具有良好的运行效率 易于实现单层次以及持久存储系统 单地址空间操作系统面临的主 要困难是要求运行平台提供大的虚拟寻址空间 同时难以完全兼容 UNIX 语义 本文介绍一种新的操作系统内核模型 服务体模型 在服务体模型中消息传递仍然是 通讯的基本方式 这是实现系统灵活性 开放性以及可扩展性的基础 服务体模型中消息 的处理模式只支持同步方式 操作系统的异步功能由相应的服务体实现而不像微内核模型 那样作为一种通讯机制提供给上层使用 这种消息处理模式的设计是基于以下理由的 1 在微内核模型中绝大部分服务都是同步的 也就是 Client 要等待 Server 完成请求处 理 2 跨越服务器边界的通讯切换必然伴随着内存上下文的切换和线程调度 3 操作 系统的异步服务没有必要以一种基础通讯协议的形式提供 异步处理完全可以在同步通讯 协议的基础上加以实现 就如同传统的 UNIX 所实现的异步系统服务一样 同步消息处理模式使我们可以采用一种新的系统抽象 执行流 执行流是比线程更基 本的概念 执行流是 CPU 对指令的执行的抽象 是一种动态的概念 与线程不同执行流不 拥有地址空间 栈等资源 因此执行流可以跨越操作系统功能组件的边界而且使得地址空 间的管理更加具有灵活性 服务体是系统的基本组成单位 是一种静态的概念 服务体拥 有地址空间 运行栈以及安全描述符 数据 代码等资源 依靠执行流完成服务 在这里 执行流体现的是一种 推动力 的作用 通过使用执行流 服务体模型有效的减低了运行 开销同时保持了和微内核模型相当的灵活性和可扩展性 服务体模型的一个有趣的特性是 它能够匀滑的在单内核模型和微内核模型之间进行转变 从而将两种完全对立的模型统一 起来 本文首先详细描述了服务体模型的基本要素和工作原理 然后介绍了一个基于服务体 模型的一个实例 MiniCoreV3 并对其性能进行了分析 2 服务体模型的基本结构 服务体模型的基本结构 服务体模型的基本结构包括执行流 服务体 服务体空间 服务体管理器 核心内核 等要素 各部分的关系如图一所示 服务体是操作系统的基本组成单位 服务体管理器提 供服务体间通讯 服务体异常处理以及消息广播等机制 核心内核是一个特殊的服务体 负责提供如执行流 系统异常 陷入 时钟服务 系统同步等功能 执行流 执行流 通讯控制块通讯控制块 通讯控制块 服务体服务体核心内核 服务体管理器 原始执行流 虚拟执行流 服务体注册的小端口列表 订阅消息 服务体间通过消息进行通讯 图一 服务体模型结构 2 12 1 执行流执行流 在服务体模型中我们以执行流作为系统基本抽象 执行流与线程有类似之处 如具有 优先级 是调度的基本单位 拥有保存 CPU 硬件上下文的数据结构等 二者的区别是执行 流不与固定的地址空间绑定 或者说执行流不拥有地址空间 进而言之 我们通过将系统 拆分成服务体 静态部分 和执行流 动态部分 两个概念以强调 CPU 运行力的抽象 执 行流所代表的就是 CPU 对机器码执行的抽象 从推动服务体意义上来说各个执行流是等价 的 一个任务由哪个执行流完成是无区别的 这就使得执行流能够直接跨越系统组件边界 往往也是地址空间边界 完成服务而不必像微内核模型那样必须使用不同的线程 这种 抽象方式的另一个优点是在内存空间的使用可以更灵活以减少不必要的运行开销 应该说 执行流是比线程更加基本的概念 执行流根据用途分为普通执行流和工作者执行流两类 普通执行流用来推动用户程序 当用户发出请求时该执行流推动相关服务体完成请求处理 当消息的处理需要在单独的执 行流中完成的时候 服务体则为它的某个小端口申请工作者执行流并使用该执行流完成消 息的处理 对于频繁经常使用工作者执行流的服务体通过将工作者执行流和小端口绑定以 提高效率 绑定方式分为两种 固定式和周期式 服务体使用周期性的工作者执行流完成 一些周期性的任务 如协议栈状态维护 缓冲区的刷新等 一个小端口可以同时申请多个 工作者执行流以加速处理 系统中每个 CPU 提供一个原始执行流 如果采用超线程技术 Hyper Thread 则每个 CPU 可以提供超过一个的原始执行流 核心内核中的执行流管理器将原始执行流变换成若 干个并发的虚拟执行流 核心内核可以说是整个系统的动力之源 2 22 2 服务体服务体 概括的说 服物体是具有通讯功能 拥有地址空间 安全控制等资源和属性的能够完 成某一功能的代码和数据集合 可以看作是进程和模块这两种分属微内核和单内核两种不 同内核模型的概念的一个综合体 服务体是系统的基本组成单位 用户程序包括驱动程序 在内的各种功能组件都以服务体的形式存在 传统的用户程序模型 进程 线程 通过运行 环境服务体实现兼容 服务体本是一种静态的概念 他的生命周期并不依赖执行流 具有 持久性 服务体间基于消息进行通讯 在执行流的推动下进行消息处理 服务体模型中通 讯的主体是服务体而不是进程或线程 通信使用的是服务体管理器所提供的服务体通讯机 制而不是进程间通讯机制 这一点上与微内核模型有很大的区别 服务体 其他服务体注册 的小端口 异常插口 广播插端口 命令插口 本服务体小端口列 表 服务体控 制 块 图二 服务体管理数据结构 每个服务体可以视情况具有若干个小端口 所谓小端口指的是一个消息处理例程入口 以及相应的属性 包括优先级 使用的地址空间 运行栈以及存取权限等信息 执行流只 能从小端口进入一个服务体的内部 并根据记录的信息进行资源和状态的切换 由于每个 小端口具有不同的控制信息 因此对从不同的小端口进入的执行流服务体也会呈现出不同 的视图 一个服务体的所有的小端口都注册在一张表中 该表由服务体管理器负责管理 服务体管理器为每个服务体准备了三个标准的插口 命令插口 异常插口 广播插口 按 照执行流流动的方向来分类 命令插口是输入端口 其他为输出端口 是消息的发布点 错误插口 广播插口是两个小端口链表 通过服务体管理器提供的注册机制 一个服务体 可以将自己的小端口注册在其他服务体的错误插口或者广播插口上来订阅该服务体所发出 的异常或广播消息 其结构如图二所示 当在这两个端口抛出消息时 服务体管理器将依 次是用所注册的小端口来处理这些消息 如果没有指明 其他服务体发来的请求消息均使 用命令端口进行处理 微内核模型在处理消息时线程是不能跨越进程边界去完成服务的 因此引起了过多的 上下文切换开销 开销包括 1 选择合适的线程 2 上下文切换 3 地址空间的切换以 及由此而带来的数据交换的开销 服务体是在执行流的驱动下运行 因为执行流是等价的 使用哪个执行流并没有区别 所以处理请求时执行流可以跨越多个服务体边界 这样就减 少 1 2 两项的开销 服务体也可以根据需要拥有自己的执行流 一个有趣的结论是在极 端情况下如果每个服务体都拥有独立的执行流 服务体模型最终也就退化成微内核模型 我们把该问题放到 2 5 节中去讨论 有关地址空间的讨论则在 2 3 节中 2 32 3 地址空间和运行栈地址空间和运行栈 服务体的逻辑空间分为基本空间和扩展空间两部分 所有服务体的共享同一个基本空 间 根据需要服务体还可以拥有属于本服务体一个或多个扩展空间 扩展空间基本空间 图三 服务体空间 服务体 A 服务体 B 运行库 数据 基本空间为不同的服务体共享 从而有利于服务体间高效的信息传递 尤其是对经常处 理大数据的服务体如文件 网络等 基本空间位于系统地址的高端 且是不可换出的以提 高系统的运行效率 服务体对基本空间的访问控制基于 capability 机制 4 6 只能访问 所授权的地址段从而实现系统的健壮性和安全性 扩展空间是服务体所私有的 私有空间是分页管理的 可以根据需要交换到后备存储 器中以优化系统内存的使用 服务体可以将大的私有数据和运行的时候所需要的动态运行 库加载到其私有空间中而经常使用的部分被加载到基本空间中以提高效率 由于扩展空间 的内容私有于服务体 所以当使用扩展空间的数据作为参数传递给其他服务体的时候 应 首先映射到基本空间内 地址的映射由内存管理服务体完成 通过使用 Copy On Write 的 机制实现服务体扩展空间内的数据共享 一个服务体可以根据需要可以拥有多个私有空间 从而使所管理数据的容量超过硬件所带来的虚存空间限制 在 MiniCoreV3 中 Cache 服务 体利用了多个扩展空间从而为每个打开文件分配了更大缓冲窗口 提高了 Cache 性能 服务体的地址空间信息记录在小端口中 同一服务体的不同小端口可以具有不同的地 址空间信息 执行流通过小端口进入服务体时加载该小端口中记录的地址空间信息 如果 服务体只使用基本空间则仅加载存取内存控制信息 系统中的全部执行流由核心内核产生 并默认的绑定核心内核的基本空间 服务体提供执行流运行所需要的栈 当执行流进入通过小端口进入服务体时要进行堆 栈切换 初始的时候执行流的产生者 核心内核为每个新创建的执行流提供一个位于基本 空间的堆栈 出于安全或空间的考虑每个服务体也可以为自己的小端口配备一个或多个分 离的堆栈空间 栈一般位于基本空间内 也可以位于扩展空间以满足对堆栈大小有特殊要 求的情况 一个小端口堆栈的数量决定了能够同时进入该小端口的执行流的数量 从这个 意义上讲每为小端口配备一个堆栈 相当于在微内核模型中为服务进程中增加了一个服务 线程 2 4 核心内核核心内核 核心内核是一个特殊的服务体 它屏蔽了大多数的处理器具体细节 为其他服务体提 供包括执行流管理 中断管理 异常管理 时钟服务 工作者执行流管理以及内核同步等 多种基础机制 核心内核同其他服务体一样 使服务体通讯机制同其他服务体通讯 中断 异常由核心内核捕获并以错误 对异常事件 或者广播 对于中断 的形式向 外发布 消息中包含了异常 中断编号 以及描述该错误的参数如发生错误的指令地址等 需要相关异常 中断消息的服务体可以通过订阅核心内核的相关消息来捕获相应的消息 在 MiniCoreV3 中 Linux 运行环境正是通过订阅核心内核的异常消息捕获系统服务请求的 并将用户请求转发到对应服务体 设备的中断服务例程并不在中断消息中完成 核心内核 实现了一个功能更加完善的实时中断处理机制用以处理设备中断 核心内核负责将系统中的原始执行流变换成若干虚拟执行流 系统中所有的执行流均 由核心内核产生 需要执行流的服务体向核心内核提出申请并注册一个小端口 注册的小 端口中有服务体的地址空间 栈以及消息处理函数地址等信息 发生执行流切换的时候当 前指令寄存器作为新的消息处理函数被写回到该小端口中 在调度的时候原始执行流通过 向所注册的小端口写入一条空消息来恢复该虚拟执行流的运行 3 服务体模型的工作过程服务体模型的工作过程 3 1 建立服务体连接建立服务体连接 使用一个服务体所提供的服务前 首先应该与该服务体建立连接 服务体管理器提供 Connect 命令来完成此功能 目标服务体的每个连接都使得该服务体的引用数增加一 释 放时引用数减一 服务体的引用数为 0 时意味着可以从内存撤出 Connect 根据所提供的 服务体的名字和小端口号给目标服务体发送连接请求消息 由该服务体并对各项安全指标 进行认证 如果通过认证则返回代表连接的描述符 如果目标服务体不存在服务体管理器 则会抛出一个错误 动态加载服务器通过订阅该错误实现服务体的按需加载 3 2 消息的发送和回复消息的发送和回复 服务体管理器提供了基于消息的通讯机制 减在消息的处理上利用执行流的等价性 通过复用执行流避免了不必要的上下文切换开销 在此需要介绍两个具有代表性的核心元 语 PokeMessage ReplyMessage 服务体模型使用 PokeMessage 将消息写入一个服务体的 小端口 ReplyMessage 用来回复消息表明该消息处理完毕 PokeMessage 的算法的算法 输入 消息 目标服务体的小端口 1 对指定小端口进行消息重定向处理 见 2 3 3 节 2 根据小端口的属性切换资源和运行状态包括地址空间 堆栈 调度优先级 存取 控制信息以及运行特权级等 必要时阻塞当前执行流以等待空闲的堆栈资源 3 使用小端口处理该消息 4 检查消息中的 Complete 位是否为 完成 该位由回复元语设置 否则当前执行 流睡眠在该消息上等待该位变为 完成 5 恢复执行流所绑定的资源 ReplyMessage 的算法的算法 输入 消息 1 设置所回复消息体的 Errcode 位和 Complete 位 2 如果有执行流睡眠在消息的等待队列上 则唤醒这个执行流 根据服务体对消息回复的时机可以将消息处理分为立即型和延迟型两类 如图四所示 立即型指的是小端口中的消息处理例程直接完成了消息的处理并在返回前使用 ReplyMessage 对消息进行回复 延迟型消息处理只是将消息暂时挂在消息队列上并不处理 执行流被阻塞在该消息上一直到该消息被处理完毕并回复为止 挂在队列上的消息由其他 执行流负责处理和回复 绝大多数的请求都是立即型的 只有为了优化合并相应的请求或 者使用工作者执行流处理相应的消息等个别情况下才使用延迟型的处理方式 消息处理对提出请求的服务体来说是总是同步的 服务体模型不支持异步通讯方式 这不影响操作系统实现异步的操作 异步功能可以通过服务体间更高层的约定协议来实现 唤醒操作 服务体 消息队列 服务体 等待队列 请求执行流 服务体 立即型 消息队列请求执行流 回复消息 延迟型 其它执行流 图四 消息回复机制 3 3 服务体重定向服务体重定向 消息的重定向可以实现层次化的消息处理 消息重定向系指的是将本来发送到服务体 A 的消息都转发到服务体 B 消息的发送算法需要对消息的重定向进行处理 算法如下 ReplyMessage 的算法 的算法 输入 小端口 1 根据目标服务体的控制块 得到重定向服务体的控制块 2 检查重定向服务体控制块与目标服务体控制块是否相同 如果一致则算法停 止 消息被写入目标服务体的相同名字的端口中 否则将重定向服务体控制块作为 目标服务体句柄并重复步骤 1 使用多个服务体层次会提供很多好处 尤其是对于设备驱动服务体 例如 它允许把 高层协议问题与特定的基础硬件的管理分开 从而有可能支持多种硬件而不必重写许多代 码 并可通过对同一协议设备服务体在运行时插入不同的硬件驱动程序来提高灵活性 还 可把硬件限制对设备的用户隐藏起来 或者增加硬件自身不支持的功能 层次化插入服务 体实现了对系统增加或删除功能的透明的支持 不必对同一个产品维护多个代码 并为动 态的修正系统错误提供了一种方法 3 4 错误和广播错误和广播 服务体模型提供统一的错误以及广播消息处理制 一方面服务体可以从错误端口或广 播端口发布错误或者是广播消息客户 另一方面服务体可以使用自己的小端口来订阅其他 服务体的错误消息或者是广播消息 消息的广播主要用于若干个模块的协调 如通过订阅 内存管理服务体所广播的内存紧缩消息 服务体能够在合适的时候缩减各自的缓冲内存 错误的发布机制则将错误的处理与错误的抛出分离开来从而实现错误处理的结构化 处理一个服务体所发布的错误或是广播的算法基本是相同的 都是依次咨询相应端口 上所注册的小端口 对错误处理而言如果没有任何小端口能够处理所发布的错误消息 则 该错误被转发到服务体管理器的出错端口上 在那里将有默认的动作来处理这些错误 其 他服务体也可以通过向服务体管理器订阅这些错误来改变这些默认的动作 四 基于服务体模型的实现四 基于服务体模型的实现 MiniCore V3 MiniCore V3 7 是使用服务体模型设计实现的操作系统的原型系统 目的是对服务体 模型进行研究 MiniCore V3 使用运行环境服务体来实现现有多地址空间操作系统 如 UNIX 如进程控制 调度机制以及用户 API 在内的基本特征从而兼容不同的操作系统 运行环境通过订阅核心内核的广播消息即捕捉到系统异常以及用户服务请求 Linux 运行 环境订阅了 0 x80 号陷入异常 并转换为对不同服务体的请求消息 这种将异常组织成消息 并通过订阅 广播机制在不同的服务体中传递的机制 使得很多利用异常加速处理的算法 如 Cache 管理 内存有效性检查等以更加清晰的方式组织起来 在 MiniCore 中我们已经实 现了嵌入式实时运行环境 RT 1 和 Linux 的运行环境 其中 Linux 运行环境目前已经实现 60 个核心系统调用 包括文件 内存管理 进程调度 信号处理 网络等部分 支持 Gcc As Vi Telnet 等部分 Linux 应用程序 我们对 MiniCoreV3 性能进行了测试 方法是挑选 Linux 运行环境中有代表性系统服务 统计系统服务总的运行时间和由于服务体模型引入的包括包括通讯和上下文切换在内的运 行开销 通过观察二者的比例来了解服务体模型的运行开销 表 1 是测试结果 这种测试 方法避免了将运行结果直接与 Linux 相比较而带来的不公平 1 Linux 运行环境是重新 编写的 数据结构 算法 程序编制技巧都与 Linux 内核不同 这些因素能够极大的影响 运行时间开销 2 由于所实现的 Linux 运行环境是一个功能子集 由于少了很多功能限 制 这一点也会引起运行时间的不同 以上因素都导致将数据直接对比并不能反映服务体 模型的运行开销情况 在表 1 中 A 是得到进程号 GetPid B 是创建新的进程 Fork C 是内存的匿名映 射 Mmap 映射的内存大小为 1M D 是父进程向子进程发送信号 Kill E 是加载 ELF 格式可执行映像 Execve 表一 Linux 运行环境部分服务测试结果 us 编号 测试服务 总运行时间 服务体机制所耗时间 比例 百分比 A GetPid 0 7 0 087 12 B Fork 450 3 26 6 5 90 C Mmap 95 1 68 1 75 D Kill 16 7 0 13 0 78 E Execve 174352 3 702 2 0 40 从上表可以看出在服务体模型所引入的开销是很小的 为进一步测量消息机制的运行 开销 我们在 MiniCoreV3 的 Linux 运行环境中长时间运行各种程序 然后收集在运行期间 消息机制所占用的时间开销 经过长期运行 采集的数据表明服务体模型各种机制所引起 的平均开销小于百分之 2 微内核模型系统开销则要高于百分之 20 甚至更高 6 表二 路由性能测试结果 CPU8MHz 的嵌入式 i386300MHz 赛扬处理器 RAM2M64M Flash2M无 网络控制芯片83908390 操作系统MiniCore V3Win98 路由软件MiniCore 内置WinGate 转发速度300K S350K S 为对服务体间通讯开销 中断处理以及设备管理 设备驱动程序通讯等综合性能进行 评价 我们研制了一个路由器硬件试验平台 该平台以 MiniCoreV3 作为操作系统 并在 该操作系统上运行了一个网络地址转换程序事先多台计算机共享一个 Internet 连接 该程 序的运行运行数据与 Win98 300MHz 微机的同样数据的测试对比如表二 实验数据表明 二者之间的速度非常相近 考虑到平台间的性能差别 这些数据可以直观的表明服务体模 型在服务体通讯 中断的处理 驱动程序的组织等方面具有很好的运行效率 五五 结论结论 本文介绍了一种新的操作系统模型 提出了执行流 服务体等系统抽象 将单内核模 型特征融合到微内核模型之中因此具有根大的灵活性和高效性 其特点如下 1 保留了微内核良好的结构性和可扩展性 服务体之间通过消息进行信息交换 不 必关心服务体的具体位置使得服务体模型很容易应用在分布式系统当中 另一方面用户可 以根据需要选择满足需要的服务体方便的实现系统功能的剪裁 2 良好的运行效率 在服务体模型中使用了执行流的抽象 由于执行流的等价性因此 可以跨越服务体边界完成用户服务 减少了上下文切换的次数 由于将地址空间与执行流 相分离 地址空间的切换被延迟到必须发生的时刻 并通过共享的基本空间降低了服务体 间信息交换开销 3 提供了统一了单内核模型和微内核模型的一种途径 如果每个服务体只具有基本 空间 不使用分离的栈且消息处理方式都是立即型的 服务体模型就相当于单内核 由于 基于消息的通讯方式 扩展性 错误处理以及对分布式的支持仍然优于单内核模型 如果 每个服务体都具有扩展空间且所有代码 数据均在扩展空间里 使用分离的栈且所有的消 息处理均为延迟型的 服务体模型就成为于微内核 服务体模型的这种特性为操作系统的 设计者