基于虚拟化环境的多GPU并行通用计算平台研究

徐 恒 吴俊敏 杨志刚 尹 燕

1(中国科学技术大学软件学院 安徽 合肥 230027) 2(中国科学技术大学计算机科学与技术学院 安徽 合肥 230027) 3(中国科学技术大学苏州研究院 江苏 苏州 215123)

基于虚拟化环境的多GPU并行通用计算平台研究

徐 恒1,3吴俊敏2,3杨志刚2尹 燕2

1(中国科学技术大学软件学院 安徽 合肥 230027)2(中国科学技术大学计算机科学与技术学院 安徽 合肥 230027)3(中国科学技术大学苏州研究院 江苏 苏州 215123)

针对分布式多节点多GPU的系统环境，实现一种基于CUDA框架的多GPU通用计算虚拟化平台。应用程序可以如同使用本地GPU一样方便地使用多个远程GPU，原来的CUDA应用程序可以不经过修改或者只进行少量的修改就可以运行在该虚拟化GPU平台上，从而实现单机多GPU和多机多GPU在编程模式上的统一，并通过一个基于高斯混合模型的数据聚类程序来进行实验验证。实验结果表明，在不影响程序正确性的前提下，相对于原来使用CPU的程序，使用两个远程GPU可以获得十倍左右的加速比。

虚拟化 GPU 多机多GPU 分布式

0 引 言

近年来， GPU的通用计算功能得到了迅速发展。随着GPU的性能提高以及GPU自身的结构特性，使得GPU在大规模并行计算中起着越来越重要的作用，对于GPU的通用计算功能的研究也成为了热点。在通用计算领域，以CUDA为代表的并行计算架构将GPU引入到科学计算。但是CUDA规范只能直接访问本地的GPU，并没有直接提供对远程GPU的访问接口，为了能够使用网络中的远程GPU，开发人员需要用到MPI与CUDA结合等方法，这增加了程序的复杂性并且给开发人员带来额外的工作量。

为了能够更加方便地使用多GPU系统的计算资源，本文以开源项目gVirtuS为基础，实现了一种基于CUDA框架的、支持多GPU通用计算的虚拟化方案，可以将分布式环境中多个节点的GPU资源的统一抽象到一个GPU池中。程序可以用本地GPU的方式使用任意位置、任意数量的GPU的资源，原有的CUDA程序可以不修改源代码只要在编译过程中进行简单的配置就可以在该虚拟化平台上运行，即使没有GPU设备或者只有不支持CUDA的GPU设备也能够十分方便地使用分布式环境中的非本地GPU资源进行通用计算。

1 GPU虚拟化背景

虚拟化技术在现代计算机系统中有非常广泛的应用，是对传统计算资源的使用方式的一种突破。在虚拟化技术中，由于I/O设备的复杂性、多样性与封闭性，针对I/O设备的虚拟化一直是瓶颈。GPU属于I/O设备中的特殊部分，其功能主要有图形计算与通用计算两部分，近年来随着神经网络的兴起，GPU的通用计算功能越来越受重视，针对GPU通用计算的虚拟化一直是学术界研究的热点。目前GPU虚拟化技术主要有三类：1) 设备独占;2) 设备模拟；3) 应用层接口虚拟化(即API重定向)。此外还有硬件虚拟化，但是运用较少。

由于CUDA的广泛应用，对GPU通用计算的虚拟化主要是基于CUDA的解决方案，例如rCUDA[1]、vCUDA[2-3]、 gVirtuS[4]、Gvim[5]等。其中vCUDA是针对在虚拟机环境中运行CUDA程序提出的解决方案，“采用在用户层拦截和重定向CUDA API的方法，在虚拟机中建立物理GPU的逻辑映像”[3]。vCUDA出现时间较早，对于CUDA 4.0之后的版本不再支持。Gvim是基于Xen系统的，实现了基于前后端的CUDA虚拟化系统，但是并没有实现CUDA全部功能的虚拟化。rCUDA是目前比较成熟的GPU虚拟化解决方案，支持最新的CUDA 7.5，支持cuDNN，其不再侧重于针对虚拟机的GPU虚拟化，而是所有不包括NVIDIA GPU的节点都可以使用rCUDA来使用GPU进行通用计算。rCUDA可以免费获得，但是不开源，其具体实现细节与原理都未公开。gVirtuS是基于前后端模式实现的GPU通用计算虚拟化方案，其前端提供了一个封装了CUDA接口的伪库。在前端的所有的对CUDA API的调用都会被这个伪库拦截并转发到后端进行处理，而后端则运行在具有处理能力的宿主机上，负责处理前端发来的请求。这种虚拟化方案被称为API重定向( API remoting)，其访问远程GPU时采用的前后端通信方式是TCP/IP，只能使用一台远程主机中的GPU资源。

