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

基于服务体的操作系统体系结构李宏1，吴明桥，龚育昌,赵振西中国科学技术大学计算机科学技术系，合肥，230027Email:[e-mail]摘要：在分析微内核模型特点的基础上，提出了基于服务体的操作系统体系结构，引入了执行流和服务体等新的系统抽象以及服务体间通信等相应机制。服务体模型具有微内核模型的优点，克服了其效率低下的不足，为融合单内核模型和微内核模型提供了一种途径。除了传统多地址空间操作系统外，服务体模型还可应用在单地址空间操作系统中。关键词：微内核服务体执行流中图分类法：TP316文献标识码：AServer-BlockBasedOperatingSystemArchitectureLiHong,WuMing-Qiao,GongYu-Chang，ZhaoZhen-Xi(DepartmentOfComputerScienceAndTechnologyOfUSTC,HeFei,230027)Abstract:Server-Blockbasedoperatingsystemarchitectureispresentedonthebaseofanalysisofthetraditionalmicrokernel,,introducingsomenewsystemabstractionandpolicysuchasserver-block,executive-streamandthecommunicationbetweenserver-blocks.Server-Blockmodelovercomethepoorperformanceofmicrokernelandprovideaunifiedapproachtomicrokernelandmacokernel。Besidethetraditionalmultiplyaddressoperatingsystem,thenewmodelcanalsobeusedtoimplementthesingleaddressoperatingsystem.Keywords:microkernelserver-blockexecutive-stream1研究背景操作系统内核模型主要分为单内核和微内核两种，单内核模型效率高但结构性、可扩展性、可维护性均存在较大的不足；微内核模型目标是以统一的形式在一个系统内兼容多个不同操作系统，降低操作系统开发维护的开销。微内核模型以线程为系统基本抽象，以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.1执行流在服务体模型中我们以执行流作为系统基本抽象。执行流与线程有类似之处，如具有优③执行流①②执行流通讯控制块通讯控制块④通讯控制块⑤服务体服务体核心内核服务体管理器①原始执行流②虚拟执行流③服务体注册的小端口列表④订阅消息⑤服务体间通过消息进行通讯图一服务体模型结构先级、是调度的基本单位、拥有保存CPU硬件上下文的数据结构等，二者的区别是执行流不与固定的地址空间绑定，或者说执行流不拥有地址空间。进而言之，我们通过将系统拆分成服务体（静态部分）和执行流（动态部分）两个概念以强调CPU运行力的抽象，执行流所代表的就是CPU对机器码执行的抽象。从推动服务体意义上来说各个执行流是等价的，一个任务由哪个执行流完成是无区别的，这就使得执行流能够直接跨越系统组件边界（往往也是地址空间边界）完成服务而不必像微内核模型那样必须使用不同的线程。这种抽象方式的另一个优点是在内存空间的使用可以更灵活以减少不必要的运行开销。应该说执行流是比线程更加基本的概念。执行流根据用途分为普通执行流和工作者执行流两类。普通执行流用来推动用户程序，当用户发出请求时该执行流推动相关服务体完成请求处理，当消息的处理需要在单独的执行流中完成的时候，服务体则为它的某个小端口申请工作者执行流并使用该执行流完成消息的处理。对于频繁经常使用工作者执行流的服务体通过将工作者执行流和小端口绑定以提高效率，绑定方式分为两种：固定式和周期式。服务体使用周期性的工作者执行流完成一些周期性的任务，如协议栈状态维护、缓冲区的刷新等。一个小端口可以同时申请多个工作者执行流以加速处理。系统中每个CPU提供一个原始执行流，如果采用超线程技术（Hyper-Thread）则每个CPU可以提供超过一个的原始执行流。核心内核中的执行流管理器将原始执行流变换成若干个并发的虚拟执行流，核心内核可以说是整个系统的动力之源。2.2服务体概括的说，服物体是具有通讯功能，拥有地址空间、安全控制等资源和属性的能够完成某一功能的代码和数据集合，可以看作是进程和模块这两种分属微内核和单内核两种不同内核模型的概念的一个综合体。服务体是系统的基本组成单位，用户程序包括驱动程序在内的各种功能组件都以服务体的形式存在，传统的用户程序模型(进程/线程）通过运行环境服务体实现兼容。服务体本是一种静态的概念，他的生命周期并不依赖执行流，具有持久性。服务体间基于消息进行通讯，在执行流的推动下进行消息处理。服务体模型中通讯的主体是服务体而不是进程或线程。通信使用的是服务体管理器所提供的服务体通讯机制而不是进程间通讯机制，这一点上与微内核模型有很大的区别。每个服务体可以视情况具有若干个小端口，所谓小端口指的是一个消息处理例程入口以及相应的属性，包括优先级、使用的地址空间、运行栈以及存取权限等信息，执行流只能从小端口进入一个服务体的内部，并根据记录的信息进行资源和状态的切换。由于每个小端口具有不同的控制信息，因此对从不同的小端口进入的执行流服务体也会呈现出不同的视图。一个服务体的所有的小端口都注册在一张表中，该表由服务体管理器负责管理。服务体管理器为每个服务体准备了三个标准的插口：命令插口、异常插口、广播插口。按照执行流流动的方向来分类，命令插口是输入端口，其他为输出端口，是消息的发布点。错误插口、广播插口是两个小端口链表，通过服务体管理器提供的注册机制，一个服务体可以将自己的小端服务体其他服务体注册的小端口异常插口广播插端口命令插口本服务体小端口列表服务体控制块图二服务体管理数据结构口注册在其他服务体的错误插口或者广播插口上来订阅该服务体所发出的异常或广播消息，其结构如图二所示。当在这两个端口抛出消息时，服务体管理器将依次是用所注册的小端口来处理这些消息。如果没有指明，其他服务体发来的请求消息均使用命令端口进行处理。微内核模型在处理消息时线程是不能跨越进程边界去完成服务的，因此引起了过多的上下文切换开销。开销包括：1.选择合适的线程；2.上下文切换；3.地址空间的切换以及由此而带来的数据交换的开销。服务体是在执行流的驱动下运行，因为执行流是等价的，使用哪个执行流并没有区别，所以处理请求时执行流可以跨越多个服务体边界。这样就减少1、2两项的开销。服务体也可以根据需要拥有自己的执行流。一个有趣的结论是在极端情况下如果每个服务体都拥有独立的执行流，服务体模型最终也就退化成微内核模型。我们把该问题放到2.5节中去讨论，有关地址空间的讨论则在2.3节中。2.3地址空间和运行栈服务体的逻辑空间分为基本空间和扩展空间两部分。所有服务体的共享同一个基本空间，根据需要服务体还可以拥有属于本服务体一个或多个扩展空间。基本空间为不同的服务体共享，从而有利于服务体间高效的信息传递,尤其是对经常处理大数据的服务体如文件、网络等。基本空间位于系统地址的高端，且是不可换出的以提高系统的运行效率。服务体对基本空间的访问控制基于capability机制[4][6]，只能访问所授权的地址段从而实现系统的健壮性和安全性。扩展空间是服务体所私有的，私有空间是分页管理的，可以根据需要交换到后备存储器中以优化系统内存的使用。服务体可以将大的私有数据和运行的时候所需要的动态运行库加载到其私有空间中而经常使用的部分被加载到基本空间中以提高效率。由于扩展空间的内容私有于服务体，所以当使用扩展空间的数据作为参数传递给其他服务体的时候，应首先映射到基本空间内。地址的映射由内存管理服务体完成，通过使用Copy-On-Write的机制实现服务体扩展空间内的数据共享。一个服务体可以根据需要可以拥有多个私有空间，从而使所管理数据的容量超过硬件所带来的虚存空间限制。在MiniCoreV