中文翻译网络子系统设计.docx
《中文翻译网络子系统设计.docx》由会员分享，可在线阅读，更多相关《中文翻译网络子系统设计.docx（20页珍藏版）》请在冰点文库上搜索。
中文翻译网络子系统设计
网络子系统设计
单纯使用技术来避免工作站上CPU和存储器的瓶颈是不够的，必须要把技术集成起来。
PeterDruschel,MarkB.Abbott,
MachaelA.Pagels,LarryL.Peterson
新兴的网络技术期望给终端工作站提供接近1Gbps的传输带宽，这样的带宽足以带动一类新的应用火热起来。
然而，这些得益于高速网络的应用受到一些因素的制约，其中的一个重要因素就是运行在工作站上的操作系统。
操作系统必须将良好的网络吞吐率转换为良好的应用程序间吞吐率。
Arizona大学的网络系统研究小组（NetworkSystemsResearchGroup,以下简称NSRG）正在研究操作系统支持高速网络的相关问题。
这些实验性的工作是在MachOS操作系统的x核心[1]环境下完成的。
研制的系统运行在DecStation5000/200以及HP9000/720工作站上，这些工作站连接着ATM网络和FDDI网络。
大体来讲，Mach系统提供了一个基于微内核的操作系统框架，而x内核相当于其中的网络子系统。
我们先在逻辑上将所有的网络协议集中于单个x内核协议树中，然后在物理上将这个图结构分布在整个系统中，包括操作系统和应用程序保护域（applicationprotectiondomain）。
例如，图1描述了一个协议树，它连接了一个应用程序、一台专用网络服务器，以及内核。
一个特定的协议属于哪个保护域要等到配置时（不是操作系统设计时间）才能决定，从而也能够根据系统配置员对于性能和信任处理的意愿程度。
要优化这种结构的性能，就必须解决工作站的存储器结构限制。
问题在于工作站存储器性能的提升跟不上处理其性能和网络带宽提升的步伐。
例如，Hennessy和Patterson报告指出，自从1985年以来，处理器的性能一直以每年50%-100%的速率提升，而存储器的性能提升速率只有7%。
而且，我们希望这种趋势能够持续下去，因为处于开销的考虑，我们将会避免在这类机器上使用非常快的主存和互联技术。
应当记住我们考虑的是数据在一个基于微内核的系统中的流动，在这种系统中，设备驱动程序、网络协议以及应用软件都可能驻留在不同的保护域中。
我们相信把话题集中于此是很适合基于微内核的系统的优点的（可配置性、可分布性以及可移植性），也适合于当前商业领域中对这类系统的支持趋势。
我们想说明的是，在不考虑操作系统结构的情况下，取得高的应用带宽也是可能的。
本文讨论了工作站CPU/存储器的带宽和网络的带宽将保持在同一个数量级，从而，网络子系统必须要致力于使网络数据在CPU/存储器数据路径上的跳步数最小。
本文也对一些应用于这些问题的技术进行了研究，得到的一个重要结论是单纯的应用这些技术对取得应用程序间吞吐率是不够的，也必须把从一个源设备，通过操作系统，到达应用程序，还可能到达终端设备的整个数据路径集成起来。
本文在总结中列出了一个使端对端吞吐率得到最优化的完整数据路径。
工作站硬件的性能
在这一节中我们分析桌面工作站硬件影响输入输出数据流量的性能参数，包括了对目前商用工作站的测试以及下一代工作站相关参数的预测。
表1中给出了四种商用工作站存储子系统的存储器峰值带宽（取自于硬件规格），以及部分CPU/存储器带宽测量数据。
存储器峰值带宽是存储子系统在突发模式传输下能够达到的带宽。
括号中给出的是测量到的带宽对峰值带宽的比例。
图1:
分布式协议图
表1：
一些工作站的存储器带宽
表1中的CPU/存储器带宽数值是使用一个普通测试台程序测算得到的。
该测试台程序测试的是一组读、写、复制操作过程中支持的带宽。
测试台程序用C语言编写，在各工作站自身的C编译器下编译，并得到了最高级的优化，但是C源代码或者生成的机器代码没有针对特定机器进行改写。
“读”、“写”两列测试的是对一个数组中单元素进行读（写），而“复制”列使用了两种方法测量：
一种是数组元素形式的赋值，另一个是调用库函数bcopy（）。
测试台程序使用了int类型（32位）和double类型（64位）数组，给出的数据都是各自条件下所能取得的最佳值。
测试的主要结果是标准带宽仅为峰值带宽的一小部分，特别是读带宽为峰值带宽的15%~38%，复制带宽仅为10%~19%。
带宽的下降是由两方面局限性综合影响的结果：
第一，编译器生成的机器代码和厂家提供的bcopy（）函数对于执行基准程序故意设定的工作是不够理想的。
但是我们尽量不排除它，因为这个局限性对真实程序同样会有影响。
第二，硬件强制性会限制带宽，即CPU能支持的带宽是有限的。
尽管动态RAM存在很大的相关访问延迟，所有存储子系统都使用了某些形式的流水线（交叉式/页式）来获得高带宽。
在传输时间中初始化延迟是比较大的，所以对于少量数据传输其平均带宽会降低。
由于传输线路宽度限制，Cache和存储器之间的数据传输不能获得大部分的峰值带宽。
由此我们得出，当前工作站的CPU/存储器带宽不超过其网络带宽的规定量级——几百Mbps。
下一代工作站将支持1Gbps网络适配器，它可以以网络速率将数据传送到主存。
持续增长的CPU速度不久将允许以该速率处理软件数据。
例如，DEC公司的Alpha处理器首次运行，允许以1Gbps带宽传输数据流，每个机器字包含12~24条可执行的CPU指令。
然而，人们没有把希望寄托在CPU/存储器带宽的急剧增加上。
存储器峰值带宽可以通过增加存储器宽度来提高，但是，Cache的线宽必须成比例的增加才能实质性的增加CPU带宽。
因此，就是要找到一个理想的合适的比率，很明显如果太小就不能获得大部分的峰值带宽。
另一个方法是降低传输延迟，但是动态RAM（DRAM）的访问时间被认为已经接近其技术极限。
几个最近公布的器件在DRAM上集成了Cache来降低平均访问延迟[4]。
这些集成的二级Cache使用大线宽，用宽数据通路与DRAM相连。
对于任何Cache，其合适的比率的设定依赖于它们所处的位置。
我们下边将要谈到数据I/O访问表现很差。
因此，我们希望下一代桌面工作站的CPU/存储器带宽和网络带宽处于同一量级。
数据Cache的作用
工作站使用Cache来缓冲CPU与主存之间的速度差。
该思想是在CPU附近设置一个高速存储器，用来存储主存中部分数据。
Cache通过降低数据和指令的平均访问延迟来提高系统性能，也降低了在共享存储器的多处理器系统中对存储器的争夺。
然而，Cache的效果受到一些因素的影响：
如Cache的大小和组织，数据访问的位置和处理器调度。
假设系统支持处理全部应用级高带宽数据，处理数据时需要CPU对数据单元的每个字进行检查和可能的修改，潜在的多次访问。
（下一节将确定几个数据可能通过CPU/存储器数据通道的原因。
）本节讨论数据Cache在避免CPU/存储器间传输上效果不明显。
考虑以下重要因素：
处理器调度——CPU调度可能导致在执行其它程序时插入对数据单元的处理进程，当
返回重新执行时，很可能缓冲的数据已经被替换。
在一个多处理器系统上，进程可能被拥有自己数据缓冲的不同的CPU重新调度。
在处理数据单元时有几种情况会发生调度：
当数据单元要被传递给另外的线程（如队列），处理器必须调度执行该线程；在某种协议下，队列典型性的产生在用户和系统接口处，在设备驱动的中断句柄和驱动的顶层之间；在最差的情况下，在协议层之间会产生附加队列；还有硬件中断及信号触发处理器重新调度的事件。
写策略——多处理器数据Cache通常采用写穿透策略，即每个写操作都要写回主存。
写
缓冲与写穿透Cache一起被使用来减少CPU回写存储器的时间。
但是，许多连续写——如要对一个数据单元读写每一个字时将发生——仍然会造成CPU执行存储指令时等待。
Cache查找——Cache实际上是索引和标记，访问Cache中的数据不需要虚存地址到物
理地址的译码。
以这种方法，从虚拟共享页来的缓冲数据若超过保护域边界就不能保持其有效，物理上标记的缓冲不存在这样的问题。
但是，需要一个包含参考数据的辅助翻译缓冲（TLB）处于活跃状态。
Cache容量——数据Cache速度很快，容量有限。
因为留在Cache中的数据检查和修改
的过程包括读取和存储每个字，所以Cache必须至少是数据单元的两倍大。
在实际情况下，由于Cache有限的连接产生线路冲突和在数据处理过程中要访问程序变量使得对Cache容量的要求进一步增加了。
为了量化数据Cache处理网络数据的效果，我们进行了一些初步的实验，测量了在操作系统运转以后驻留内存的网络数据量。
这个值反映了由于缓冲网络数据，避免了CPU/存储器数据传输给用户进程带来的潜在的好处。
它给出了Cache在没有网络数据复制情况下能提供的最大好处。
这些实验是在装有Mach3.0（MK67）的HP9000/720工作站上运行的。
这些工作站配有256KB虚拟索引物理标记的数据Cache。
Mach3.0运行着称为via的UNIX操作系统和称为UnixServer的用户进程。
UnixServer接收用户进程的请求UNIX系统调用信息，并由Mach的微内核来使能设备请求的的处理。
到达的网络报文被微内核通过中断服务机制接收，复制并压缩为一个Mach信息，然后发送给UnixServer通过其协议栈来处理。
如果一个网络报文包含的数据被另一个用户进程预定，它必须从UnixServer的地址空间复制到目标地址空间。
由于Mach的Unixserver包含了典型UNIX单片机上的全部网络代码，所以它接收网络数据信息并将其复制到最终用户这个过程接近于模拟了UNIX单片机处理网络报文的过程。
实验测量了在UnixServer将网络数据复制到其用户地址空间之前，驻留Cache的网络数据量。
如果UnixServer执行一个随意复制的网络数据系统，UnixServer在复制点所能看到的在Cache中的驻留部分也将被接收用户进程看到。
公布的结果是在关闭UDP校验时获得的，若打开校验，Cache中的驻留部分将会增加，因为上下文切换的机会将降低并且校验码会导致对大量缓冲报文数据的读取。
对于MachUnixServer在收集数据方面的修改细节见参考文献[5]。
收集实验数据会出现两种情况：
第一，接收处理器仅运行普通的系统程序和实验接收程序的轻负载状态；第二，接收处理器正在接收从第三方处理器快速传送的8000字节UDP报文的重负载状态。
图2画出了200次测试时钟周期数的算术平均值，对比了要访问的网络缓冲数据是否全在Cache中和UDP数据包大小的关系。
“100%未命中”曲线显示在网络数据缓冲中使用全部的Cache线，将数据从主存读到Cache中需要的时钟数。
注意我们测试的两种情况下的数字均超过了100%Cache未命中时的结果。
图2：
网络缓冲数据超额访问时间
在我们的定时循环中，还有三方面可可能增加时钟周期数：
第一，因为UnixServer是一个用户进程，在定时循环发生时可能会被切换，如果这种情况发生，测量时间将会增加超过10000个时钟周期。
这个事件反映在数据上是很明显的，所以在图像上已经被排除。
第二，I/O设备的直接存储器访问（DMA）会增加执行访存指令的时钟周期数，使得在DMA传输结束之前防止Cache访问存储器。
尤其是在以太网设备使用DMA在网卡和存储器之间传送数据这种重负载的情况下，这类影响最为明显。
第三，HP720处理器使用虚地址物理标记Cache，在访问Cache时，处理器的TLB中应该存在其入口。
实验数据表明，在Mach3.0环境下，如果TLB中没有入口，则需要130个时钟周期的处理时间。
根据Mach中使用的管理TLB重新加载的算法和网络数据缓冲的组织结构，对于一个单缓冲访问可能需要加载4个TLB。
图中“100%TLB和Cache未命中”曲线显示了最差情况下TLB和Cache未命中所需的时钟周期数的累积值，提供了假设DMA在最小功效时的上限访问时间。
有趣的是，重负载时要比轻负载时访问时间短。
由于一个4KB的存储页可以容纳1个以上的网络缓冲，我们设定在重负载情况下将大量发送的网络数据提前加载到TLB存储页，以满足该特殊发送方的需要。
为了减小TLB加载的影响，我们做了另一个实验。
在定时循环之前，网络缓冲所在的存储页被加载到TLB中，并且特别小心的保证了在加载TLB时没有网络缓冲被加载到Cache。
图3：
强行加载TLB情况下网络缓冲数据超额访问时间
在图3中，我们发现所有的测量时间均低于“100%修改后Cache未命中”曲线，并且重负载时间现在要比轻负载时间长。
轻负载时间的线性程度指出与其考虑大约72%的未命中率的已修改的Cache线路，不如关注100%未命中率的未修改的Cache线路。
实验论证了存在三个限制网络缓冲数据访问时间的重要因素：
第一、其它系统设备使用DMA操作时，增加了对存储器访问的争夺，它将显著增加把数据调入处理器Cache的时间，因而增加了平均数据访问时间；第二、在物理标记Cache上，由于网络数据分布在多个虚存页上，这种碎片性导致了对TLB争夺，产生了大量的额外访问开销；最后，消除了TLB争夺后，我们测试平均Cache命中率为28%，这是Cache对于在UnixServer和用户地址空间之间传输网络数据所产生的最小的积极作用。
避免数据传输
前两节证明了我们的论点，即工作站的CPU/存储器带宽应不超过网络带宽的量级，数据Cache在降低CPU/存储器之间网络数据流量上收效很小。
因此，为了保持来自网络设备并通过操作系统、应用程序和可能的下一级设备（如显示器）的数据通路的带宽，就要避免在CPU和存储器之间的频繁的数据传输。
以下每个小节确定了一个潜在的在该通路上的数据传输，并简要描述了几个能够有效处理或避免它的技术，同时给出了这些技术的假设前提和局限性。
设备/存储器数据传输
主存与网络或设备适配器之间的数据传输。
通常使用的技术是DMA和程控I/O（PIO）。
DMA指I/O适配器不通过CPU直接与主存传输数据。
PIO需要处理器执行一段循环程序逐字传输主存和I/O适配器的数据。
使用DMA通常可以在单总线条件下传输大的数据块，因此，获得的传输率接近主存和I/O总线的极限。
在活跃的处理器上数据传输可以并发执行，尽管在大量DMA操作时会因为争夺存储器访问权使处理器等待。
另外，DMA还增加了设备适配器的复杂性。
数据Cache经常与DMA传输产生不一致，这是说，
图4：
X-内核中消息的实现
使用PIO方式，在从设备输入和向输出数据的过程中CPU一直被占用。
所获得的带宽常常仅有峰值I/O带宽的一小部分，这是由以下的原因导致的。
适配器的控制端口和数据端口可以映射到能缓冲或不能缓冲的存储器区域内。
在不能缓冲的情况下，每个LOAD/STORE指令都导致一个较短的（例如一个机器字）I/O总线传输，使得支持的带宽比较低。
在能缓冲的情况下，I/O总线传输长度为缓冲线（cacheline）长度，取得的带宽有所提高，但是离峰值I/O带宽还比较远。
而且，同样要刷新高速缓冲区，以和适配器端口保持一致。
然而，在某些条件下PIO要比DMA可取一些。
首先，内核中进行的数据运算，如校验和计算，有时候可以和PIO数据流动结合在一起，节省了流向主存储器的一段路经。
其次，编程控制数据从I/O适配器传入主存后，数据还在高速缓冲区中，如果数据在高速缓冲期间得到访问，那么就可以减少主存使用的拥塞。
具有分散-收集能力对基于DMA方式的I/O适配器减小存储器拥塞是非常重要的。
分散机制允许一个输入数据元存储到主存的多个不连续的区域内；收集机制允许从多个不连续的缓冲区中收集一个输出数据元。
分散-收集能力允许DMA方式从不连续的物理页帧中输入和向不连续的物理页帧输出，这样就极大简化了操作系统的物理存储管理，并有助于避免把数据复制到连续的存储区中。
使用PIO的话，用软件就可以简单的实现分散-收集机制。
网卡可能要支持在数据传入主存储器之前对数据包进行多路分派操作（demultiplexing），以过滤和选择数据在存储器中的位置。
在最简单的情况下，网卡允许主机仅仅扫描一下数据包的头部，然后主机确定数据包分派策略以及初始化DMA或PIO方式，使数据传输到主存储器的合适位置。
比较精细的网卡可以通过主机CPU进行编程后，只需要匹配数据包的头部就能自动识别数据包，并使用DMA方式将其存入主存储器的正确位置。
跨域传输
保护机制使得在保护域（地址空间）之间传输数据成为必要。
在最简单的情况下，一个I/O数据流是由运行在传统的单内核系统顶层的一个应用程序进程处理的，在这种情况下，每个数据单元必须跨越用户和内核的边界。
一般的，附加的用户进程，如窗口管理器和多媒体服务器，以及操作系统设计内核化的趋势，都会给I/O数据路径引进额外的域边界。
用软件数据复制来解决数据的跨域边界传输又加剧了存储器瓶颈矛盾。
许多现有的技术都是依赖虚拟存储系统来提供免于复制的跨域数据传输。
虚页重映射技术（remapping）[8，9]把含有数据单元的页帧和发送域之间的映射去掉，再把它们映射到接收域。
虚拟复制技术（写复制）[10]把要传输的页帧共享给发送域和接收域，并一直延续到共享的一方试图向共享单元写入数据时。
共享虚存技术[11]在两个或多个域之间引入了静态共享的缓冲区来避免数据传输。
虚页重映射技术有移动的语义，但没有复制的语义，这就限制了它在某些场合的应用，如发送方以后不再需要访问已传输的数据时。
虚页复制技术有复制的语义，但它只能避免对那些在传输后既没被发送方改写又没被接收方改写的数据的物理复制。
这两种技术都需要仔细的实现才能达到低的延迟。
切换到超级用户模式，取得对VM数据结构的必要锁定，改变每1页的VM映射（可能是在数个层面上），执行TLB/cache保持一致性的操作，然后返回到用户态，这些操作耗费的时间限制了能获得的性能。
我们在DecStation5000/200平台上进行了测试，结果表明，虚页重映射还是不够快，难以维持高速网卡的带宽[12]。
实际上，这两种技术都依赖VM页的大小，这就产生了另一个复杂问题。
当数据单元大小和VM页大小不匹配时，意味着被数据单元重叠的最后一页中部分数据一直得不到利用。
由于数据私有的原因，内核必须把一个新分配的缓冲页的这部分清空（例如填入0），不至于使之带来关系到全局缓冲区管理和跨域数据传输的重大开销。
而当接收的网络数据包报头（在数据包前部）含有必须对用户进程隐藏的敏感数据时，也会产生类似的问题。
存储器页帧只能得到部分利用使得对于单位数量的数据需要更多的页面，导致物理存储开销、页面分配、重映射开销以及对TLB表目的需求增加。
共享的VM技术同时避免了数据传输和相关的开销，然而，在共享的保护域中，使用这种技术可能要在保护和安全上做权衡。
因为共享是静态的（一个特定的页面在同一个域集合中总是可以访问的），需要事先知道一个数据单元的所有接收方。
有一种称为动态页面共享（dynamicpagesharing,fbufs）[12]的混合技术，它把页面重映射和共享式VM结合起来，并且探寻网络拥塞的位置，来克服这两种技术的缺陷。
数据处理
数据处理是指对网络数据包中的每一个数据字进行检查甚至改写的计算过程。
例如加密、压缩、差错检测和校正，以及数据表示的转换等。
数据处理可以用硬件或软件来实现。
硬件如果能支持数据处理就可以减轻CPU负载，而且如果集成得比较恰当的话，还能减小存储器的使用冲突。
对于某些特定的处理，例如视频压缩（解压缩），由于这类任务的计算非常复杂，因此短期内还必须硬件支持处理。
然而，如果所有的数据处理都依赖硬件，可能会严重约束新型的高带宽的应用。
软件对数据的处理一般都是彼此互相独立的，这是因为它们一般都是不同的程序模块（如协议层）的一部分。
从而，每次处理的数据可能是非缓冲数据，即数据是从存储器中装入或存入存储器的。
这些在CPU/存储器数据路径上重复的传输常常占用了处理消息的绝大部分时间，以及带宽。
使用一种称为集成层处理（integratedlayerprocessing,ILP）的技术可以使这样的数据传输达到最少。
ILP是通信协议实现中避免数据处理的访存操作的一种技术。
不同协议中的数据进行处理时一般将它们融合到一个流水线管道中。
每个数据先装入寄存器，在寄存器中由多个数据处理层进行处理，最后再存储，所有这些操作都是在下一个数据字处理前进行的。
在这种方式下，一个合成的数据处理序列处理一个数据字时仅仅从存储器向CPU传输一次，相反的方向也只有一次，而不是对于每个不同的层可能都要传输一次。
文献[13]有1份详细的性能研究，阐明了集成化可以对性能产生重要影响。
另一方面，ILP也有一个主要的局限，即不同保护域中的程序模块要实现数据处理的集成化是非常不容易的。
缓冲区管理
我们把缓冲区编辑和数据处理区别开来，后者是对数据的每一个字进行检测和（或）更改，而前者可以看作是一组对缓冲区的合成操作，即创建、共享、剪切、分割、合并以及回收缓冲区。
引入缓冲区“懒赋值”（lazyevaluation）来实现前述原语的缓冲区管理器可以使缓冲区编辑免于复制操作。
该管理器提供一个抽象数据类型来表示单个邻接缓冲区的提取。
这个抽象缓冲区类型的实例可以实现为一串不要求连续的内存片断。
例如，X-内核用一棵树来表示消息，树的叶子对应缓冲区，最左边的叶子可以带有信息（如消息头）。
图4是X-内核消息的示意图。
由于缓冲区编辑常常用于网络协议的实现中，所以许多操作系统的网络子系统都使用了缓冲区管理器。
这些缓冲区管理器的作用域限制在单个保护域中，且一般都在内核中。
在大多数系统中，跨越域边界的数据单元需要用软件复制到一个连接的缓冲区中。
接口设计
应用程序接口（applicationprogramminginterface,API）定义了数据在应用程序间输入和输出的语义。
由该接口定义的语义是实现效率的重要组成部分。
例如，考虑UNIX的read（）、write（）系统调用。
应用程序可以在其地址空间中选择一个连续的数据缓冲区，可以是任意地址，任意大小或者对齐方式（alignment），并且对缓冲区拥有无限制的访问。
这种低级的数据缓冲区表示使得系统要避免数据复制都是非常困难的。
首先，所有基于VM（虚存管理）技术的跨域数据传输都是在一个VM页的单位下进行的。
如果用户的缓冲区起始和结束的地址不是页对齐的，系统就必须复制第一页和最后一页在缓冲区重叠的部分。
根据用户缓冲区的大小，这样会抵消掉使用免于复制技术所带来的大部分好处。
其次，write（）系统调用原语的语义允许用户进程在调用返回后即可修改（重用）用户缓冲区。
如果这样，系统必须要么把受影响的页复制一份，要么在系统处理完先前数据之前将用户进程阻塞。
第一种方法又引进了复制操作，第二种方法可能会降低用户进程的有效I/O带宽。
一个适宜于高效数据传输方法的API应该使用一种抽象数据类型来表示数据缓冲区。
应用程序通过对它进行操作间接访问缓冲区类型数据，即当应用程序需要缓冲区或者在系统调用中传递（接收）缓冲区实例时，应用程序请求系统创建一个实例，并当关联的缓冲区不再需要时请求系统回收这些实例。
这样系统可以完全控制缓冲区的管理，包括地址分配、对齐、传输方法等等。
后面章节有关于这类API的建议。
端对端设计
这一节对I/O子系统的设计空间进行分析，以使在从数据源到终端设备的整个数据路径上数据相关的开销得到最优化。
目的是使CPU/存储器的数据传输最少。
我们分析了设计空间中的一些典型采样点，针对每种采样点，我们分析其公平性（tradeoff），确定最优数据路径，并选择合适的实现技术以达到最优的数据路径。
在这一节中，我们引用图5这样的结构图来说明数据从源到终端设备的流动过程。
在这些图的下面的结构模型中，使用了一条专用的存储器总线把单级高速缓冲和主存储器连接起来。
总线转换器把主存储器总线连接到单独的I/O总线上，所有的设备都连在I/O总线上。
图5：
不同形式
升级会员 