以上方案无论是针对虚拟机的vCUDA还是针对远程物理机的rCUDA，其设计都包含有高效性、普适性、透明性三个原则。高效性是要求虚拟化方案不能带来额外的开销；普适性是指虚拟化方案不能只针对特定虚拟化平台有效，在本文中的虚拟化方案除了虚拟化平台外还包括了没有GPU的物理平台；透明性是指虚拟化的方案对于CUDA应用保证兼容性，不要求修改CUDA程序源码或者重新编译，或者只需要做很少的修改就可以在虚拟化平台上运行，在透明性良好的虚拟化方案中，原有的单机多GPU程序可以直接在多机多GPU的分布式环境中运行，从而实现了不同环境中的编程模式的统一，这也是本文研究的重点。

2 单GPU虚拟化

本节讨论如何通过API重定向虚拟化方案来访问单个的远程GPU进行通用计算的问题，以此为基础，下一节再来讨论如何使用分布式环境中的多个GPU的问题。在本文中的“虚拟节点”这个术语有两层含义：一是指传统意义上的虚拟机节点；二是指没有配备可以运行CUDA的GPU的物理机节点。为了不引起歧义，本文使用“前端节点”这个术语来指代以上两层含义。相应的，使用“后端节点”这个术语来指代宿主机。

2.1 API重定向虚拟化方案

API重定向技术虚拟化方案[6]，是一种应用层接口虚拟化，是对GPU相关的应用程序编程接口在应用层进行拦截，然后使用重定向方式实现相应的功能，将完成的结果返回给对应的应用程序。

这种方案是针对CUDA运行时API(Runtime API)进行虚拟化，为前端提供了一个运行时伪库，该伪库重写了CUDA的运行时API，将其实现为对后端的远程调用。前端编写的CUDA程序对CUDA API的调用被伪库动态拦截，伪库将CUDA API的参数与名称发送到前端通信部分，再由前端通信部分通过网络发送给后端，后端接受相应参数后调用真正的CUDA程序进行计算，然后将运行结果返回给前端。结构如图1所示。

图1 API重定向虚拟化方案结构

这种方案解耦了上层软件与底层硬件之间的强耦合关系，不仅可以应用在虚拟机中，也可以为没有配备GPU资源或者配备了缺少支持CUDA的GPU资源的计算机提供一种使用远程节点上的GPU的方法。这两种方案的区别在于前端与后端的通信方式的不同：在虚拟机中可以利用虚拟机与宿主机之间的高速通信方式，而在访问远程节点上的GPU时只能使用网络通信。

这种方案不依赖于特定的虚拟化平台，前端节点可以是一个Xen、KVM、Vmware或者其他任何一台虚拟机，甚至可以是一台真正的物理机，只要与后端节点有网络连通，都可以使用这种方案来搭建虚拟化平台。搭建的方式也十分简单，只需要在前端节点中安装好运行时伪库(一般与原装库同名)，然后在配置文件中将后端节点的IP地址正确的写入即可。原本的代码不需要做任何的修改，只要在编译时将伪库链接到可执行文件中，源程序不需要做任何的修改就可以运行在虚拟化平台上。应用程序可以如同使用本地GPU一样方便地使用远程GPU，虚拟化平台的复杂的执行流程对程序员完全透明。

一个典型的CDUA API的执行过程如图2所示，不同的API执行步骤会有差异，但基本流程都是如图2所示。图中虚框部分是虚拟化平台所做的处理，一般包括前端部分与后端部分，分别位于不同的节点上。前端节点与后端节点之间的交互包括数据传输与函数调用，前端的所有参数都会被伪库拦截转发给后端，后端节点接收了参数之后会启动核函数进行运算，最后将结果返回给前端节点。每一个CUDA API在执行时都会涉及上述步骤，执行期间会有大量数据传输，涉及不同组件、不同节点，数据传输对应用程序的性能会产生重大影响，是虚拟化方案设计时要解决的重要问题。

