本发明一般涉及计算机处理器，尤其涉及优化可扩展GPU虚拟化的系统、装置和方法。
背景技术：
：：图形处理单元(GPU)在云计算中发挥着不可替代的作用，因为GPU能高效地加速诸如2D和3D渲染之类的某些工作负载的计算。随着越来越多的GPU密集型工作负载被部署在云端，云服务器提供商引入一种新的计算范式，称为GPU云，以满足对GPU资源的高需求，例如，亚马逊EC2GPU实例和阿里云GPU服务器。作为GPU云的关键实现技术中的一种，GPU虚拟化旨在为多个实例提供高性能的灵活且可扩展(scalable)的GPU资源。为了实现这一具有挑战性的目标，已经引入若干GPU虚拟化解决方案，例如GPUvm和gVirt。gVirt也称为GVT-g，是一种完全虚拟化解决方案，对英特尔图形处理器具有适中的直通支持。在每个虚拟机VM中，利用本机图形驱动器运行，维持虚拟GPU(vGPU)实例以提供直接分配的性能关键资源，因为在性能关键路径上没有虚拟机监控程序(hypervisor)干预。因此，其在性能、特性和共享能力之间优化资源。对于虚拟化方案，可扩展性是一种不可替代的特性，它通过在云服务器上主存密集的VM实例来确保高资源利用率。尽管gVirt成功实施GPU虚拟化，然而它遭受放大vGPU实例的数量的问题。当前版本的gVirt仅支持一个物理英特尔GPU上3个虚拟机vGPU实例，这将虚拟机VM实例的数量限制到3个。相反，CPU虚拟化技术(例如，Xen4.6虚拟机VM支持高达256个vCPU)被充分实现，以便开发其潜能。GPU与类似CPU之类的其它资源的可扩展性之间的不匹配必然减少VM实例的数量。另外，高可扩展性能够提高资源合并。GPU工作负载在GPU利用率上显著波动。gVirt的这种低可扩展性将导致严重的GPU资源利用不足。如果更多的虚拟机VM能够被合并到单个宿主机，则云服务提供商具有更多的机会在具有不同工作负载模式的VM之间复用GPU能力(例如，调度GPU密集或空闲模式的VM)，从而能够提高GPU的物理资源使用率。技术实现要素：本文描述了优化可扩展GPU虚拟化的各种实施方式。在某些实施方式中，提供一种优化可扩展GPU虚拟化的方法，包括：为每个vGPU提供私有影子图形转换表GTT；连同上下文切换将vGPU的私有影子GTT复制到物理GTT，其中所述私有影子GTT允许vGPU共享重叠范围的全局图形存储器空间。应该理解，上述简要描述和以下的详细描述对各个实施例进行了说明并且旨在提供理解要求保护的主题的特性和特点的概览或框架。附图用于提供对各实施例的进一步的理解，并且构成说明书的一部分。附图示出了本文描述的各个实施例，与说明书一起解释要求保护的主题的原理和操作。附图说明图1示出图形转换表GTT的一个实施例的框图。图2示出gScale的架构的一个实施例的框图。图3示出静态共享影子GTT和gScale的动态私有影子GTT。图4示出共享全局图形存储器空间的高地址部分的实施例。图5示出常规映射和阶梯映射。图6示出栅栏寄存器存储器空间池工作的流程。图7示出物理全局图形存储器空间的布局的实施例。图8示出使用细粒度分区片的物理全局图形存储器空间的布局的示例。图9示出gScale如何通过预测GTT复制减少总的执行时间。图10示出gScale主控的LinuxVM的2D和3D性能。图11示出Windows中gScale的可扩展性。图12示出gScale与gVirt的性能比较。图13示出具有或不具有预测GTT复制以及考虑到预测复制机制的调度的gScale之间的Linux3D性能比较。图14示出具有或不具有预测GTT复制以及考虑到预测复制机制的调度的gScale之间的3D性能比较。图15示出私有影子GTT的开销。图16示出WindowsVM的混合测试。具体实施方式在以下的描述中，为了解释的目的，阐述了众多特定细节，以提供对本案的实施例的透彻理解。然而，本领域的技术人员将认识到可在没有一个或多个特定细节的情况下或者与其它替换和/或附加方法、材料或组件一起实施各实施例。在其它情形中，未示出或未详细描述公知的结构、材料或操作以免使本发明的各实施例的诸方面晦涩。由类似OpenGL和DirectX的高级编程API驱动，图形驱动器产生GPU命令至初级缓冲器和批量缓冲器中，同时GPU相应地消耗该命令。初级缓冲器也称为环形缓冲器，被设计成传递具有环形结构的初级命令，但初级缓冲器的尺寸是有限的。为了补偿空间不足，将批量缓冲器链接到初级缓冲器以传递大部分GPU命令。GPU命令由CPU产生并且批量地从CPU传送到GPU。为了确保在CPU产生命令后GPU消耗这些命令，在初级缓冲器中利用两个寄存器实现通知机制。当CPU完成命令放置时，更新尾部寄存器，它将通知GPU在初级缓冲器中获取命令。当GPU完成处理所有的命令时，它写头部寄存器以向CPU通知到来的命令。图1是图形转换表(Graphicstranslationtable，GTT)的一个实施例的框图。图形转换表160有时也被称为全局图形转换表，它是一种页表，提供从逻辑图形存储器地址到物理存储器地址的转换，如图1所示。由GTT160服务的物理存储器空间被称为全局图形存储器空间，它由诸如渲染引擎和显示引擎之类的所有的GPU组件使用，。根据GPU的架构，GTT是驻留在MMIO(存储器映射的输入/输出)范围的GPU的唯一的全局寄存器。CPU不直接访问全局图形存储器空间。然而，入口(Aperture)130也是MMIO范围，通过入口130，CPU110也能访问全局图形存储器空间。全局图形存储器的该CPU可见部分被称为全局图形存储器的低地址部分140，而其余的部分被称为全局图形存储器的高地址部分(GM的高地址部分)或隐藏的全局图形存储器(隐藏的GM)150。注意，GM的低地址部分140和孔130之间的映射由硬件直接设定。在一些实施例中，GPU180具有2MBGTT，它映射到2GB图形存储器空间。入口范围最大可以是512KB，它映射到CPU110可见的512MB图形存储器空间。因此，GM的低地址部分140是512MB，而GM的高地址部分150是1536MB。除了图形转换表160，存在另一种类型的GPU页表，称为每个进程的图形转换表(PPGTT)，它向每个进程提供自身的本地图形存储器空间。与GTT不同，PPGTT驻留在主存储器中。有时，GPU180也使用一组栅栏寄存器来访问全局图形存储器，每个GPU180可仅局域32个栅栏寄存器。本发明的实施例给出gScale，一种实用、高效且可扩展的GPU虚拟化方案。为了增加vGPU实例的数量，gScale针对gVirt的瓶颈设计，并且引入全局图形存储器空间的动态共享方案。gScale向每个vGPU实例提供私有影子图形转换表(GTT)，以打破全局图形存储器空间的限制。gScale连同上下文切换将vGPU的私有影子GTT复制到物理GTT。私有影子GTT允许vGPU共享重叠范围的全局图形存储器空间，这是gScale的核心设计。然而，进行全局图形存储器空间共享是不简单的，因为全局图形存储器空间对于CPU和GPU都是可访问的。gScale实现新颖的阶梯映射机制和栅栏寄存器存储器空间池，以允许CPU访问服务图形存储器的宿主机物理存储器空间，绕过了全局图形存储器空间。然而，假设GTT实际上是存储器映射的寄存器，在上下文切换时，需要将影子GTT复制到物理GTT，这是耗时的操作。为了解决这个问题，gScale提出区片(slot)共享，从而改进高密度实例下vGPU的性能。还引入预测GTT复制，以便在上下文切换前将影子GTT复制到物理GTT，并且使用考虑到预测复制机制的调度算法predictive-copyawarescheduling)以便最大化该优化。图2示出gScale的架构的一个实施例的框图。为了打破全局图形存储器的限制，gScale提出动态共享方案，该方案将分割与共享组合在一起。对于GPU的访问，引入私有影子GTT410，以便使得全局图形存储器空间可共享。对于CPU的访问，纳入阶梯映射单元420，以便允许CPU直接访问服务图形存储器的宿主机物理存储器空间，这绕过全局图形存储器空间。对于CPU和GPU的同时访问，gScale保留一部分全局图形存储器的低地址部分作为栅栏寄存器存储器空间池430，以便确保栅栏寄存器存储器的功能。gScale还将全局图形存储器空间的高地址部分分成若干区片，以便平衡私有影子GTT复制造成的开销。然而，由于在上下文切换时复制私有影子GTT至物理GTT的开销，gScale的性能损失是严重的。为了解决该问题，实现预测GTT复制单元460，它通过在上下文切换前将影子GTT410复制到正确位置来改进gScale的性能。考虑到预测复制机制的调度单元470用于改进高密度实例下gScale的性能。在本发明中，gScale的设计解决三个技术问题：(1)如何使得全局图形存储器空间能够在vGPU之间共享，(2)如何使CPU直接访问服务图形存储器的宿主机存储器，且绕过全局图形存储器空间，(3)在高实例密度的情况下如何使gScale的性能影响最小化。在vGPU之间共享全局图形存储器空间是一项非凡的任务，因为CPU和GPU同时访问全局图形存储器空间的低地址部分。然而，全局图形存储器空间的高地址部分仅对GPU可访问，这使得vGPU可共享全局图形存储器空间的高地址部分。图3示出静态共享影子GTT和gScale的动态私有影子GTT。具体而言，引入共享影子GTT，以便将资源分割应用于全局图形存储器空间。它向每个vGPU提供相同的物理GTT视野，而向每个vGPU分配不同的影子GTT部分。因此，每个vGPU占据彼此不同范围的全局图形存储器空间。然而，gScale的私有影子GTT专用于每个vGPU，它向vGPU提供全局图形存储器空间的独特视野。此外，私有影子GTT包含的转换仅对其对应vGPU是有效的。并且gScale连同上下文切换将vGPU的私有影子GTT复制到物理GTT，以便确保物理GTT的转换对于即将到来的vGPU是正确的。当vGPU拥有物理引擎时，gScale将物理GTT的修改同步到vGPU的私有影子GTT。通过操纵私有影子GTT，gScale能够允许vGPU使用重叠范围的全局图形存储器，这使得全局图形存储器空间的高地址部分可共享，如图4所示。然而，图形存储器空间的低地址部分仍然在vGPU之间划分，因为，它对CPU也是可见的。简单地使用私有影子GTT来共享图形存储器空间的低地址部分将会向vGPU提供错误的转换。不幸的是，将影子GTT复制到物理GTT是耗时的工作，上下文切换时间将变得非常长，这将不利地影响性能。这是一个严重的问题，且可通过区片共享单元440、细粒度分区片单元450以及预测GTT复制单元460解决。将私有影子GTT写入物理GTT导致开销。gScale引入按需复制，以便减少不必要的复制开销。虽然gScale能够共享整个GM的高地址部分，但是这不是必要的，因为更多的全局图形存储器不会增加vGPU的性能。相反，共享更多GM的高地址部分可能增加复制影子GTT的开销。结果，gScale仅配置vGPU为具有足够的全局图形存储器。虽然私有GTT的尺寸与物理GTT完全相同，但是vGPU被配置成具有可用全局图形存储器空间的一部分(对应于vGPU的私有影子GTT的一部分)。通过利用这种特性，gScale仅将vGPU的私有影子GTT的需要的部分复制到物理GTT，这将减少不必要的开销。仅共享全局图形存储器空间的高地址部分是不够的，因为应用到全局图形存储器空间的低地址部分的静态分割仍然限制vGPU的数量。全局图形存储器空间的低地址部分对CPU和GPU是可访问的，而CPU和GPU被独立调度。gScale需要始终向VM提供其全局图形存储器空间的低地址部分。一些GPU不具有专用图形存储器，而图形存储器实际上是从系统存储器分配的。VM的图形存储器实际上驻留在逐级物理存储器中。gScale提出阶梯映射以允许CPU直接访问服务图形存储器的宿主机存储器空间，其绕过全局图形存储器空间。当生成VM时，gScale通过扩展页表EPT120将VM的虚拟机物理存储器空间映射到宿主机物理存储器空间，如图1所示，EPT120是用于虚拟化的硬件支持的页表，该页表将虚拟机物理地址转换成宿主机物理地址。通过入口130，即，宿主机物理存储器空间中的MMIO空间的范围，CPU能够访问全局图形存储器空间的低地址部分。利用GTT中的转换，全局图形存储器地址被转换成服务图形存储器的宿主机物理地址。最后，CPU可访问驻留在宿主机物理存储器空间中的图形数据。图5示出常规映射和阶梯映射。对于常规映射，通过步骤1、2和3，虚拟机物理地址被转换成宿主机物理地址。当进程完成时，建立虚拟机物理地址和服务图形存储器的宿主机物理地址之间的转换。之后，gScale修改EPT的转换，将虚拟机物理地址直接转换成服务图形存储器的宿主机物理地址，而不参考全局图形存储器地址。这种机制被称为阶梯映射，它是在CPU通过参考GTT访问全局图形存储器空间时建立的。gScale始终监控GTT，并且只要GTT的转换被CPU修改，就构建阶梯映射。总之，阶梯映射允许CPU访问宿主机存储器空间，绕过全局图形存储器空间，之后gScale将使全局图形存储器空间的低地址部分与私有影子GTT共享。尽管阶梯映射用于强制CPU绕过全局图形存储器空间，但仍有一个例外，即CPU可能仍然通过栅栏寄存器访问全局图形存储器空间。栅栏寄存器包含关于图像存储器的特定区域的区块格式的信息。当CPU访问记录在栅栏寄存器中的全局图形存储器该区域时，它需要栅栏寄存器中的格式信息已操作图形存储器。然而，在实现阶梯映射之后，全局图形存储器空间不再可用于CPU。栅栏寄存器中的全局图形存储器地址对于CPU是无效的。为了解决栅栏寄存器的误操作，gScale保留全局图形存储器的低地址部分的专用部分用作栅栏寄存器，并且实现动态管理。全局图形存储器的低地址部分的该保留部分被称为栅栏寄存器存储器空间池。图6示出栅栏寄存器存储器空间池的工作流程：在步骤1，当栅栏寄存器被图形驱动器写入时，gScale获取寄存器内的原始数据。通过分析原始数据，gScale获得格式信息和该栅栏寄存器服务的全局图形存储器空间范围。在步骤2，通过参考EPT的初始映射，gScale找到对应于寄存器中的全局图形存储器空间范围的虚拟机物流存储器空间范围。虽然EPT的初始映射被阶梯映射取代，但是很容易利用备份恢复原始映射，因为初始映射是连续的且具有清楚的偏移和范围。之后，该虚拟机物理存储器空间范围被再次映射到入口内的物流存储器空间范围。在步骤3，gScale暂停该虚拟机物理存储器空间范围的阶梯映射，并且分配具有相同尺寸的栅栏寄存器存储器空间池中的存储器空间范围。在步骤4，gScale将入口中的宿主机物理存储器空间映射到栅栏寄存器存储器空间池中新分配的存储器空间。在步骤5，gScale将服务栅栏寄存器中的图形存储器空间的GTT条目复制到与栅栏寄存器存储器空间池中新分配的图形存储器空间相对应的GTT部分。在步骤6，gScale将新的图形存储器空间范围连同未接触的格式信息写入栅栏寄存器。为此，gScale建立栅栏寄存器的临时映射，并且CPU最终将正确地使用栅栏寄存器中的信息。当栅栏寄存器被更新时，gScale恢复栅栏寄存器服务的前一范围的全局图形存储器空间的阶梯映射，并且释放栅栏寄存器存储器空间池中其对应的存储器空间。之后，gScale重复上述过程以确保更新的寄存器利益能够栅栏寄存器存储器空间池正确地工作。在真实的云环境中，由云主存的实例可能不会一直保持繁忙。gScale实现区片共享来提高高实例密度下vGPU实例的性能。图7示出物理全局图形存储器空间的布局的实施例。如图7所示，gScale将全局图形存储器空间的高地址部分分成若干区片，并且每个区片可保持一个vGPU的图形存储器的高地址部分。gScale可在同一区片内部署若干vGPU。如上所述，全局图形存储器空间的高地址部分可以是1536MB，而384MB足够用于一个VM。然而，gScale仅在图形存储器空间的高地址部分中为VM提供区片，因为全局图形存储器空间的低地址部分的量是512MB，这远远低于全局图形存储器空间的高地址部分。在图形存储器空间的低地址部分中没有用于区片的空闲空间。作为一个优化，gScale对空闲vGPU实例不进行上下文切换，这节省了上下文切换和私有影子GTT复制的成本。对于没有工作负载的vGPU实例，他们不向物理引擎提交命令。gScale跳过它们，并且集中在服务具有重工作负载的实例。同时，gScale不会将空闲vGPU的私有影子GTT的条目复制到物理GTT。利用区片共享，如果一个区片中仅有一个活动的vGPU，则该vGPU将拥有该区片。gScale将其私有影子GTT的全局存储器的高地址部分保持在物理GTT上而不进行条目复制。利用该优化，区片共享可有效地减少私有影子GTT复制的开销，且将在本说明书的后面讨论性能改进。gScale目前具有4个区片(1536MB/384MB＝4)：一个预留用于宿主机vGPU，而剩余3个由虚拟机vGPU共享。区片共享在高实例密度但仅几个vGPU繁忙的情况下有助于gScale提高vGPU的性能。如果云提供商细致地部署虚拟机VM，则可使用区片共享。例如，云提供商允许繁忙vGPU与几个空闲vGPU共享一个区片。云供应商可能需要向它的客户提供不同的配置的vGPU，例如，图形存储器的尺寸不同。一些特殊的应用可能需要更多的图形存储器来正确地运行或更好地执行。gScale提供一种称为细粒度分区片的机制或单元，以便允许云供应商配置具有不同图形存储器尺寸的不同VM。图8示出使用细粒度分区片的物理全局图形存储器空间的布局的示例。gScale将图形存储器空间的高地址部分分成多个子区片，且每个VM可占据某些相邻的子区片。在这种情况下，vGPU1占据子区片1至5，且vGPU2占据子区片4至6。当vGPU1和vGPU2之间发生上下文切换时，仅子区片4和5需要被替换，因为vGPU2的子区片6已经在硬件上。利用细粒度分区片，区片共享机制可向云供应商提供更灵活的配置界面。如区片共享所实现的，全局图形存储器的高地址部分被分成4个区片，且若干vGPU可部署在同一区片中。当gScale在vGPU之间进行上下文切换时，VM的影子GTT被复制到物理GTT，这可导致大的开销并限制工作负载的性能。预测GTT复制单元的目的是通过在上下文切换前复制影子GTT来减少这种开销。图9示出gScale如何通过预测GTT复制减少总的执行时间。在另一个VM仍然占据GPU的同时，将VM的影子GTT复制到其对应的区片，因此缩短了上下文切换时间。然而，预测GTT复制可能会在一种情况下失败，即，调度序列中两个相邻的VM被部署在同一区片中，例如，图9中的vGPU4和vGPU5。在这种情况下，gScale将放弃GTT复制，因为GTT的该部分当前正在被运行VM使用。为了实现该算法，称为预先复制线程的线程负责与预测GTT复制有关的工作，诸如根据历史记录投票预测哪个VM可能会成为下一个运行的VM，注意，空闲VM不会被调度，并且将影子GTT复制到物理GTT。当发生上下文切换时，进行上下文切换的线程将唤醒预先复制线程。算法1示出预先复制线程如何根据最后三个调度序列预测下一时间片哪个VM将运行。在预先复制线程被唤醒之前，Cid和Pid将被设置城上下文切换前和上下文切换后VM的ID。应该注意，不保证阵列NextVmId的正确性，阵列NextVmId指示即将切换的下一VM。但是下一VM的不精确预测对正确性没有伤害，因为进行上下文切换的线程将检查影子GTT是否被正确地复制到物理GTT。如上所述，当上下文切换前和上下文切换后的两个VM被部署在同一区片中时，预先复制线程将放弃预测GTT复制。为了最大化预测GTT复制的优化，gScale将通过仔细地安排VM的调度序列尝试避免这种情况。调度中涉及的VM是不稳定的，因为一些VM将在完成其任务后变得空闲。考虑到预测复制机制的调度单元可将繁忙VM的上下文切换序列安排在多个区片上，从而避免调度序列中两个相邻VM被部署在同一区片中的情况。考虑到预测复制机制的调度算法还解决了预先复制线程中的另一个问题。先前的调度序列进行的下一VM的预测是不精确的。一旦预测不正确，预测GTT复制优化在一个循环中无效。然而，在考虑到预测复制机制的调度算法的辅助下，预测复制线程能够获得精确的调度序列，因此它不进行错误预测。考虑到预测复制机制的调度算法通过以下的工作流程安排多个区片上vGPU的上下文切换序列：在步骤a)，在所有的区片中找出具有最大数量vGPU的第一区片；在步骤b)，从第一区片弹出一个vGPU；在步骤c)，在剩余的区片中找出具有最大数量vGPU的第二区片；在步骤d)从第二区片中弹出一个vGPU；在步骤e)，将弹出的vGPU插入输出Vm列表(OutputVmList)，OutputVmList指示一个循环的调度序列；在步骤f)返回步骤a)并重复步骤a)至步骤e)。如果所有的其它区片均先弹光它们的vGPU而最后一个区片中的一些vGPU未被弹出，则将最后一个区片中的所有剩余的VM插入OutputVmList。算法2示出gScale如何安排多个区片中VM的上下文切换序列。过程getNextVm将找出具有最大数量的VM的区片，例如，区片k。然后，它交替地从区片k和其它区片弹出VM并且将VM插入OutputVmList，OutputVmList指示一个循环的调度序列。如果区片k先弹光所有的VM，则过程getNextVm将被再次调用，以确定其它区片上VM的调度序列。如果所有的其它区片先弹光其VM，而区片k中还有一些VM未弹光，仅将所有剩余的VM插入OutputVmList。在这种情况下，不存在满足同一区片没有VM在序列中相邻的调度序列，因为一半以上的VM被部署在区片k中。评价在该部分，当gScale主存增加数量的具有GPU工作负载的虚拟机VGPU时，评价gScale的可扩展性。我们比较了gScale与gVirt的性能，并且证明gScale带来了可忽略的性能趋势。同样，比较了高密度实例下，gScale、其基本版本(不具有区片共享)，其分区片版本(具有区片共享但不具有预测复制)的性能。此外，我们仿真了更复杂的环境，以示出gScale在工业环境下的可用性。所有的VM运行在一个如表1配置的服务器上，且gScale被应用在gVirtd的2015Q3版本上作为一个补丁。为了支持较高的分辨率，栅栏寄存器需要服务较大的图形存储器范围。在本发明的测试环境中，gScale保留300MB的全局图形存储器的低地址部分作为栅栏寄存器存储器空间池，且这足够用于1920*1080分辨率下的15个VM。表1：实验配置我们主要聚焦于3D工作负载，因为在云环境中，图形处理仍然是典型的GPU工作负载。一些2D工作负载也被覆盖。然而，我们仅使用2D工作负载来证明gScale主存的vGPU的全部功能，因为2D工作负载也可通过CPU来加速。对于Linux3D性能，我们选择PhoronixTestSuit3Dmarks，包括Lightsmark、Nexuiz、Openarena、Urbanterror和Warsow。包含一组测试情况的Cairo-perf-trace用于评价Linux2D性能。对于Windows，我们使用3DMark06评价3D性能。选择PassMark来评价2D功能。所有的基准程序都是在1920*1080分辨率下运行的。我们声明，Windows和Linux上的这些3D基准程序都是GPU强度高的，它们在执行时能够完全利用所提供的GPU资源。对于混合测试，我们使用Linpack作为CPU基准程序，它聚焦数字计算。我们实现向每个VM分派任务的测试框架。当所有的任何都被完成时，我们收集测试结果用于分析。基准程序被执行三次。通常，结果非常稳定，误差小于3％。然而，如果结果不稳定，我们将执行更多次以便获得稳定值。当gScale主存打了VM时，I/O是瓶颈。我们在我们的服务器中安装3个SSD驱动器并且将VM的虚拟盘分布在这些SSD驱动器中以满足VM的I/O要求。对于3DMark06，负载进出占用打了时间，这导致在多个VM运行时不可接受的错误。此外，VM在同一时间开始加载，但由于不同的加载速度，它们不能同时处理渲染任务。为了减少加载导致的错误，我们通过将其分成单个单元运行3DMark06，并且每个单元重复3次。3DMark06中的单个单元是GT1-ReturnToProxycon、GT2-FireflyForest、HDR1-CanyonFlight和HDR2-DeepFreeze，并且它们用于SM2.0和SM3.0/HDR性能。在混合测试中，我使用类似的技术，除非分派到半数VM的基准程序是Linpack。1.可扩展性在该部分，我们给出Linux和Windows上gScale的可扩展性的实验。图10示出gScale主控的LinuxVM的2D和3D性能，从1扩展到15，且所有测试的结果被归一化为1VM。通过基准程序给出的帧率(FPS)的值测量本发明中的所有3D性能。FPS值被归一化为1VM，较高的值表示较好的性能。对于所有的3D工作负载，在我们的测试情况下，有微小的性能下降或没有性能下降。然而，当VM的数量增加时，存在性能增加的情况。该结果显示CPU对这些基准程序具有一些影响，因为当仅有一个VM时CPU未被完全利用。对于3D工作负载Lightsmark、Nexuiz、Openarena和Warsow，从5VM扩展到15VM，gScale实现微小的性能改变。这证明GPU资源被有效地共享在多个VM之间。对于2D工作负载，从1VM到5VM，firefox-ast和gnome增加其性能。因为2D工作负载也被CPU加速。GPU可能不是一些基准程序的性能瓶颈。允许这些基准程序的VM不可能消耗大量GPU资源，尤其是当VM的数量较少时。注意，我们使用的CPU具有超线程技术的4个核，且我们仅向每个VM分配2个vCPU，所以当仅有一个活动的VM时，CPU实际上未被完全利用。3D基准程序的性能瓶颈是GPU，所以在1VM至5VM之间没有观察到显著的性能增加。图11示出gScale主存的WindowsVM从1扩展到12的3M性能，且所有的测试结果被归一化为1VM。与Linux不同，Windows基准程序的性能下降更严重。GT1、GT2、HDR1和HDR2的最大下降分别是13.6％、14.7％、8.4％、9.0％。在达到12个VM的点，性能损失变得比较少VM的性能损失更大。原因是当VM的数量增加时，除GPU外的因素，如I/O和缓存，限制了gScale的性能。注意，在GPU渲染时，操作系统和一些系统服务也需要被调度，这导致一些开销。Linux基准程序可能不具有如此高的性能损失，因为与Windows相比，Linux系统以及其基准程序的CPU和I/O强度低，且具有较少的活动线程。假设该性能损失是可接受的，则该实验仍然能够证明从1VM至12VM该性能扩展良好，且当VM的数量增加时，GPU资源被高效率使用。需要提及，对于Linux和Windows，VM的最大数量不是硬限制。英特尔GPU仅具有32个栅栏寄存器，且这些寄存器在gVirt中未被影子化。考虑到每个VM需要占据至少两个寄存器，gScale能够仅支持15个VM和一个宿主机。使这些栅栏寄存器影子化以支持更多VM是可能的。然而，在多数情况下，考虑到英特尔GPU的硬件容量，在云环境中15个VM已经能够完全利用英特尔GPU。支持更多的VM为云供应商带来较少的益处。此外，Windows的12个VM的限制主要是因为在小于32GB可用存储器的情况下主存储器是不足的。2.性能在图12中比较了gScale与gVirt的性能，并且gScale的性能被归一化到gVirt。我们测试了gScale的1-3个VM的设置，因为gVirt仅能支持3个虚拟机vGPU。因为只有3个vGPU，预测GTT复制和考虑到预测复制机制的调度算法被禁用。对于Linux，gScale实现高达99.89％的gVirt性能，而对于Windows，gScale实现高达98.58％的gVirt性能。当实例的数量超过1时，性能下降小于归一化性能的5％。性能降低是因为为图形存储器的低地址部分复制私有影子GTT的一部分，图形存储器的低地址部分在所有的VM之间共享。这类开销是不可避免的，因为全局图形存储器空间共享将导致复制私有影子GTT的开销。我们想要在高实例密度的情况下评价gScale的区片分享机制和预测GTT复制机制。我们同时发起15个VM(对于Linux)或12个VM(对于Windows)。然而，我们仅允许其中一些的GPU密集工作负载，而其余VM保持GPU空闲。GPU空闲的VM表示被发起的VM但没有GPU工作负载。我们使GPU繁忙的VM的数量从1增加到15或从1增加到12，并且观察性能变化。我们使用gScale-Basic表示不具有区片共享的gScale，使用gScale-Slot表示具有区片共享但不具有预测GTT复制的gScale，使用gScale表示具有区片共享和预测GTT复制的gScale。对于Linux中的gScale的3D性能，我们选择Nexuiz作为证明，且在增加数量的VM中运行这种情形，同时gScale主存共计15个VM，如图13所示。当GPU繁忙的VM仅为一个时，gScale和gScale-Basic具有相同的性能。当GPU繁忙的VM的数量增加时，发生私有影子GTT复制。对于gScale-Basic，有20％的性能下降。然而，当GPU繁忙的VM的数量小于4时，gScale具有较小的性能降级，并且GPU繁忙的VM的数量小于6时，区片共享减轻这种性能降级。然而，当GPU繁忙的VM的数量超过6时，区片共享对开销没有帮助，且性能稳定在归一化性能的80％左右。当活动VM的数量小于或等于三时，gScale显示了与gScale-Slot相同或类似的性能。在这种情况下，因为区片共享机制，不发生全局图形存储器的高地址部分的私有影子GTT复制。然而，当活动VM的栅栏寄存器超过四时，gScale显示出比gScale-Slot明显好得多的性能，因为预测GTT复制可降低大量的GTT复制开销。对于在Windows中gScale的3D性能，选择GT1运行在增加数量的VM中，同时gScale主存共计12个VM。如图14所示，当仅有一个GPU繁忙的VM时，gScale显示了与gScale-Basic相同的性能。然而，与Linux上的结果类似，当GPU繁忙的VM的数量超过1时，gScale-Basic具有16.5％的性能降级。当GPU繁忙的VM的数量小于4时，gScale实现平坦的性能变化，且结果显示在GPU繁忙的VM的数量达到6之前区片共享减少性能降级，且gScale和gScale-Basic的性能非常接近。当VM的数量增加时，Linux上的实验显示gScale具有较少的性能损失。然而，当VM的数量增加时，Windows的性能损失比Linux严重一点，因为Windows上的基准程序通常比Linux上的重，且需要更多的CPU资源。3.微分析当CPU修改GTT的条目时，由gScale构建阶梯映射。我们尝试确定在运行3D工作负载时的阶梯映射的频率。我们计算GTT修改的总数以及阶梯映射的次数，以便计算如表2所示的百分比。对于Windows工作负载，阶梯映射很少发生，其小于1％。对于Linux，阶梯映射频率的百分比高于Windows，我们认为原因时Windows中GTT修改的总数比Linux多(高达8x)。同时，我们观察到这种现象：当加载工作负载时通常发生阶梯映射而当处理工作负载时很少发发生阶梯映射。这解释了在可扩展性评价中性能的平坦变化，虽然阶梯映射可能具有开销。LightsMarkNexuizOpenarenaWarsowSM2.0HDR阶梯映射(k)18.84.674.96.610.28.1GTT修改(k)455.3313.5228.51629.91134.21199.7百分比4.13％1.49％2.14％0.40％0.90％0.68％表2阶梯映射的频率复制私有影子GTT引起的开销被评价以显示区片共享、细粒度分区片和预测GTT复制引起的性能优化。在该实验中，我们发起运行Lightsmark的4个LinuxVM。在运行基准程序时，我们记录将私有影子GTT复制到硬件的开销。图15示出实验的结果。在图中，gScale-Basic、gScale-Slot、gScale-FineGrained和gScale-PreCopy分别表示不具有区片共享的gScale、具有区片共享的gScale、具有细粒度分区片的gScale以及具有预测复制的gScale。gScale-Basic、gScale-Slot、gScale-FineGrained和gScale-PreCopy中的VM如表1所示配置。在gScale-FineGrained中，为了示出细粒度分区片的性能影响，我们将非保留的全局GM的高地址部分分成12个子区片，且VM1-4分别占据7个、5个、4个、4个子区片。在gScale-Slot中，我们能够看到区片共享能够减少VM2和VM3的GTT复制开销。VM1和VM4的开销几乎不变，因为它们被部署在同一区片中。在gScale-FineGrained中，复制VM1的私有影子GTT的开销大于VM3和VM4的开销，因为VM1占据7个子区片并且其私有影子GTT具有更多的条目。然而，对于VM2，因为其4个子区片已经在硬件上，复制其私有影子GTT的开销大大减少。在gScale-PreCopy中，我们看到预测GTT复制机制是有效的，因为开销减少了很多。4.混合测试在更类似云的情景下测试了gScale的性能，以证实gScale的可用性。在该实验中，我们发起增加的偶数个WindowsVM，在其中一半上运行GPU密集的工作负载，并且在其余上运行CPU密集的工作负载。这种设计更加忠实于真实的云环境，其中具有CPU密集的工作负载和GPU密集的工作负载的VM主存在同一宿主机上。测试了具有预测GTT复制的gScale和不具有预测GTT复制的gScale。在实验中，主要集中在数字计算上的Linpack被选择作为CPU密集的工作负载。并且HDR2被选择作为GPU密集的工作负载。在该实验中，将数据归一化为2VM，在这种情况下，一个运行Linpack，另一个运行HDR2。我们使用gScale-Slot来指示不具有GTT复制和考虑到预测复制机制的调度的gScale。图16示出实验的结果。我们可以看到在该实验中，在具有和不具有预测GTT复制的情况下，CPU密集的工作负载的性能从4VM至12VM扩展。当仅有2个VM时，CPU未被完全利用，这使得CPU性能差。当VM的数量小于或等于六时，两种版本的gScale的GPU性能几乎相同，因为仅2或3个VM运行GPU密集的基准程序，因此没有发生预测GTT复制。当VM的数量达到八且发生预测GTT复制时，具有预测GTT复制的gScale的性能明显比基础版本的好。然而，两个版本的性能比具有较少VM的情况差。原因是gScale需要被完全利用的CPU，以仿真一些类似修改GTT并提交命令之类的虚拟机操作。预测GTT复制的确对CPU密集的基准程序具有一些不利影响，因为它开启新的线程并使用一些CPU资源。这也时当有4个、6个、8个VM时两个条之间轻微的性能差别的主要原因。然而，该影响足够小，可以忽略。总之，当CPU资源稀少时，预测GTT复制仍然是有效的，且它对CPU密集的工作负载不具有不可接受的不利影响。尽管上文描述了本发明的各实施例，但是，应该理解，它们只是作为示例来呈现的，而不作为限制。对于相关领域的技术人员显而易见的是，可以对其做出各种组合、变型和改变而不背离本发明的精神和范围。因此，此处所公开的本发明的宽度和范围不应被上述所公开的示例性实施例所限制，而应当仅根据所附权利要求书及其等同替换来定义。当前第1页1 2 3 当前第1页1 2 3