基于OpenPOWER架构的GPU配置方法及装置与流程

本申请涉及服务器技术领域，具体涉及基于openpower架构的gpu配置方法及装置。

背景技术：

图形处理器(graphicsprocessingunit，简称gpu)作为电脑显卡的处理器，其具有更多的晶体管用于数据处理，特别适用于解决并行计算的问题，可以使程序执行的速度加快。因此，gpu的重要性也越来越高，正在被越来越多的应用于除了简单渲染图形之外的金融建模，科学研究等重要领域。

openpower是国际商业机器公司(internationalbusinessmachinescorporation，简称ibm)、谷歌(google)、英伟达(nvidia)以及许多其他的硬件、软件开发商组成的联盟共同开发的芯片架构，从目前云计算、大数据等高性能需求的市场发展趋势看，传统的x86已经到了遇到瓶颈的时候，而具有高性能优势的openpower未来则十分光明。

但毕竟openpower的市场份额不大，不被大众所熟知，因此在现有的配置gpu显卡时难免会遇到一些报错的问题，导致配置失败。例如，当采用openpower9系列的服务器安装rhel7.5的系统、内核版本4.14.0-49、cuda:9.2，并使用p4gpu卡运行bandwidth测试时，在hash__remap_4k_pfn函数传递pfn值时，会出现报错的情况。

因此，如何利用更先进的方法，实现openpower架构服务器对逻辑推理系列gpu显卡的支持，使得gpu的功能在云计算、大数据等高性能需求的市场中能够得到充分发挥，已成为亟待解决的问题。

技术实现要素：

为解决上述问题，本申请提供了基于openpower架构的gpu配置方法及装置，具体技术方案如下：

第一方面，本申请提供了一种基于openpower架构的gpu配置方法，所述方法应用于基于openpower架构的服务器，所述方法包括：

获取待配置的目标gpu；

通过硬件层与所述目标gpu建立连接；

根据所述连接，通过固件层获取所述目标gpu的唯一标识，并将所述目标gpu的唯一标识保存；

将内核层的默认页表由radix页表切换到hash页表；

通过驱动层获取设备驱动cuda；

通过应用层，根据所述hash页表和所述目标gpu的唯一标识，利用所述设备驱动cuda对所述目标gpu进行测试，以便根据测试结果，完成所述目标gpu的配置。

在一种可选的实现方式中，所述通过硬件层与所述目标gpu建立连接，包括：

通过运行lspci命令，查询所述目标gpu的接口pcie槽位；

根据所述目标gpu的接口槽位，通过所述硬件层与所述目标gpu建立连接。

在一种可选的实现方式中，所述利用所述设备驱动cuda对所述目标gpu进行测试，包括：

生成带宽测试bandwidthtest的测试脚本；

根据所述测试脚本，对所述目标gpu进行带宽测试。

在一种可选的实现方式中，所述利用所述设备驱动cuda对所述目标gpu进行测试，包括：

利用可扩展的异构计算基准套件shoc，对所述目标gpu进行测试。

在一种可选的实现方式中，所述目标gpu的唯一标识为所述目标gpu的设备id。

第二方面，本申请提供了一种基于openpower架构的gpu配置装置，所述装置应用于基于openpower架构的服务器，所述装置包括：

第一获取单元，用于获取待配置的目标gpu；

建立单元，用于通过硬件层与所述目标gpu建立连接；

第二获取单元，用于根据所述连接，通过固件层获取所述目标gpu的唯一标识，并将所述目标gpu的唯一标识保存；

切换单元，用于将内核层的默认页表由radix页表切换到hash页表；

第三获取单元，用于通过驱动层获取设备驱动cuda；

测试单元，用于通过应用层，根据所述hash页表和所述目标gpu的唯一标识，利用所述设备驱动cuda对所述目标gpu进行测试，以便根据测试结果，完成所述目标gpu的配置。

在一种可选的实现方式中，所述建立单元包括：

查询子单元，用于通过运行lspci命令，查询所述目标gpu的接口pcie槽位；

建立子单元，用于根据所述目标gpu的接口槽位，通过所述硬件层与所述目标gpu建立连接。

在一种可选的实现方式中，所述测试单元包括：

生成子单元，用于生成带宽测试bandwidthtest的测试脚本；

第一测试子单元，用于根据所述测试脚本，对所述目标gpu进行带宽测试。

在一种可选的实现方式中，所述测试单元包括：

第二测试子单元，用于利用可扩展的异构计算基准套件shoc，对所述目标gpu进行测试。

在一种可选的实现方式中，所述目标gpu的唯一标识为所述目标gpu的设备id。