图2 CUDA函数在虚拟化平台上的执行流程

2.2 程序在虚拟化平台上的执行过程

图2显示了CUDA函数在虚拟化平台上的执行流程，与直接在本地上运行时不同，在虚拟化平台上程序执行时被分解为了前端与后端两个部分，这使得其执行步骤更加复杂。在没有虚拟化的环境下，一次GPU运算的过程可以简单地分成三个步骤：

1) 将数据从主机内存拷贝到GPU显存。

2) 在GPU上启动核函数，开始计算。

3) 将结果由GPU显存拷贝回主机内存。

在虚拟化方案中，由于前端节点与后端节点往往不是在一台机器上，除了必要的数据外，前后端之间还需要传输大量的参数信息与控制信息，这些都是由虚拟化平台来处理。

图3是一个求后端节点的GPU数目的简单程序，原程序不需要做任何的修改就可以移植到虚拟化平台上，并得到正确的结果，只是其执行的流程更加复杂：

1) 根据配置文件中提供的IP地址，前端传输相关的参数到后端，完成GPU资源的初始化，并传回句柄的相关信息。如果无法完成初始化，则报错。

2) 在后端GPU上注册代码段(FatBinary)，程序在本地上运行时，这一步骤会隐式的调用一个CUDA未公开的API _cudaRegisterFatBinary()来完成如内存偏移、空间大小、GPU设备编号等相关初始化工作。该API是在程序的所有代码之前被调用。在虚拟化环境下，这一过程由平台来完成，同样对前端编程人员透明。

3) 将计算数据与参数从前端内存传输到后端节点的内存，这往往是通往网络传输的。

4) 根据前端传输过来的参数以及控制信息，后端节点调用GPU进行计算。

5) 后端节点将计算结果拷贝回主存，释放资源，并且完成相关的清理工作，在GPU程序的所有代码执行结束之后，还需要调用另外一个未公开的CUDA API： _cudaUnregisterFatBinary()来注销相关的信息。

6) 虚拟化平台的后端将计算结果传回给前端节点。

图3 一个简单程序在虚拟化平台上的执行

上述一个简单的求后端节点的GPU数目的例子中就涉及到了两个未公开的CUDA API。由于CUDA的封闭性，还有其余未曾公开的API，这些不曾出现在官方文档中的API是实现虚拟化方案的过程中需要处理的棘手问题。为了保证虚拟化平台的透明性，这些API的功能都是由虚拟化平台来实现。

以上是对虚拟化平台的程序执行步骤的简单介绍。一个简单的程序在虚拟化平台上的运行过程往往就涉及到了复杂的参数传递与控制信息传递，这些数据都要通过网络来传输，新增加的软件栈也会导致性能降低。另外，在一些程序中，需要处理大量的数据，这些数据在前端/后端之间传输所带来的延时往往会比GPU处理这些数据的时间高的多，这也常常成为程序的性能瓶颈。

2.3 改变通信方式提高效率

在2.1小节论述了论述了虚拟化平台的普适性、透明性原则，本小节讨论虚拟化过程的效率性。本文采用的API重定向技术是在应用层完成了对GPU的虚拟化，这是一种在CUDA的封闭、不了解其内部细节情况下提出的虚拟化方案[7]，也是目前研究GPU通用计算虚拟化的主流方案。API重定向方案可以解决CUDA封闭性问题，然而由于需要拦截/转发、前端处理、后端处理等步骤来实现平台的功能并对上层程序员透明，因此带来了额外传输开销与控制开销。新增加的软件栈也会降低系统的性能[8]，尤其是在采用网络传输来实现前端/后端的参数传递与数据传输时。相对于主机内存到GPU显存的高速传输，网络传输的延时往往会高好几个数量级，这部分开销也成了整体性能的瓶颈，如何通过提高通信的性能也是本文要讨论的重点。

前端节点与后端节点的通信方式有不同的选择，当需要访问远程的GPU时，采用的是基于socket的传输方式进行通信，这带来两个问题，一是前端/后端之间的数据传输延时比较大；二是一个前端节点只能与一个后端节点进行通信，无法同时对多个GPU进行抽象和映射。本小节将其通信方式改为ZeroMQ来解决第一个问题，第二个问题在第4节讨论。由第2.1小节可以知道，通信部分为CUDA编程提供了有效的底层通信接口，前端通信部分与后端通信部分的关联十分紧密，而通信部分与系统的其余部分的耦合性并不高，在深入研究之后为系统增加了一种新的高效通信方式：ZeroMQ通信方式。

