基于LINUX系统的多GPU板卡bounding的系统、方法及介质

技术领域

本发明实施例涉及计算机硬件技术领域，尤其涉及一种基于LINUX系统的多GPU板卡绑定bounding的系统、方法及介质。

背景技术

由于图形处理器（GPU，Graphics Processing Unit）的超强计算能力，GPU在图像视频处理、物理、生物科学、化学、人工智能等需要高性能计算的领域发挥重要作用。当前，为了完成日益复杂的图形图像处理任务、通用计算任务和缩减计算时间，往往需要同时使用多GPU板卡进行计算。基于此，需要提供一种能够对多GPU板卡进行管理以及资源分配的方案。

发明内容

有鉴于此，本发明实施例期望提供一种基于LINUX系统的多GPU板卡 bounding 的系统、方法及介质；能够使用多GPU板卡并发处理任务的同时，可以灵活管理这些多GPU板卡以及资源，尽可能提高线程并发效率以及计算性能，实现高吞吐目的。

本发明实施例的技术方案是这样实现的：

第一方面，本发明实施例提供了一种基于LINUX系统的多GPU板卡 bounding 的系统，所述系统包括：gbound内核驱动和gbound_slave用户工具；所述gbound内核驱动，包括gbound模块以及调度模块；其中，所述gbound模块，经配置为基于用户请求创建虚拟的GPUMaster以及将待添加的GPU板卡添加至目标GPU Master所管理的GPU板卡列表中；

所述调度模块，经配置为基于进程粒度为应用程序的处理任务在所述目标GPUMaster所管理的GPU板卡中分配目标GPU板卡；并通过所述gbound_slave用户工具根据所述目标GPU Master所管理的GPU板卡列表向所述目标GPU板卡下发处理任务以执行。

第二方面，本发明实施例提供了一种基于LINUX系统的多GPU板卡 bounding 的方法，所述方法应用于第一方面所述的基于LINUX系统的多GPU bounding 的系统，所述方法包括：

通过gbound模块基于用户请求创建虚拟的GPU Master以及将待添加的GPU板卡添加至目标GPU Master所管理的GPU板卡列表中；

通过调度模块基于进程粒度为应用程序的处理任务在目标GPU Master所管理的GPU板卡中分配目标GPU板卡；并通过所述gbound_slave用户工具根据所述目标GPU Master所管理的GPU板卡列表向目标GPU板卡下发处理任务以执行。

第三方面，本发明实施例提供了一种计算机存储介质，所述计算机存储介质存储有基于LINUX系统的多GPU板卡 bounding 的程序，所述基于LINUX系统的多GPU板卡bounding程序被至少一个处理器执行时实现第二方面中所述基于LINUX系统的多GPU板卡bounding方法步骤。

本发明实施例提供了一种基于LINUX系统的多GPU板卡 bounding的系统、方法及介质；通过在LINUX系统中增加gbound内核驱动和gbound_slave用户工具，协助用户灵活管理当前的GPU bound设备，尽可能提高线程并发，实现高吞吐目的；此外，便于用户场景，灵活动态调整当前多GPU 板卡的使用场景，不再局限于固定bounding场景，可以根据需要将GPU板卡作为别的用途；最后，通过进程为粒度进行GPU板卡绑定，解决存储与任务指令不在同一个GPU内执行的问题，避免出现NUMA现象，提高了计算性能。

附图说明

图1为能够应用本发明实施例技术方案的计算设备的系统框架示意图。

图2为本发明实施例提供的软件模块和从机系统的实例实施方案的框图。

图3为本发明实施例提供的任务分配的流程示意图。

图4为本发明实施例提供的一种基于LINUX系统的多GPU板卡 bounding 的方法流程示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。