在本申请提供的基于openpower架构的gpu配置方法中，基于openpower架构的服务器首先获取到待配置的目标gpu，然后，在通过硬件层与目标gpu建立连接后，根据该连接，通过固件层获取并保存目标gpu的唯一标识，接着，将内核层的默认页表由radix页表切换到hash页表，进而，再通过驱动层获取设备驱动cuda，用以在应用层，根据内核层的hash页表和目标gpu的唯一标识，对目标gpu进行测试，以便根据测试结果，完成对目标gpu的配置。可见，本申请实施例先利用openpower架构中的硬件层、固件层写入了目标gpu，再将内核层的默认页表由radix页表切换到gpu支持的hash页表，从而，可以根据该hash页表，对写入的目标gpu提供支持，有效解决了现有问题。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种基于openpower架构的gpu配置方法的流程示意图；

图2为本申请实施例提供的openpower架构的结构示意图；

图3为本申请实施例提供的一种基于openpower架构的gpu配置装置的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

为了便于理解本申请提供的技术方案，下面先对本申请技术方案的研究背景进行简单说明。

众所周知，正如背景技术中的描述，随着云计算、大数据等高性能需求市场的快速发展，相对于传统的x86系统，具有高性能优势的openpower得到了越来越广泛的应用。与此同时，gpu作为电脑显卡的处理器，其具有更多的晶体管用于数据处理，特别适用于解决并行计算的问题，可以使程序执行的速度加快。因此，如何在openpower架构基础上，将gpu的功能在云计算、大数据等高性能需求的市场中得到充分发挥显得尤为重要。

但毕竟openpower的市场份额不大，不被大众所熟知，因此在现有的配置gpu显卡时难免会遇到一些报错的问题，导致配置失败。例如，当采用openpower9系列的服务器安装rhel7.5的系统、内核版本4.14.0-49、cuda(computeunifieddevicearchitecture):9.2，并使用p4gpu卡运行bandwidth测试时，在hash__remap_4k_pfn函数传递pfn值时，会出现报错的情况，导致gpu的配置失败。所以，如何利用更先进的方法，实现openpower架构服务器对逻辑推理系列gpu显卡的支持，使得gpu的功能在云计算、大数据等高性能需求的市场中能够得到充分发挥，已成为亟待解决的问题。

基于此，本申请提出了一种基于openpower架构的gpu配置方法及装置，用于实现openpower架构服务器对逻辑推理系列gpu显卡的支持。

以下将结合附图对本申请实施例提供的基于openpower架构的gpu配置方法进行详细说明。

参见图1，其示出了本申请实施例提供的一种基于openpower架构的gpu配置方法的流程图，本实施例可以包括以下步骤：

s101：获取待配置的目标gpu。

在本实施例中，将采用本实施例进行配置的任一gpu定义为目标gpu。并且，本实施例不限制目标gpu的类型，比如，目标gpu可以是nvidiateslap4/p40系列等。

s102：通过硬件层与目标gpu建立连接。

在本实施例中，通过步骤s101获取到待配置的目标gpu后，为了让目标gpu能够在基于openpower架构的服务器上有效工作，基于openpower架构的服务器可以先通过其架构中包含的硬件层与目标gpu建立连接。

其中，openpower架构的结构示意图如图2所示，包含有硬件层201、固件层202、内核层203、驱动层204、应用层205。

在本申请一些可能的实现方式中，步骤s102的具体实现过程可以包括下述步骤a1-a2：

步骤a1：通过运行lspci命令，查询目标gpu的接口槽位。

在本实现方式中，在获取到待配置的目标gpu后，基于openpower架构的服务器可以通过运行lspci命令查询到目标gpu的接口pcie槽位。

举例说明：以目标gpu为teslap4为例，通过运行lspci命令可以查询到teslap4的gpu卡槽位，例如，0033:01:00.03dcontroller:nvidiacorporationgp104gl[teslap4](reva1)。其中，0033:01:00.0就是teslap4的pcie的槽位。

步骤a2：根据目标gpu的接口槽位，通过硬件层与目标gpu建立连接。

在本实现方式中，通过步骤a1查询到目标gpu的接口槽位后，可以根据目标gpu需要的槽位，通过硬件层为目标gpu提供足够的槽位和通道数。

举例说明：以目标gpu为teslap4为例，由于teslap4的槽位满足的是pcie3.0x16的标准，所以，openpower的服务器可以提供一个pcie3.0x16的槽位给teslap4。其中，如果需要经过转接卡，也需要保证pcie的通道数满足x16。

进而，可以查看到槽位的速率和通道数，例如，lspci–s0033:01:00.0–vvv，输出lnkcap:port#0,speed8gt/s,widthx16。可见，这是符合teslap4卡需要的pcie3.0x16的标准。

s103：根据该连接，通过固件层获取目标gpu唯一标识，并将该目标gpu的唯一标识保存。