ZeroMQ是一种基于消息队列的多线程网络库，其对套接字类型的底层细节进行抽象，提供跨越多种传输协议的套接字。相对于Socket来说ZeroMQ是一个更为高效的传输层协议。ZeroMQ设计之初就是为了高性能的消息发送而服务的，所以其设计追求简洁高效。ZeroMQ是面向“消息”的而非字节流，发送消息采用异步模式。

实验表明，采用ZeroMQ通信方式的程序能够比原来的Socket方式整体性能更高。实验中的后端节点配置Inter(R) Core(TM) i5-4590CPU(3.3 GHz)处理器，4 GB内存和100 GB硬盘，GeForce GTX750 Ti GPU，Ubuntu 14.04 64位操作系统，CUDA版本为7.5。前端节点是一台物理机，配置Celeron(R) Dual-Core CPU T3000(1.8 GHz)处理器，3 GB内存和30 GB硬盘，没有NVIDIA显卡，也没有安装CUDA程序，Ubuntu 14.04 64位操作系统。前后端之间通过百兆以太网交换机互联。由于网络环境会影响到实验结果，所以每组数据都是测试多次取平均值，实验运行的程序都是CUDA SDK自带的程序。计算性能实验在三类平台上进行对比，即本地GPU计算平台、基于Socket通信方式的虚拟化计算平台以及基于ZeroMQ通信方式的虚拟化计算平台。

图4显示的是向量加法的性能实验结果，其中横坐标表示的是向量长度，纵坐标是运行时间。除了运行时间不同之外，运行结果与本地机上的运行结果没有差别，说明虚拟化平台不会对程序的正确性有影响。实验结果表明使用ZeroMQ通信方式可以提高系统的整体性能，在这个程序中，可以获得20%～35%的性能加速。然而与本地运行的程序相比，随着数据量的加大，不论是哪一种通信方式的虚拟化方案所带来的性能损失也越来越大。这是因为随着向量规模的增加需要传输的数据量越多，就有更多的数据和参数需要在前端/后端之间传递，自然会有更大的传输开销与控制开销。而数据在GPU上计算所增加的时间并不多，这是因为GPU特别适合处理向量加法这种可以并行的程序，因此数据规模的加大并不会使GPU的运算时间大幅提高。

图4 不同平台上向量加法程序的执行结果

在GPU上运行的往往不会是向量加法这么方便地进行并行处理的程序，比如复杂一些的CUDA程序：矩阵乘法，这是一个计算密集型程序，其需要传输的数据并不太多，而GPU的运算却相对复杂，结果如图5所示。

图5 不同平台上矩阵乘法程序的执行结果

图5中横坐标是参加运算的矩阵的阶数，纵坐标是程序的运行时间。实验结果表明，当矩阵规模越大时，虚拟化方案的性能反而越接近物理机，当矩阵的规模为960×960时，程序在基于ZeroMQ的虚拟化平台上的运行时间是在物理机器上运行时间的1.12倍，此时达到临界点，规模更大的矩阵运算不会使程序的性能更接近本地机，因为传输开销与控制开销以及额外的软件栈等是虚拟化无法避免的性能损失。以上实验结果表明虚拟化平台在处理计算密集型的程序时损失的性能会相对较少。图5中还显示了另外一个问题：基于ZeroMQ方式与基于Socket方式的虚拟化平台之间的性能差距不再十分明显。这同样是由于程序的计算比较复杂，需要GPU运算的时间大大超过了数据在网络中传输的时间，通过改变通信方式获得的性能提升不再明显，那么为什么依旧选择ZeroMQ呢？下一节的多GPU虚拟化来讨论这个问题。

3 多GPU虚拟化

多GPU平台主要有两种构架，如图6所示。一种是单机多GPU，另一种是多机多GPU，即GPU集群[9]。在编程方式上，在单机多GPU的环境下CUDA提供了直接的编程接口，而对于多机多GPU的结构CUDA没有相关的编程接口，需要借助其他工具，如基于MPI与CUDA相结合的方式，要求编程人员显式地采用分布式MPI编程。目前的多GPU的处理方案中，一般都是将两种情况区别对待，运行在单机多GPU上的CUDA代码需要进行很大的修改才能移植到多机多GPU的环境上，如何实现二者在编程模式上的统一是本文讨论的重点。