目前在应用多GPU板卡执行具体的运算或处理任务时，常规方案通常会采用构造Ringbuffer页空间与多GPU板卡之间的映射关系来对多个GPU板卡的数据进行管理，但是并未从整体上提出对多GPU板卡的管理方案，无法根据业务场景灵活调整，缩限了多GPU板卡的应用范围；举例来说，当系统正常工作时，设定完成三张GPU板卡的绑定之后，那么用户只能一直强制占用这三张GPU板卡，如果想移除其中一张做别的功能使用，那么只能重启机器进行重新初始化绑定配置，无法根据业务需要动态调整显卡绑定。此外，也没有考虑存储分配与任务指令匹配问题，较易导致存储空间与任务指令不在同一个GPU内部，也就意味着GPU需要跨过设备总线去访问存储数据，从而出现非一致性内存访问（NUMA，Non UniformMemory Access）的存储问题，严重影响计算性能。基于此，本发明实施例期望提供一种在LINUX系统环境下多GPU板卡的动态管理方案，期望将多张GPU板卡绑定作为一个逻辑GPU板卡提供用户使用，即为多GPU板卡绑定，也可称之为多GPU bounding，从而能够灵活动态调整当前多GPU板卡的使用场景；此外，还解决存储与任务指令不在同一个GPU内的问题。

参见图1，其示出了能够应用本发明实施例技术方案的计算设备的系统框架100的示意，如图1所示，该框架100可以包括主机系统1和从机系统2，所述主机系统1和从机系统2之间可以通过总线BUS 3连接，该BUS支持两者之间的数据传输及访问等功能。对于主机系统1来说，可以包括CPU、主机内存以及直接内存访问（DMA，Direct Memory Access）等硬件模块11，此外还包括有能够基于前述硬件模块所执行的软件模块12。对于从机系统2来说，可以包括多个GPU板卡，如图1所示，这些GPU板卡可以分别被表示为：GPU 1、GPU 2、……、GPU N。对于主机系统1中的软件模块12来说，可以包括多个应用程序（以M个为例且分别被表示为应用程序1、应用程序2、……、应用程序M）、DRM、GPU内核模块以及基于LINUX系统环境下的gbound内核驱动121和gbound_slave用户工具122。在一些示例中，软件模块12可以通过硬件模块11中的CPU调用主机内存所存储的程序而被执行。

参见图2所示的进一步详细说明图1中软件模块12和从机系统2的实例实施方案的框图。结合图1以及图2，本发明实施例提供了一种基于LINUX系统的多GPU板卡 bounding的系统，在该系统中，采用类似于服务器-客户机（C/S，Client-Server）架构将多个GPU板卡绑定于虚拟的GPU主机（Master）上，从而通过GPU Master对其所属的GPU板卡进行动态灵活的管理。该系统至少可以包括：gbound内核驱动121和gbound_slave用户工具122；所述gbound内核驱动121，包括gbound模块1211以及调度模块1212；其中，所述gbound模块1211，经配置为基于用户请求创建虚拟的GPU Master以及将待添加的GPU板卡添加目标GPUMaster所管理的GPU板卡列表中；

所述调度模块1212，经配置为基于进程粒度为应用程序的处理任务在目标GPUMaster所管理的GPU板卡中分配目标GPU板卡；并通过gbound_slave用户工具122根据目标GPU Master所管理的GPU板卡列表向目标GPU板卡下发处理任务以执行。

结合图2所示以及上述基于LINUX系统的多GPU bounding 的系统，需要说明的是，gbound内核驱动121和gbound_slave用户工具122之间需要配合工作，gbound内核驱动121能够完成GPU板卡与GPU Master之间以及应用程序的处理任务进程与GPU板卡之间的绑定及分配操作，而gbound_slave用户工具122则用于完成上述操作的具体执行过程。

在一些可能的实现方式中，所述gbound模块1211，经配置为基于用户发出的创建虚拟的GPU master请求，利用LINUX系统的DRM框架创建所述GPU Master，并完成接口初始化后挂载于gbound_slave用户工具122中的全局Master列表中。

对于上述实现方式，具体来说，当用户发出创建虚拟的GPU Master请求时，gbound内核驱动121中的gbound模块1211可以利用LINUX的DRM框架在gbound模块1211内创建所述GPU Master，为了与后续添加的GPU板卡进行区分，本发明实施例中可以将该被创建的GPUMaster命名为bcard，比如可以标识为bcard 1。创建完成后，可以将与DRM、存储、GPU任务处理相关的接口进行初始化，并且在初始化完成后挂载到全局Master列表。比如通过gbound_slave用户工具122可以管理有多个虚拟的GPU Master，那么gbound模块1211可以管理一张包含有多个GPU Master的全局GPU Master列表，该列表中记录有已创建的其他虚拟的GPUMaster，比如标识为bcard 0、bcard 2等的GPU Master。