在本实施例中，通过步骤s102与目标gpu建立连接后，进一步可以根据该连接，通过固件层获取目标gpu唯一标识，并将标识保存，使得在固件层pcie映射空间能够满足目标gpu卡的要求。

其中，一种可选的实现方式是，目标gpu的唯一标识为目标gpu的设备(device)id。

具体来讲，由于目标gpu(如teslap4gpu)在分配内存时候需要的预存空间(bar1)为256m，可以利用指令lspci-s0033:01:00.0查看内存分配情况。例如，可以查询到region1:memoryat30000000000(64lnkcap:port#0,speed8gt/s,widthx16,-bit,prefetchable)[size＝256m]。

并且，假设在现有技术中，如果目标gpu(如teslap4gpu)在测试带宽时，遇到的cuda问题为“cudaerrormemoryallocation”：bar1地址分配不满足要求，例如，通过lspci命令查看分配到了0x6200000000000不满足42bit内。

则基于openpower架构的服务器需要在固件层的skiboot-6.1默认的deviceid里面加入p4的deviceid，并将pcie映射的内存地址指定到少于42bit。可参考dg-07562-001，其中p4的pcideviceid是0x1bb3。

具体代码如下：

straticstructpci_card_idlane_eq_disable[]＝{0x10de,0x17fd},/*nvidiagm200gl[teslam40]*/

{0x10de,0x1db4},/*nvidiagv100*/}；

这样，即可生成新版固件pnor存储在固件层，用以识别出目标gpu。

s104：将内核层的默认页表由radix页表切换到hash页表。

在本实施例中，可以在openpower9上的内存页面尤其是tlb(translationlookasidebuffer)管理上引入了新的radix页表，以及支持传统的hash页表。

从rhel7.5的默认编译选项来看，在openpower9上是默认采用radix页表方式。而从cuda的行为来看，目前cuda还是采用传统的hash页表来做mmu(memorymanageunit)，从而导致报错。

具体来讲，按照传统方法，让gpu在openpower服务器上工作时，在运行bandwidth测试时，dmesg里面内核报remp_4k_pfnwithwrongpfsvalue,nvidia_mmap_helper+0x66c/0x680[nvidia](unreliable)，调用了驱动中的nvidia_mmap_helper函数，此函数最终调用arch/powerpc/include/asm/book3s/64/hash-64k.h：106。.

在rhel7.5(内核为4.14.0-49.2.2)上，传递disable_radix内核参数之后无法启动。参考ubuntu的描述，该问题在内核4.15.0-10之后得到解决。由于cuda9.2目前不支持ubuntu18.04，因此，需要在rhel7.5上编译一个较高版本的内核以便支持禁用radix页表。并将openpower9上默认的页表从radix表切换到hash页表。

优选的，本实施例可以选用版本号为4.16.15的主线内核。基于该稳定版本，在编译内核安装后，可以在启动过程禁用radix页表，切换为hash页表。

在切换完成后，还可以在系统中，通过tail/proc/cpuinfo查询，判断mmu的类型是否为hash，以判断从radix表切换到hash页表的方式是否成功；同时，也可以通过cat/etc/grub2.cfg查询启动参数中是否加入了disable_radix，以便再次启动时，判断是否已成功禁用radix页表。

从而可以在内核层禁用radix表、设置启动项的同时，实现了内核层的升级，满足了cuda以及目标gpu使用的hash表。

s105：通过驱动层获取设备驱动cuda。

在本实施例中，基于openpower架构的服务器还需要获取设备驱动，用以在系统中驱动设备(目标gpu)的操作系统。

具体来讲，可以在nvidia的cuda下载官网，选择linux操作系统、ppc64le架构、rhel的系统类型，7的版本，rpmlocal的安装包，下载cuda9.2(驱动版本为396.26)。

其中，cuda指的是nvidia利用gpu平台进行通用并行计算的一种计算设备架构，它包含cuda指令集架构(isa)以及gpu内部的并行计算引擎。可以运行c语言、opencl、fortran、c++等类型的编码程序。

进一步的，在安装了cuda后，可以通过运行nvidia-smi命令，查看目标gpu的详细信息，包括驱动的版本、gpu型号、显存大小、功耗、使用率等。

s106：通过应用层，根据hash页表和目标gpu的唯一标识，利用设备驱动cuda对目标gpu进行测试，以便根据测试结果，完成目标gpu的配置。

在本实施例中，通过步骤s105获取到设备驱动cuda后，可以在应用层，根据内核层中的hash页表以及目标gpu的唯一标识(如在固件层加入的目标gpu的deviceid)，利用该设备驱动cuda对目标gpu进行测试，以判断出面部gpu是否能够在openpower服务器上有效工作。

在本申请一些可能的实现方式中，步骤s106中“利用设备驱动cuda对目标gpu进行测试”的具体实现过程可以包括下述步骤b1-b2：

步骤b1：生成带宽测试bandwidthtest的测试脚本。