图6 单机多GPU与多机多GPU

在第2节中提到的基于Socket方式来实现的单GPU虚拟化方案中，由于Socket只支持一对一的通信，一个前端节点只能访问一个远程GPU，无法同时调用集群环境中的多个GPU来加速应用程序。因此，在基于ZeroMQ通信方式的虚拟化方案除了能够提高效率外，还实现了另外的功能：ZeroMQ支持一对多的通信，从而能够同时使用多个远程GPU，实现多GPU的虚拟化方案，如图7所示。一个前端节点可以绑定多个后端节点的IP地址，从而能够通过ZeroMQ同时调用多个后端节点上的GPU资源。GPU集群中存在多个节点，每个节点配备了不同的GPU资源，节点之间通过网络互连。在虚拟化的过程中，通过IP地址来标识不同节点的GPU，将其映射到一个统一的GPU池中，并且顺序编号为GPU0，GPU1，…，GPUn等。所有分布式环境下需要解决的容错性，冗余性等问题都在虚拟化过程中解决。对于前端节点来说，其能够使用的GPU的最大数目就是这个GPU池中的数目。在逻辑上，前端应用调用这个GPU池中的GPU的方式和使用本地GPU的方式完全相同，从而将多机多GPU卡的物理环境抽象成了单机多GPU卡的逻辑环境，使得单机多卡的程序可以不用修改或者只做很少的修改就可以运行在多机多卡的环境下，实现了两个环境编程模式的统一。

图7 多GPU虚拟化平台的物理结构与逻辑结构

如图7所示，集群中的所有GPU资源都由虚拟化平台来管理，前端需要使用GPU资源时，只需要在配置文件中准确描述后端节点的IP地址和需要的GPU数目，就可以将相应节点上的GPU映射到本地。应用程序可以像访问本地GPU一样调用这些映射来的GPU进行加速。此外当有些程序需要的GPU资源超过了单个节点的能力时，这也是一种很好的解决方案。程序开发过程中，开发人员只需要专注于CUDA编程， GPU资源的分布、数据的传输、冗余与错误处理等都交给虚拟化平台来处理。这种方式的灵活性极好，对GPU资源的分配只需要修改配置文件即可。

多GPU虚拟化平台的优势是可以使用分布式环境中的其他节点的GPU资源，并且理论上没有数目的限制，具体需要使用多少的GPU资源取决于程序开发人员和分布式环境中的GPU资源数目。此外由于虚拟化平台的透明性很好，使用远程GPU的方式就如同使用本地GPU一样，可以直接通过CUDA提供的接口方便的调用，可移植性非常好。例如CUDA SDK自带的多GPU samples程序绝大部分都可以直接运行在虚拟化平台上，不需要修改源码，只需要修改编译时的选项并重新编译即可，只不过这些程序往往都是以演示功能为主，计算规模不大，并不能体现出多GPU虚拟化的优势。

在第2节中详细分析了程序在单GPU的虚拟化平台上的执行流程，在多GPU的虚拟化环境下程序的执行流程也是基本如此。此外在进行多GPU的并行计算时，还有数据的分解、运算和合并等步骤，因此会带来更多的软件栈和控制开销。所以当程序的计算规模不大时，使用多GPU虚拟化平台往往不能得到很好的结果。第4节的实验结果可以证明，当计算规模比较大的时，使用多个GPU是可以抵消这些开销所带来的性能损失从而提升程序的执行效率。

4 实验结果与性能分析

4.1 实验环境

实验中的后端节点是两台配置Inter(R) Core(TM) i5-4590CPU(3.3 GHz)处理器，4 GB内存和100 GB硬盘，GeForce GTX750 Ti GPU，Ubuntu 16.04和Ubuntu 14.04 64位操作系统，CUDA版本分别为6.5和7.5；前端节点是一台物理机，配置Celeron(R) Dual-Core CPU T3000(1.8 GHz)处理器，没有NVIDIA显卡，也没有安装CUDA程序，Ubuntu 14.04 64位操作系统；前端与后端节点通过百兆以太网互连。

4.2 实验内容