在一些可能的实现方式中，所述gbound模块1211，经配置为基于用户发出的GPU板卡添加请求，根据所述GPU板卡添加请求中所指定待添加的GPU板卡当前的工作状态将所述待添加的GPU板卡添加目标GPU Master所管理的GPU板卡列表中。

对于上述实现方式，具体来说，针对每个虚拟的GPU Master，gbound模块1211也会维护一张列表用于表示GPU Master所管理的GPU板卡，在本发明实施例中，该列表可以命名为bcard slave列表。以目标GPU Master的标识是bcard 1为例，当用户发出添加GPU板卡到标识为bcard 1的GPU Master的添加请求时，gbound内核驱动121中的所述gbound模块1211可以检查该待添加GPU板卡是否处于空闲状态，需要说明的是，为了与GPU Master进行区分，GPU板卡可以基于DRM框架注册且被命名为card，比如可以标识为card 1；此外，gbound_slave用户工具122可以使用上述DRM框架所提供的card，并向gbound模块1211发送相关card设备的绑定信息。对于待添加GPU板卡的空闲状态，本发明实施例示例性地通过该待添加GPU板卡（card 1）是否有待处理任务处于等待状态进行表征，也可以示例性通过该待添加GPU板卡（card 1）是否已经添加到其他GPU Master进行管理进行表征等。如果以上示例性的表征方式均为否，则能够确定该待添加GPU板卡（card 1）处于空闲状态，进而可以添加至目标GPU Master（bcard 1）的bcard slave列表上；否则将无法进行添加。具体地，可以将待添加GPU板卡（card 1）中的Master指向为目标GPU Master（bcard 1），从而完成了上述添加请求。可以理解地，当完成待添加GPU板卡（card 1）添加至目标GPU Master（bcard 1）之后，该GPU板卡（card 1）只处理目标GPU Master（bcard 1）发出的任务请求，而不再处理用户发出的任务请求；此外，考虑GPU板卡（即card设备）的性能因素，本发明实施例还可以通过用户自定义权重来调节各GPU板卡对应的任务缓冲区大小。

基于上述实现方式，在完成GPU Master的创建过程以及将GPU板卡添加至GPUMaster的添加过程之后，在一些示例中，所述gbound模块1211，还经配置为基于用户发出的删除GPU板卡请求，将待删除的GPU板卡的工作状态将所述待删除的GPU板卡从所在的GPUMaster所管理的GPU板卡列表中删除。对于上述示例，具体来说，当用户发出删除GPU板卡请求时，gbound内核驱动121中的所述gbound模块1211将按照前述实现方式中所阐述的手段检测所述删除GPU板卡请求所指定的待删除的GPU板卡是否处于空闲状态，结合前述具体示例，待删除的GPU板卡标识为card 1，其所在的GPU Master设备标识为bcard 1。当确定card1处于空闲状态后，就可以将card 1从bcard 1的bcard slave列表中删除，从而使得card 1不再属于任何GPU Master，进而能够后续基于用户的GPU板卡添加请求将该card 1添加至其他的GPU Master所管理的GPU板卡列表中。

在一些示例中，所述gbound模块1211，还经配置为基于用户发出的删除虚拟的GPUMaster请求，根据待删除的GPU Master所管理的GPU板卡列表中的GPU板卡依次删除后，清理所述待删除的GPU Master的私有资源并将所述待删除的GPU Master从全局Master列表中进行删除。对于上述示例，具体来说，当用户发出删除虚拟的GPU Master请求时，结合前述示例，待删除的GPU Master标识为bcard 1，gbound内核驱动121中的所述gbound模块1211可以将bcard 1的bcard slave列表中的所有GPU 板卡依次清除，然后清理bcard 1对应的私有资源并从全局Master列表中删除bcard 1。

