多核环境下日用操作系统可伸缩性研究.doc

多核环境下日用操作系统可伸缩性研究摘要：随着多核技术的不断普及，多核硬件平台在人们的生活中有着越来越广泛的应用。我们有理由相信，在可以预见的未来，cpu将拥有越来越多的核。在这样的背景下，发挥硬件能力提高系统效率显得至关重要。只有操作系统与硬件配合起来，才能达到这一目标。操作系统可伸缩性反应了操作系统对于多核硬件平台的资源使用效率。在这篇论文中，我们将深入研究日用操作系统的可伸缩性，并且根据研究出来的成果，给出相应的解决方案，从而提高操作系统的可伸缩性。关键词：操作系统，可伸缩性。abstract: with the growing popularity of multi-core technology，multi-core technology is more and more widely used in peoples daily life. in the foreseeable future，pcs cpu will contains more and more cores. its important to make full use of hardwares power to improve operation systems efficiency. only if hardware and software complement each other, can we achieve this purpose. operation system including interface and implementation was developed for single-core hardware. as a result, nowadays operations system cannot use multi-core hardware perfectly and it reduces the performance of the whole system. in this paper, we dive into scalability of daily-use operation system and develop methods to deal with the problem discovered by us.keywords: operation system, scalability引言（前言）随着硬件技术的不断发展，cpu已经从最初的单核向多核方向发展，并且cpu上核数目还有不断增加的趋势8。日常生活中随处可见双核或四核的个人电脑，甚至有些智能手机也采用双核的cpu。现有操作做系统的多核的支持并不完善，没有充分发挥出多核的潜能9,10。比如，四核的电脑打开word文档的速度并不比双核的电脑快2倍，其中有部分计算资源被浪费。随着cpu核数的不断增加，这种浪费的现象越发明显。云计算往往采用多核服务器作为平台的载体,为了提高硬件资源的使用效率，减少资源的闲置，往往会将多个操作系统通过虚拟化技术运行在一台服务器上。在这种情况下，虚拟化平台下操作系统可伸缩性直接影响云计算平台对多核硬件资源的使用效率11。这篇论文中，我们首先比较了dbench等9个应用程序在linux，xen hvm和xen pvm三个平台下的可伸缩性。通过比较我们总结出虚拟化对于操作系统可伸缩性的影响。我们通过oprofile和xenprofile等工具对虚拟化平台下的操作系统做了深入分析，总结出了三个可能导致系统可伸缩性下降的问题。最后我们对于三个问题都给出了解决方案，并且对第一个问题给出了代码实现。1 背景1.1虚拟化1.1.1虚拟化分类虚拟化技术分为半虚拟化（pvm）和硬件辅助虚拟化（hvm）4。早期的虚级化技术没有硬件上的支持，于是就产生了半虚拟化技术，使用模拟指令等方法，达到虚拟化的目的。半虚拟化技术需要通过修改操作系统，以达到操作系统和虚拟化平台交互的目的。随着硬件技术的不断发展，越来越多的cpu提供了对虚拟化的支持。硬件辅助虚拟化则利用了这些硬件特性，使得操作系统可以直接运行在虚拟化平台上，而不需要进行任何修改。在这样的平台下，用户就可以在虚拟机上运行多种操作系统，包括一些不开源的操作系统，如windows，macos等。1.1.2 xenxen6是一款基于gpl授权方式的开源虚拟机监控器。xen起源于英国剑桥大学，之后，xen独立出来成为一个社区驱动的开源软件项目。xen在其1.0和2.0版本中，采用的是半虚拟化技术，从3.0版本开始，xen支持intel和amd的硬件技术，实现硬件辅助虚拟化。xen支持多种硬件平台，包括x86_64、ia_64和powerpc等。2 测试工具2.1 oprofile和xenoprofoprofile是用于linux上的运行数据采样工具12，xenoprof是用于xen虚拟机监控器下的vm运行数据采集工具。xenprof是从oprofile发展而来，能够被用于xen虚拟机监控器和虚拟机上的运行数据采集。xenprof有两个模式：active模式和passive模式。其中active模式不支持硬件辅助虚拟化，所以在我们的测试当中采用了passive模式。oprofile和xenoprof能够采集多种运行时硬件相关数据，其中包括时钟周期，页表缓冲不命中概率和缓冲存储不命中概率等。在我们的测试中，采集了其中6项数据，它们是cpu cycle unhalted, instruction retired, l1 itlb miss and l2 itlb hit,l1 itlb miss and l2 itlb miss, l2 cache miss和data cache misses。2.2 mpstat 和xentracempstat是linux命令行程序，用于反映进程相关的信息，包括user time，kernel time和idle time。我们使用mpstat来测试程序在空闲等待的时间占整个执行时间的百分比。xentrace是用于记录xen上下文切换的信息。当xen切换到idle-vm的时候，我们就认为xen当前处于空闲状态。3 测试环境3.1 硬件环境硬件环境，如表1所示：cpu8 six-core amd 2.4ghz opteron，total 48 coresmemory128gdisk300g scsi表1我们测试的硬件采用的是48核的服务器，cpu的主频为2.4ghz，内存为128g，服务器的硬盘大小为300g。3.2 软件环境我们测试了3个操作系统环境。l 原始linux（linux）：直接在机器上运行linux操作系统l 半虚拟化的xen（pvm）：xen 4.0.0上运行相匹配的linux版本，使用了半虚拟化。l 硬件辅助虚拟化的xen（hvm）：xen 4.0.0上运行相匹配的linux版本，开启了硬件辅助功能。4 测试程序4.1 gmakegmake1 是对并行编译标准的一种实现，我们用这个进行测试主要是因为大多数开发人员都使用它来编译linux内核。对比原始linux，pvm在单核情况下性能下降了12%， 在32核的情况下，性能下降18%。hvm从理论上本应该有较好的表现，但是实际情况却是，单核13%的性能下降，32核36%的性能下降。测试结果如图1。4.2 dbenchdbench是一个文件系统测试软件，它会产生一些i/o请求来操作文件系统。我们使用这个软件对系统进行压力测试。我们的测试结果发现，无论是原始linux还是虚拟化环境下的linux，可伸缩性都很差。在单核的时候，由于虚拟化带来的性能开销，使得pvm和hvm的性能相对于原始linux有较大下降，当核数增加之后，这种性能下降就小了很多。测试结果如图2。图1图24.3 phoenix5phoenix是google mapreduce的另外一种实现，它采用了共享内存的方式，并且利用了多核技术。phoenix会创建很多线程来分别做map和reduce的工作。我们选择其中三个应用对内核的内存管理进行压力测试，它们分别是：histogram，wordcount，linear regression。4.3.1 histogramhistogram是一个更具图片像素rgb值，生成直方图的应用程序。测试的输入数据是2gb。在原始linux里，单核情况下，程序有18%的时间运行在内核态，32核的情况下，程序就有95%的时间运行在内核态。histogram在pvm和hvm平台下性能可伸缩性比原始linux下要差。pvm在单核情况下有24%的性能下降，在32核情况下有382%的性能下降。hvm在单核情况下有21%的性能下降，在32核的情况下有345%的性能下降。测试结果如图3。图34.3.2 wordcountwordcount应用程序读取给如的文本，统计每个词语出现的次数。我们的测试输入文本大小为2gb。在单核的情况下，程序有17%的时间运行在内核态，而在32核的情况下，程序有46%的时间运行在内核态。其在pvm和hvm的可伸缩性相比原始linux更差。测试结果如图4。图44.3.3 linear regression其主要功能是对用户提供的点，进行线性回归操作。用户的数据以文件形式提供。我们的测试文件大小仍然为2gb。在单核环境下，程序有20%的时间在内核态，32核情况下，程序则有96%在内核态。对于hvm和pvm的情况，程序的性能可伸缩性都不好，相对于原始linux而言，pvm最大有741%的性能下降，hvm最大则有46%的性能下降。测试结果如图5。图54.4 specjvm2specjvm-2008 (java virtual machine benchmark)是用来测试jre性能的程序组合。我们选取了其中两个程序作为测试用例，它们是compress和xml-validation。4.4.1 compress这是一个基于lempel-ziv的压缩程序。在单核和32核的情况下，程序花在内核态的时间都小于5%。compress在三个平台下都有较好的性能可伸缩性。pvm的性能减小都少于3%。hvm在单核和32核的情况下分别有14%和25%性能损失。测试结果如图6。4.4.2 xml-validation这个程序用以检测xml文件的正确性。在单核和32核情况下，程序花在内核态的时间都少于10%。xml-validation在linux的可伸缩性在大于24核的情况下有所下降。其在pvm 单核的情况下只有7%的性能损失，在32核情况下，有180%的性能损失。其在hvm在单核和32核情况下，性能损失分别为20%和196%。测试结果如图7。图6图74.5 parsecparsec是一个多线程测试程序集合。我们选择了其中两个作为我们的测试用例，dedup和streamcluster。4.5.1 dedup这个测试程序用于压缩数据流。测试的输入大小大约为2gb。它在单核的情况下，内核态占用时间为38%，在32核的情况下，内核态占用时间为85%。depup在三个平台下的伸缩性都不好。其在pvm 单核的情况下只有19%的性能损失，在32核情况下，有371%的性能损失。其在hvm在单核和32核情况下，性能损失分别为16%和63%。测试结果如图8。图84.5.2 streamcluster这个测试程序主要用于解决在线clustering问题。测试数据大小为256mb。它在pvm和hvm上性能可伸缩性有明显降低。其在pvm 单核的情况下只有22%的性能损失，在32核情况下，有1432%的性能损失。其在hvm在单核和32核情况下，性能损失分别为14%和434%。测试结果如图9。图95 问题分析通过上面的测试，我们分析出三个主要原因，导致性能的显著下降。如表2所示vtimehvm在时间模拟时的冲突idle虚拟机浪费很多时间在空闲等待上cm虚拟cpu间缓存共享问题 表25.1 vtime在xen开启硬件辅助虚拟化的时候，会在时间模拟的时候发生严重的资源竞争。主要的竞争来自于handle_pmt_io函数，它是hvm时间模拟的主要方法。由于每个n核虚拟机都会被分配到n个虚拟cpu，这样导致整个虚拟机监控器内的虚拟cpu核数比真实的cpu核数多。为了能够维护一个全局时间，并且保持其持续更新，每个虚拟cpu都有更新全局时间的义务。这个操作不能同时进行，一个时间只有一个虚拟cpu可以进入这个方法。于是当虚拟cpu数量足够多的时候，大量的虚拟cpu就会拥塞在这里，浪费大量的cpu计算时间在无意义的等待上。5.2 idle在原始的linux里面，当一个进程空闲时，linux会切换到一个idle的进程，当进程需要被唤醒时，linux在切换回来3。但是在pvm模式下，当一个进程空闲时，linux会调用一个hypercall告诉xen调度另一个虚拟机的进程，如果没有这样的进程，xen就会调度到idle vm，这个idle虚拟机和原始linux下的idle进程类似13。虚拟机级别的调度需要消耗更长时间，因此造成了性能的降低。并且，如果存在资源竞争的情况，进程切换时间加长，会导致等待队列时间延长，最终使得整个程序的运行效率下降。5.3 cmxen在调度的过程中会查询和修改一个bitmap，这个bitmap被每个虚拟cpu共享，这个时候任何修改，都会导致其他虚拟cpu的对应cache被标记成无效。这样其他虚拟cpu需要查询内存来得到更新的内容，耗费更多的时间。6 解决方案6.1方案我们对于vtime和idle问题提出了解决方案。6.1.1 vtime在xen中，其实没有必要每个虚拟cpu都去更新全局时间，当一个虚拟cpu发现两外一个虚拟cpu在更新全局时间是，那么前者就可以跳过时间更新，继续自己的任务。通过这样的修改，hvm的时间模拟冲突就得到了解决。6.1.2 idle对于idle问题，我们提出了两个个能的解决方案。第一，创建出一个低优先级进程，当没有其他进程或线程在运行时，运行这个新创建出的进程。这样可以避免系统切换进idle进程，从而避免了重量级的虚拟机上下文切换。第二，防止xen截获hlt指令，通过这个方法，xen就不可获知虚拟机进入idle状态，同样避免了重量级的虚拟机上下文切换6.2 代码我们对vtime的解决方案给出了代码实现。代码如下所示： 原始xen的代码实现是循环获取锁得过程，在我们的修改版本中，则改为使用trylock去尝试获取锁，如果这个所正在被别人占用，那么这个虚拟cpu就知道有其他的虚拟cpu在修改全局时间，那么久放弃这次修改。6.3 性能测试对于vtime问题实现的优化，我们做了相应测试，并且和原始的xen进行了对比。测试结果如表3所示：app8cores32coresxenxen（修改）xenxen（修改）gmake57.47%0.70%32.56%0.97%dbench31.45%0.88%9.93%0.37%histogram43.27%1.64%36.44%0.63%wordcount30.93%1.00%55.24%1.75%linear regression7.13%0.82%19.49%0.01%compress26.55%0.47%4.06%0.06%xml-validation22.46%0.54%13.14%0.36%dedup70.96%13.28%71.69%8.73%streamcluster43.27%9.26%36.44%36.44%表3我们分别在8核和32核的情况下，对两个系统进行了测试。表格中的数字表示，程序花费在时间模拟上的时间占总运行时间的百分比。对于大多数情况，修改过的xen比原始的xen，花费更少的时间在时间模拟上，并且性能提升显著。7 总结日常操作系统可伸缩性直接影响了程序在多核环境下的执行效率。在这篇论文中，我们通过对9个程序在3个平台下执行情况进行分析，找到虚拟化系统xen存在的可伸缩性问题，并且对其中两个问题提出了解决方案，对vtime问题给出了代码实现。通过我们的解决方案，虚拟化系统xen性能得到了显著提高。后记（致谢）：感谢实验室宋翔博士给我的巨大帮助。感谢我的导师陈海波老师以及臧斌宇教授在整个项目过程中给我的指导。感谢望道项目给我这个机会来完成这个项目。参考文献1 gnu make. /software/make.2 specjvm 2008. /jvm2008.3 j. aas. understanding the linux cpu scheduler. /linux/linux_cpu_scheduler.pdf.4 k. adams and o. agesen. a comparison of software and hardware techniques for x86 virtualization. in proc. asplos, pages 213, 2006.5 apache wiki. applications and organizations using hadoop. /hadoop/poweredby.6 p. barham, b. dragovic, k. fraser, s. hand, t. harris, a. ho, r. neugebauer, i. pratt, and a. wareld. xen and the art of virtualization. in proc. sosp, pages 164177, 2003.7 r. bhargava, b. serebrin, f. spadini, and s. manne. accelerating two-dimensional page walks for virtualized systems. in proc. asplos, pages 2635, 2008.8 s. borkar. thousand core chips: a technology perspective. in pr