GPU虚拟化环境下的数据通信策略范文

本站小编为你精心准备了GPU虚拟化环境下的数据通信策略参考范文，愿这些范文能点燃您思维的火花，激发您的写作灵感。欢迎深入阅读并收藏。

1引言

虚拟化技术对物理资源进行逻辑抽象和统一表示，降低了资源管理的复杂度，提高了物理资源的利用率和运营效率，从而有效地降低了运营成本[1]。同时，现代gpu的计算能力比同时代CPU的计算能力胜出几个数量级，因而商业界、学术界纷纷致力于GPU虚拟化技术的开发[2]。然而在目前的虚拟化环境下并没有一个通用且高效率的RPC系统，传统的如XMLRPC[3]、CORBA[4]、ICE[5]等应用则只针对开放的网络或分布式环境，当把它们移植到虚拟化环境中则会在系统吞吐率、延迟以及CPU占用方面出现很大的劣势，基本无法应用于实际项目。2006年，Nvidia公司统一架构CUDA[6]（ComputeUnifiedDeviceArchitecture)）的诞生，引发了GPU通用计算领域（GPGPU，GeneralPurposecomputingonGraphicsProcessingUnits）的迅猛发展，大大简化了GPU的编程环境。当采用多GPU并行处理大规模的数据时，数据通信的选择问题，已经成为在虚拟化环境下进行CUDA应用开发不可越过的难题。为了提高在虚拟化环境下多GPU协同计算的性能，本文首先在系统层分析由于虚拟化带来性能影响的主要因素，通过对比同一虚拟化平台下的不同数据通信策略得出特定虚拟化平台的最佳通信方式。在应用层方面，通过研究多GPU卡的不同的数据传输机制，得到影响多GPU协同运算效率的主要因素。

2虚拟机域间通信策略

2.1基于Xen的虚拟机通信方式Xen平台下虚拟机域间通信优化的解决方案主要有三种，分别是XenSocket[7]、XWAY[8]和XenLoop[9]。XenSocket是在Xen中基于socket的解决方案，旨在提高虚拟机域间通信的吞吐率。XenSocket的API采用标准的socketAPI接口，在socket的接口下，它使用Xen提供的共享内存来实现虚拟机之间高速的数据传输[10]。XWAY使得在同一物理机不同虚拟机之间运行的程序可以通过标准的socketAPI来进行通信，不仅实现了域间通信的高带宽、低延迟，同时也充分地保证了对二进制兼容性，使任何基于socketAPI的网络程序都可以直接享用XWAY带来的高速域间通信的体验[11]。XenLoop是一个Xen平台下另一虚拟机域间通信方案，该方案是一个完全透明的、高性能的虚拟机域间的网络环回通道。Xenloop可使同一物理机不同虚拟机之间可以直接进行数据通信而不需要第三方软件的参与，同时可以不牺牲应用层的透明性，应用程序不用作任何修改便可以无缝地运行。XenLoop还实现了在Xen虚拟化平台下虚拟机域间的高速通信[12]。

2.2VMwareVMware开发了一套相应的虚拟机通信接口VMCI（VirtualMachineCommunicationInterface）。VMCI[13]是一个作用在应用层的方案，提供在VMware系列虚拟机平台下的快速、高效的域间通信通道，使得客户端虚拟机与客户端虚拟机、客户端虚拟机与物理机之间能够实现高速的通信。VMCI实现两类接口，一类是数据报API，一类是共享内存API。VMCI属于VMware的商业产品，内部实现细节目前并未披露[14]。由于目前并不存在适用于虚拟机中的显卡驱动，本文通过在ESXi中某一虚拟机中使用PCIpass-through（也即VMware的设备直通）技术，使得该虚拟机获得物理机中GPU的访问权。

3GPU内部数据传输

随着2011年CUDA4.0由NVIDIA作为一个全新版本后，其功能特性大幅度增加，主要涉及应用程序移植的简化、多GPU编程的加速、开发工具的增加和改进三个方面。在多GPU通信方面，在CUDA4.0之前，多个GPU在同一节点内相互访问，需要首先将GPU中的数据传输给CPU，再通过CPU的中转完成GPU间的数据交互。而在CUDA4.0之后，NVDIA实现了不同GPU可以直接进行传输，且传输可以一次完成。另外通过NVIDIA的GPUDirect2.0[15]技术使一台服务器内多个GPU之间直接点对点通信，不仅绕开了主机端的参与，同时让多GPU编程更加轻松且传输效率也大大增强。