在本实现方式中，在cuda安装好之后，进一步可以生成带宽测试bandwidthtest的测试脚本，比如，可以在目录/usr/local/cuda/samples/下，常用的是目标1_utilities/bandwidthtest.下编译，生成bandwidthtest的测试脚本。

步骤b2：根据该测试脚本，对目标gpu进行带宽测试。

通过步骤b1生成bandwidthtest的测试脚本后，可以根据内核层中的hash页表以及目标gpu的唯一标识(如在固件层加入的目标gpu的deviceid)，运行bandwidthtest，对目标gpu进行带宽测试，从而解决了现有方法中bandwidthtest测试报错的问题。

在本申请一些可能的实现方式中，步骤s106中“利用设备驱动cuda对目标gpu进行测试”的具体实现过程还可以包括：利用可扩展的异构计算基准套件shoc，对所述目标gpu进行测试。

在本实现方式中，通过步骤s105获取到设备驱动cuda后，可以在应用层，采用可扩展的异构计算基准套件(scalableheterogeneouscomputingbenchmarksuite，简称shoc)，对目标gpu的性能进行初步测试，比如可以测试目标gpu在运行过程中矩阵相乘、时域频域转换(傅里叶变换)等过程是否准确。并与其它服务器(如x86工作站)进行对比测试，如果结果符合预期，即，测试出目标gpu可以在openpower服务器上有效工作，则完成了基于openpower架构的目标gpu的配置，使得gpu的功能在云计算、大数据等高性能需求的市场中能够得到充分发挥，有效解决了现有问题。

综上，在本申请提供的基于openpower架构的gpu配置方法中，基于openpower架构的服务器首先获取到待配置的目标gpu，然后，在通过硬件层与目标gpu建立连接后，根据该连接，通过固件层获取并保存目标gpu的唯一标识，接着，将内核层的默认页表由radix页表切换到hash页表，进而，再通过驱动层获取设备驱动cuda，用以在应用层，根据内核层的hash页表和目标gpu的唯一标识，对目标gpu进行测试，以便根据测试结果，完成对目标gpu的配置。可见，本申请实施例先利用openpower架构中的硬件层、固件层写入了目标gpu，再将内核层的默认页表由radix页表切换到gpu支持的hash页表，从而，可以根据该hash页表，对写入的目标gpu提供支持，有效解决了现有问题。

上述实施例详细叙述了本申请方法的技术方案，相应地，本申请还提供了一种基于openpower架构的gpu配置装置，下面对该装置进行介绍。

参见图3，图3是本申请实施例提供的一种基于openpower架构的gpu配置装置的结构图，如图3所示，该装置包括：

第一获取单元301，用于获取待配置的目标gpu；

建立单元302，用于通过硬件层与所述目标gpu建立连接；

第二获取单元303，用于根据所述连接，通过固件层获取所述目标gpu的唯一标识，并将所述目标gpu的唯一标识保存；

切换单元304，用于将内核层的默认页表由radix页表切换到hash页表；

第三获取单元305，用于通过驱动层获取设备驱动cuda；

测试单元306，用于通过应用层，根据所述hash页表和所述目标gpu的唯一标识，利用所述设备驱动cuda对所述目标gpu进行测试，以便根据测试结果，完成所述目标gpu的配置。

可选地，所述建立单元302包括：

查询子单元，用于通过运行lspci命令，查询所述目标gpu的接口pcie槽位；

建立子单元，用于根据所述目标gpu的接口槽位，通过所述硬件层与所述目标gpu建立连接。

可选地，所述测试单元306包括：

生成子单元，用于生成带宽测试bandwidthtest的测试脚本；

第一测试子单元，用于根据所述测试脚本，对所述目标gpu进行带宽测试。

可选地，所述测试单元306包括：

第二测试子单元，用于利用可扩展的异构计算基准套件shoc，对所述目标gpu进行测试。

可选地，所述目标gpu的唯一标识为所述目标gpu的设备id。

这样，在本申请提供的基于openpower架构的gpu配置装置中，基于openpower架构的服务器首先获取到待配置的目标gpu，然后，在通过硬件层与目标gpu建立连接后，根据该连接，通过固件层获取并保存目标gpu的唯一标识，接着，将内核层的默认页表由radix页表切换到hash页表，进而，再通过驱动层获取设备驱动cuda，用以在应用层，根据内核层的hash页表和目标gpu的唯一标识，对目标gpu进行测试，以便根据测试结果，完成对目标gpu的配置。可见，本申请实施例先利用openpower架构中的硬件层、固件层写入了目标gpu，再将内核层的默认页表由radix页表切换到gpu支持的hash页表，从而，可以根据该hash页表，对写入的目标gpu提供支持，有效解决了现有问题。

需要说明的是，本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统或装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。