实验运行的程序基于CUDA框架使用EM(Expectation Maximization)算法在高斯混合模型(Gaussian Mixture Model)下进行数据聚类，原程序可以使用单个节点上的多个GPU进行加速，是CLUSTER[10]的GPU实现，程序有单节点单GPU和单节点多GPU两个不同的执行模式，当探测到节点中的GPU数目多于一个时，会启用多个线程控制多个GPU来加速程序的执行，实验使用的数据集是用Matlab生成的，所有不同类型的程序都是在同一个数据集上执行。实验中分别在前端节点上使用本地CPU和通过虚拟化平台使用1个、2个远程GPU计算同样的输入数据集，后端节点配置了相同类型的GPU，只是CUDA 版本和操作系统版本有区别。虚拟化平台为基于ZeroMQ通信方式的多GPU虚拟化方案。

图8中横轴代表的是初始时cluster的数目，不同的数目会影响程序的执行时间，所以使用这个参数来做对比，纵轴表示整个程序运行的时间。随着初始cluster的值增加，使用CPU处理花费的时间增长更快，使用GPU获得的加速比也越大，当初始有200个cluster时使用1个GPU比CPU获得6.1的加速比，而使用2个GPU时与使用1个GPU获得1.85的加速比，实验中继续增加cluster时，获得的加速比并没有继续增加。

图8 使用不同设备时程序运行的时间

实验中计算得到了许多参数，如均值、协方差等，表1中的系数π实际上是每个component被选中的概率，并不指代圆周率，实验中运行的GMM程序会得到三个系数；CPU列是使用CPU计算出来的系数π的值，GPU列是使用GPU计算出来的系数π的值。可以看出，对于同样的输入数据集，对于不同的初始cluster，使用GPU计算得到的系数与使用CPU计算的到的系数有些许的误差，这是由于实验中使用的GPU与CPU处理浮点数据的精度不同以及小数的舍入导致的，并不是虚拟化平台影响了程序的正确性。

表1 不同平台上执行得到的compunent的系数

续表1

以上可知，虚拟化平台可以保证程序正确性的情况下，获得比使用CPU时更好的性能，只使用两个GPU时，就可以获得十倍的加速比；GPU的数目增加时可以获得更大的加速比，但是还未达到线性的加速比。这是因为在有多个GPU时会涉及更多的数据交换和参数控制，网络传输的延时也会增加，新增加的软件栈也会影响效率，这些是虚拟化所无法避免的开销。

4.3 实验结论

基于虚拟化的多GPU通用计算平台上，原来基于单机多GPU实现的GMM程序不需要修改源代码就可以运行在没有NVIDIA显卡的前端节点上。通过调用两个远程GPU就能够获得比使用CPU时十倍以上的加速比，并且只需要修改一些配置文件就可以方便地增减所使用的GPU数目，十分灵活。虽然虚拟化带来了一定的性能损失，但是可以有效地实现单机多GPU和多机多GPU的编程模式统一。

5 结 语

实现了基于虚拟化的多GPU通用计算平台，可以十分方便地使用远程GPU进行通用计算。能够使用分布式环境中不同节点上的多个GPU加速程序，且不需要对源码做太多的修改。最后在实验中验证了该平台的有效性。

实验中发现网络性能对于平台的性能有很大的影响，如果使用高速网络如InfiniBand将会提高虚拟化平台的性能，此外，还有GPU RMDA技术，多GPU使用时的P2P问题等能够提升性能的技术可以应用到虚拟化平台上。

[1] Duato J,Pena A J,Silla F,et al.rCUDA:Reducing the number of GPU-based accelerators in high performance clusters[C]//High Performance Computing and Simulation (HPCS),2010 International Conference on.IEEE,2010:224-231.

[2] Shi L,Chen H,Sun J,et al.vCUDA:GPU-accelerated high-performance computing in virtual machines[J].IEEE Transactions on Computers,2012,61(6):804-816.

[3] 石林.GPU通用计算虚拟化方法研究[D].湖南大学,2012.

[4] Giunta G,Montella R,Agrillo G,et al.A GPGPU transparent virtualization component for high performance computing clouds[C]//European Conference on Parallel Processing.Springer Berlin Heidelberg,2010:379-391.

[5] Gupta V,Gavrilovska A,Schwan K,et al.GViM:GPU-accelerated virtual machines[C]//Proceedings of the 3rd ACM Workshop on System-level Virtualization for High Performance Computing.ACM,2009:17-24.