通过上述实现方式以及示例，阐述了本发明实施例利用gbound内核驱动121中的所述gbound模块1211进行虚拟GPU Master以及GPU板卡相关的创建、添加与删除操作过程。此外，当完成虚拟GPU Master的创建以及GPU板卡的添加之后，本发明实施例还需要处理用户发出的关于GPU板卡的存储申请、释放请求，以及任务处理请求等；考虑到存储可能与任务指令不在同一个GPU从而导致NUMA情况的发生，进而导致性能降低的情况出现，如图2所示，gbound内核驱动121可以通过其所包含的调度模块1212基于应用程序的任务线程为基本调度单元来实现任务分配。基于此，在一些示例中，所述调度模块1212，经配置为基于应用程序指定的GPU Master所管理的GPU板卡性能，将所述应用程序的处理任务按照进程为基本单位分配至GPU Master所管理的目标GPU板卡；

以及，根据进程标识与GPU板卡之间的对应关系，从目标GPU板卡中分配存储空间；

以及，根据用户下发的处理任务和进程标识与GPU板卡之间的对应关系，将所述处理任务下发至目标GPU板卡和存储空间以执行。

此外，所述调度模块1212，还经配置为，当下发的处理任务完成后，通知所述应用程序释放存储空间并关闭所述应用程序指定的GPU Master。

对于上述示例，具体来说，其关于任务分配过程执行过程如图3所示的S1至S6所述：

S1：应用程序打开指定的GPU Master，比如标识为bcard 1。

S2：调度模块1212根据当前bcard 1所管理的GPU板卡的性能，比如GPU板卡的资源、存储和处理能力，为当前进程分配GPU板卡。

举例来说，bcard 1申请到的GPU板卡为GPU2，那么就可以绑定进程ID与GPU ID之间的对应关系，也就是说该应用程序的进程后续存储分配与任务下发都在GPU2上执行。

S3：应用程序根据当前进程ID找到目标GPU板卡，从目标GPU板卡中分配存储空间。

S4：应用程序将计算任务下发至目标GPU板卡和存储空间，以使得目标GPU板卡执行下发的计算任务。

S5：计算任务完成后，通知应用程序释放存储空间。

S6：关闭所述应用程序指定的GPU Master，即bcard 1。

通过上述技术方案及其实现方式和示例，本发明实施例通过在LINUX系统中增加gbound内核驱动121和gbound_slave用户工具122，可以协助用户灵活管理当前的GPUbound设备，尽可能提高线程并发，实现高吞吐目的；此外，便于用户场景，灵活动态调整当前多GPU 板卡的使用场景，不再局限于固定bounding场景，可以根据需要将GPU板卡作为别的用途；最后，通过进程为粒度进行GPU板卡绑定，解决存储与任务指令不在同一个GPU内执行的问题，避免出现NUMA现象，提高了计算性能。

基于前述技术方案及其实现方式和示例相同的发明构思，参见图4，其示出了本发明实施例提供的一种基于LINUX系统的多GPU板卡 bounding 的方法，该方法可以应用于前述技术方案所阐述的基于LINUX系统的多GPU板卡 bounding 的系统，该方法可以包括：

S401：通过gbound模块1211基于用户请求创建虚拟的GPU Master以及将待添加的GPU板卡添加至目标GPU Master所管理的GPU板卡列表中；

S402：通过调度模块1212基于进程粒度为应用程序的处理任务在目标GPU Master所管理的GPU板卡中分配目标GPU板卡；并通过gbound_slave用户工具122根据目标GPUMaster所管理的GPU板卡列表向目标GPU板卡下发处理任务以执行。

在一些可能的实现方式中，所述通过gbound模块1211基于用户请求在gbound_slave用户工具122内创建虚拟的GPU Master，包括：

通过所述gbound模块1211基于用户发出的创建虚拟的GPU master请求，利用LINUX系统的DRM框架在所述gbound模块1211内创建所述GPU Master，并完成接口初始化后挂载于所述gbound模块1211中的全局Master列表中。

在一些可能的实现方式中，所述通过gbound模块1211基于用户请求将待添加的GPU板卡添加至目标GPU Master所管理的GPU板卡列表中，包括：