3.1统一虚拟地址空间统一虚拟地址空间（UnifiedVirtualAddressing，UVA）模型为主机与系统内所有的设备提供了单一地址空间[16]。这一模型将CUDA中包括CPU以及GPU在内的所有指令执行过程放入同一个地址空间。这之前每个GPU和CPU都使用它们自己的虚拟地址空间，从而导致许多额外的开销，UVA的引入为GPU之间的点对点数据传输提供了逻辑支持，使得开发者体验到更方便的内存管理。如图1所示为多存储器模型和统一地址空间模型的结构图。

3.2CPU中转传输在CUDA3.2及其之前的版本中，多GPU的设备存储器和主机端的内存被视为独立的存储器块，各自拥有独立的地址空间。GPU之间如果需要进行通信的话则必须首先通过将数据从GPU端拷贝到主机端内存，再由主机端内存传输至目标GPU中的显存。

3.3GPU点对点传输在CUDA4.0之前的多GPU程序开发中，每个GPU被看成是独立的核心。而在CUDA4.0中，每颗核心及其具备的各种存储资源被当做一个整体的工作网络中的结点，各个节点之间的通信和同步是对等的（形成了一个共享式内存的SMP网络）。host端的内存资源和GPU上的设备存储资源被当做一块统一的存储器池，存储器地址统一编码，多GPU之间可以通过PCI-E总线直接进行通信，而不再需要通过内存进行中转。

3.4结果预测虽然GPU之间的直接数据传输直接绕开了主机端内存的中转，但由于基于Fermi架构的显卡没有对GPU之间的数据传输提供直接的硬件支持，在数据传输时仍然需要将数据经由总线，其实质是少了一次经由PCI-E总线的数据传输的时间。因此预测随着计算规模的增大，G_G（GPU点对点传输）相对与G_H（CPU中转传输）的传输方式的计算时间差应该有所提升，提升的速度应该基本呈线性增长的趋势，其时间差应与数据的规模成正比，与总线带宽成反比。以矩阵复合运算A*B+C*D为例，在一定的数据规模下，设GPU的矩阵计算时间为0T，将四个矩阵拷贝至4个GPU的总时间为1T，将计算结果拷贝回CPU端的时间为2T，单GPU对中间结果的单向数据传输时间为T，则G_G的理论计算时间为012T+T+T+3T，G_H的理论计算时间为012T+T+T+8T，时间差为5T。这是因为，G_H采用的是4块GPU全部将数据传输至CPU，再从CPU中转至其中的一块GPU（如GPU0），总计算时间为012T+T+T+8T。而G_G则不然，这是因为GPU0在计算加法运算之前需要进行(A/2)*B，而计算结果并不需要进行传输，直接驻留在GPU0中，因此中间结果不仅绕开了主机端的参与，同时也省略了(A/2)*B的两次数据传输。在本文中，我们设计的矩阵中的数据类型是单精度的浮点数float，如果在GPU中分配和C/2和D同样大小的数据，采用CUDA4.0SDK中的simpleP2P样例来测试GPU之间的数据带宽（实际上就是PCI-E的实际带宽），则数据总量与PCI-E总线实际带宽的商1T应该与T在理论上相等。

4实验结果与性能分析

4.1实验环境实验所用平台的参数如表1所示。

4.2域间通信方式选择本节从通信策略支持的通信方向、对标准协议（TCP、UDP）的支持、延迟以及对用户的透明性等角度来分析在基于Xen的虚拟化环境下不同的通信策略对CUDA应用的性能影响。尽管XenSocket和XWAY能够在基于Xen的虚拟化平台下提供高效率的域间通信，但是这些通信机制都存在某方面的不足。从客户端和服务的通信方向、对标准协议的支持、TCP提交的延迟（单位为TCP报文的往返时间）以及对用户的透明性对三种通信方式进行比较。从表2可见，XenSocket的功能比较简单，只支持单向通信，而传统的socket通信和RPC都是双向的，这就使得其无法充分利用RPC机制的透明性。由于它的立足点在于增加虚拟机域间的传输带宽，对标准的TCP和UDP协议的支持也不完善。同时，XenSocket虽然在数据量少（一般在16KB以下）时的单向吞吐量是XenLoop的两倍多，但由于其采用固定的缓冲区大小使得其无法满足更大数据量的传输需求。XWAY通过拦截socket底层的TCP调用来为面向TCP连接的应用提供透明的虚拟机域间数据传输。但它同样存在诸多不足，如它需要对网络协议栈进行修改、不支持UDP协议、不支持套接字的在线迁移，同时，XWAY也未对共享内存的安全性进行考虑。XenLoop方案对用户和系统都是完全透明的，提供了高性能的虚拟机域间网络回环通道。它支持TCP和UDP两种协议，同时利用Xen提供的授权表机制在数据通道的两端建立共享缓冲，实现全双工通信，并实现了对共享区的同步机制和安全机制。本文将在Xen平台下使用XenLoop加速虚拟间的通信。由于VMware的闭源性，在学术界很少有基于VMware虚拟化平台的通信解决方案。但VMware公司开发了一套相应的虚拟机通信接口VMCI，它是一个工作在应用层的解决方案，提供在VMware系列虚拟机平台（Workstation、ESXi等）下的快速、高效的域间通信通道，使得客户虚拟机与客户虚拟机、客户虚拟机与宿主虚拟机之间能够高效的通信。本文在VMware虚拟化系列平台下均采用VMCI进行域间加速。