[6] 仝伯兵,杨昕吉,谢振平,等.GPU虚拟化技术及应用研究[J].软件导刊,2015,14(6):153-156.

[7] Suzuki Y,Kato S,Yamada H,et al.GPUvm: why not virtualizing GPUs at the hypervisor?[C]//Usenix Conference on Usenix Technical Conference.USENIX Association,2014:109-120.

[8] Liu M,Li T,Jia N,et al.Understanding the virtualization “Tax” of scale-out pass-through GPUs in GaaS clouds:An empirical study[C]//IEEE,International Symposium on High PERFORMANCE Computer Architecture.IEEE,2015:259-270.

[9] 杨经纬,马凯,龙翔.面向集群环境的虚拟化GPU计算平台简[J].北京航空航天大学学报,2016,42(11):2340-2348.

[10] Bouman C A,Shapiro M,Ncsa,et al.Cluster:An unsupervised algorithm for modeling Gaussian mixtures[J].Soft Manual,2005.

[11] Castelló A,Duato J,Mayo R,et al.On the use of remote GPUs and low-power processors for the acceleration of scientific applications[C]//The Fourth International Conference on Smart Grids,Green Communications and IT Energy-aware Technologies (ENERGY),2014:57-62.

[12] Sourouri M,Gillberg T,Baden S B,et al.Effective multi-GPU communication using multiple CUDA streams and threads[C]//2014 USENIX Annual Technical Conference Parallel and Distributed Systems (ICPADS).IEEE,2014:981-986.

[13] Gottschlag M,Hillenbrand M,Kehne J,et al.LoGV:Low-Overhead GPGPU Virtualization[C]//IEEE,International Conference on High PERFORMANCE Computing and Communications & 2013 IEEE International Conference on Embedded and Ubiquitous Computing.IEEE,2014:1721-1726.

[14] Yang C T,Liu J C,Wang H Y,et al.Implementation of GPU virtualization using PCI pass-through mechanism[J].The Journal of Supercomputing,2014,68(1):183-213.

[15] 张玉洁.基于多GPGPU并行计算的虚拟化技术研究[D].南京航空航天大学,2015.

[16] 闵芳,张志先,张玉洁.虚拟化环境下多GPU并行计算研究[J].微电子学与计算机,2016,33(3):69-75.

[17] 张玉洁,吕相文,张云洲.GPU虚拟化环境下的数据通信策略研究[J].计算机技术与发展,2015,25(8):24-28.

[18] 张云洲.虚拟化环境下的GPU通用计算关键技术研究[D].南京航空航天大学,2014.

[19] 王刚,唐杰,武港山.基于多GPU集群的编程框架[J].计算机技术与发展,2014,24(1):9-13.

[20] 陈志佳,朱元昌,邸彦强,等.一种改进的GPU虚拟化实施方法[J].计算机工程与科学,2015,37(5):901-906.

RESEARCHOFPARALLELCOMPUTINGPLATFORMOFMULTI-GPUBASEDONVIRTUALENVIRONMENT

Xu Heng1,3Wu Junmin2,3Yang Zhigang2Yin Yan2

1(SchoolofSoftware,UniversityofScienceandTechnologyofChina,Hefei230027,Anhui,China)2(SchoolofComputerScienceandTechnology,UniversityofScienceandTechnologyofChina,Hefei230027,Anhui,China)3(SuzhouInstituteforAdvancedStudy,UniversityofScienceandTechnologyofChina,Suzhou215123,Jiangsu,China)

Aiming at the distributed multi-node and multi-GPUs system environment, a general computing virtualization platform of multi-GPUs based on CUDA framework is implemented. The application program can use the remote GPUs in the same way as the local GPUs. The original CUDA application program can be run on the virtual platform of GPUs without modification or with only a few changes, in order to achieve unity in the programming model of single multi-GPUs and multi-machine multi-GPUs. In the end, we verify the correctness of the experiment through a Gaussian mixture model for data classification by CUDA. The experiment shows that the result of a program using two remote GPUs can get about ten times faster than using the original CPU without affecting the correctness.

Virtualization GPU Multi-machine and multi-GPU Distributed

2017-01-04。国家重点研发计划项目(2016YFB1000403)。徐恒，硕士生，主研领域：GPU通用计算，虚拟化。吴俊敏，副教授。杨志刚，硕士生。尹燕，博士生。

TP3

A

10.3969/j.issn.1000-386x.2017.11.014