通过所述gbound模块1211基于用户发出的GPU板卡添加请求，根据所述GPU板卡添加请求中所指定待添加的GPU板卡当前的工作状态将所述待添加的GPU板卡添加至所述gbound模块1211内的目标GPU Master所管理的GPU板卡列表中。

基于上述实现方式，在完成GPU Master的创建过程以及将GPU板卡添加至GPUMaster的添加过程之后，在一些示例中，所述方法还包括：

通过所述gbound模块1211基于用户发出的删除GPU板卡请求，根据待删除的GPU板卡的工作状态通过gbound_slave用户工具122将所述待删除的GPU板卡从所在的GPUMaster所管理的GPU板卡列表中删除。

在一些示例中，所述方法还包括：

通过所述gbound模块1211基于用户发出的删除虚拟的GPU Master请求，根据待删除的GPU Master所管理的GPU板卡列表中的GPU板卡依次删除后，清理所述待删除的GPUMaster的私有资源并将所述待删除的GPU Master从全局Master列表中进行删除。

基于上述实现方式以及示例，在一些示例中，所述通过调度模块1212基于进程粒度为应用程序的处理任务在目标GPU Master所管理的GPU板卡中分配目标GPU板卡；并通过gbound_slave用户工具122根据目标GPU Master所管理的GPU板卡列表向目标GPU板卡下发处理任务以执行，包括：

通过所述调度模块1212基于应用程序指定的GPU Master所管理的GPU板卡性能，将所述应用程序的处理任务按照进程为基本单位分配至GPU Master所管理的目标GPU板卡；

通过所述调度模块1212根据进程标识与GPU板卡之间的对应关系，从目标GPU板卡中分配存储空间；

通过所述调度模块1212根据用户下发的处理任务和进程标识与GPU板卡之间的对应关系，将所述处理任务下发至目标GPU板卡和存储空间以执行。

此外，所述方法还包括：当下发的处理任务完成后，通过所述调度模块1212通知所述应用程序释放存储空间；并关闭所述应用程序指定的GPU Master。

可以理解地，上述基于LINUX系统的多GPU板卡 bounding的方法的示例性技术方案，与前述基于LINUX系统的多GPU板卡 bounding的系统的技术方案属于同一构思，因此，上述对于基于LINUX系统的多GPU bounding的方法的技术方案未详细描述的细节内容，均可以参见前述基于LINUX系统的多GPU bounding的系统的技术方案的描述。本发明实施例对此不做赘述。

可以理解地，在本发明实施例中，gbound内核驱动121和gbound_slave用户工具122可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

所述集成的单元如果以软件功能模块的形式实现并非作为独立的产品进行销售或使用时，可以存储在一个计算机可读取存储介质中，基于这样的理解，本实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）或processor（处理器）执行本实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM， Read Only Memory）、随机存取存储器（RAM，Random Access Memory）、磁碟或者光盘等各种可以存储程序代码的介质。

因此，本实施例提供了一种计算机存储介质，所述计算机存储介质存储有基于LINUX系统的多GPU板卡 bounding 的程序，所述基于LINUX系统的多GPU板卡 bounding程序被至少一个处理器执行时实现上述技术方案中所述基于LINUX系统的多GPU板卡bounding方法步骤。

可以理解的是，本文描述的这些实施例可以用硬件、软件、固件、中间件、微码或其组合来实现。对于硬件实现，处理单元可以实现在一个或多个专用集成电路(ApplicationSpecific Integrated Circuits，ASIC)、数字信号处理器(Digital Signal Processing，DSP)、数字信号处理设备(DSP Device，DSPD)、可编程逻辑设备(Programmable LogicDevice，PLD)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)、通用处理器、控制器、微控制器、微处理器、用于执行本申请所述功能的其它电子单元或其组合中。

对于软件实现，可通过执行本文所述功能的模块(例如过程、函数等) 来实现本文所述的技术。软件代码可存储在存储器中并通过处理器执行。存储器可以在处理器中或在处理器外部实现。

需要说明的是：本发明实施例所记载的技术方案之间，在不冲突的情况下，可以任意组合。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。