4.3GPU内部数据传输由于受计算机计算能力和内存容量方面的限制，很多并行程序对数据进行拆分并通过数据交换来实现原来程序的功能。在本文中我们通过矩阵复合运算A*B+C*D来完成整个实验数据的验证。A*B+C*D，其中A*B分别由device0和device1完成，C*D分别由device2和device3来完成，乘法完成后通过两种方式分别将计算结果传递给device0，由于矩阵加法的复杂度较低，所以在最后所有的加法运算全部交由一块GPU来完成。本节给出了4个GPU在两种不同数据传输方式下的性能比较。表3所示为G_H和G_G随着矩阵规模逐渐增大后的统计特征对比，统计特征包括kernel函数的迭代次数、实验方差。在表3中，kernel执行次数即在主函数中执行kernel的次数，也即迭代次数。方差则表示若干次迭代次数的时间的统计方差，单位为秒的平方（2s）。图2所示为通过两种数据传输方式的时间对比，横轴是矩阵的阶数，纵轴是执行的时间。为了使最后统计的数据统一，图中的执行时间均为将迭代次数换算至100次后的时间，同时，矩阵复合运算的执行时间是输入数据初始化完毕后开始计时，数据从GPU端拷回主机端结束计时，因而未将由于虚拟化带来的性能开销（即访问延迟）考虑在内。从图4中可以看出，随着矩阵规模的增加，G_H相对于G_G的执行时间差也越来越大，变化速度基本呈线性增长的态势。由3.4节的理论分析知，这是由于G_G相对于G_H少了5T，其中T为单GPU对中间结果的单向数据传输时间。G_G相对于G_H不仅少了中间结果在总线上一次数据传输，同时GPU0在计算加法运算之前进行(A/2)*B的计算结果并不需要进行传输，直接驻留在GPU0中，因此中间结果不仅绕开了主机端的参与，同时也省略了(A/2)*B的两次数据传输。表4所示为实际测量的时间差与理论计算值对比情况。其中，理论值为单个GPU传输(C/2)*D的结果乘以系数5后的结果；测量值为在主机端生成同理论值相同数据量的数据将其传输至GPU中所花费的时间乘以系数5后的结果；实际值即如图4中的G_H和G_G的时间差；实际-理论差即为理论计算值与G_H和G_G时间差的差值；同理，测量实际差为“等价”的测量值与实际的时间差的差值。由表4不难看出，理论值、测量值与实际值基本相符，同时随着矩阵的阶数不断增加，实际理论差有着小幅度的增加，但都在允许的测量误差范围之内。测量实际差基本上为0，这是由于测量的数据和实际传输的数据在格式和规模上完全一致，只是简化了数据传输的过程。图4和表4验证了3.4节结果预测的正确性。

5结束语

本文对现有的虚拟机域间通信的优化方案分进行详细介绍，通过对比几种优化方案，在Xen平台下采用XenLoop域间通信方式为GPU虚拟化环境下的最优通信方式，在VMware虚拟化平台下使用VMCI的通讯方式。在单节点多GPU内部通信方面，设计了两种方式（G_G和G_H）完成GPU间的数据传输，以矩阵复合运算为应用场景设计了实验，结果验证了预测结果的正确性。将来的工作将是对于在集群环境下，GPU虚拟化的数据传输问题的分析。

作者：张玉洁 吕相文 张云洲 单位：南京航空航天大学计算机科学与技术学院