图形处理装置、资源服务装置、资源调度方法和装置与流程

本申请涉及计算机应用领域，特别是涉及图形处理装置、资源服务装置、资源调度方法和装置。

背景技术：

由于在现代的计算机中，图形的处理越来越重要，因此，需要一种专门用于图形处理的核心处理器，而图形处理器(GPU，Graphics Processing Unit)就是一种专门用于图形处理的器件。与此同时，把GPU的强大的计算能力处理通用计算(GPGPU，General Purpose GPU)也日益盛行，用于各种高性能计算集群中。

目前，在现有的GPU集群技术中，当处理用户提交的作业(job)时，主要存在两种GPU资源的调度方法。其中，一种调度方法是，资源调度器将一个GPU(如，一张GPU卡)只调度给一个用户的作业。另一种调度方法是，资源调度器将一个GPU同时调度给多个用户的作业。

在实现本申请的过程中，本申请的发明人发现现有技术中至少存在如下问题：在第一种调度方法中，由于一个GPU只被一个用户的作业独占，而一个用户的作业很可能无法充分利用一个GPU的资源，因此会出现GPU资源利用率低的问题。而在第二种调度方法中，由于一个GPU是被多个用户的作业共享的，而多个用户更有可能会充分利用一个GPU的资源，因此一定程度上提高了GPU资源的利用率。

虽然第二种调度方法可以提高GPU资源的利用率，但是，当多个用户的作业共享一个GPU时，多个用户的作业同时开启的进程数可能会很大，对于每一个进程，GPU都要为其建立一个GPU上下文，因此，在GPU上建立的GPU上下文的数量也就可能非常大，并且，还会在数量众多的GPU上下文中进行切换，建立和切换GPU上下文会使GPU资源产生巨大开销，从而导致过度共享GPU问题。

技术实现要素：

为了解决上述技术问题，本申请实施例提供了图形处理装置、资源服务装置、资源调度方法和装置，以在提高GPU资源的利用率的同时，也能节约建立和切换GPU上下文的开销。进一步的，尽可能地避免GPU的过度共享的问题。

本申请实施例公开了如下技术方案：

一种图形处理装置，在所述图形处理装置中，逻辑单元是最小的图形处理器GPU资源调度单元，所述图形处理装置映射至少一个GPU多进程代理服务器GPU-MPS，所述GPU-MPS为调度所述图形处理装置的代理，GPU-MPS的一个客户端可调度至少一个所述逻辑单元，一个任务进程为GPU-MPS的一个客户端，所述图形处理装置可包含的最大逻辑单元数为M×N×K个；

其中，M为GPU-MPS的一个客户端可调度的逻辑单元数，N为一个GPU-MPS包含的最大客户端数，K为所述图形处理装置映射的GPU-MPS数，M、N和K均为非零正整数。

优选的，GPU-MPS的一个客户端可调度一个逻辑单元。

优选的，所述图形处理装置映射一个GPU多进程代理服务器。

优选的，所述图形处理装置包含M×N×K个逻辑单元。

一种资源服务装置，包括至少一个上述任意一项所述的图形处理装置、监测单元和第一通信单元，其中，

监测单元，用于在监测周期到达时，监测当前周期内所述图形处理装置中剩余的逻辑单元的数量；

第一通信单元，用于将监测到的数据发送给集群中的监控节点，以便所述监控节点在更新周期到达时利用监测到的数据原子更新预设的资源动态表；

其中，所述资源动态表至少包含图形处理装置中剩余的逻辑单元的数量。

优选的，所述资源服务装置为集群中的一个从节点。

优选的，所述资源动态表还包含图形处理装置的实际使用率；所述监测单元还用于，在监测周期到达时，监测当前周期内本地的图形处理装置的实际使用率。

一种资源调度方法，应用在上述任意一项所述的资源服务装置，所述方法包括：

接收为目标作业调度图形处理器GPU资源的调度请求，所述调度请求中指示了请求调度的逻辑单元的数量；

响应于所述调度请求，从预设的资源动态表中查找剩余的逻辑单元的数量不为零的图形处理装置，并按照所述调度请求指示的数量，从查找到的图形处理装置中为所述目标作业调度逻辑单元；

其中，所述资源动态表至少包含图形处理装置中剩余的逻辑单元的数量。

优选的，所述资源动态表还包含图形处理装置的实际使用率；

所述响应于所述调度请求，从预设的资源动态表中查找剩余的逻辑单元的数量不为零的图形处理装置，并按照所述调度请求指示的数量，从查找到的图形处理装置中为所述目标作业调度逻辑单元为：

响应于所述调度请求，从预设的资源动态表中查找实际使用率小于或等于预设的最大阈值且剩余的逻辑单元的个数不为零的图形处理装置，并按照所述调度请求指示的数量，从查找到的图形处理装置中为所述目标作业调度逻辑单元。

优选的，所述资源动态表还包含资源服务器集群中的资源服务装置的工作状态和资源服务装置中的图形处理装置的工作状态；所述方法还包括：

在更新周期到达时，原子更新所述资源动态表中资源服务装置的工作状态和图形处理装置的工作状态，所述工作状态包括工作和非工作。

一种资源调度装置，其特征在于，应用在上述任意一项所述的资源服务装置，包括：

第二通信单元，用于接收为目标作业调度图形处理器GPU资源的调度请求，所述调度请求中指示了请求调度的逻辑单元的数量；

响应单元，用于响应于所述调度请求，从预设的资源动态表中查找剩余的逻辑单元的数量不为零的图形处理装置，并按照所述调度请求指示的数量，从查找到的图形处理装置中为所述目标作业调度逻辑单元；

其中，所述资源动态表至少包含图形处理装置中剩余的逻辑单元的数量。

优选的，所述资源动态表还包含图形处理装置的实际使用率；

所述响应单元具体用于，响应于所述调度请求，从预设的资源动态表中查找实际使用率小于或等于预设的最大阈值且剩余的逻辑单元的个数不为零的图形处理装置，并按照所述调度请求指示的数量，从查找到的图形处理装置中为所述目标作业调度逻辑单元。

优选的，所述资源动态表还包含资源服务器集群中的资源服务装置的工作状态和资源服务装置中的图形处理装置的工作状态；所述装置还包括：

更新单元，用于在更新周期到达时，原子更新所述资源动态表中资源服务装置的工作状态和图形处理装置的工作状态，所述工作状态包括工作和非工作。

由上述实施例可以看出，与现有技术相比，本申请的优点在于：

由于逻辑单元是最小的GPU资源调度单元，因此，可以将一个图形处理装置中不同的逻辑单元调度给不同的任务进程，使不同的用户作业共同占用同一个图形处理装置，保证图形处理装置中GPU资源的利用率。同时，本申请利用GPU-MPS技术，使一个任务进程成为GPU-MPS的一个客户端，这样，GPU-MPS就可以像管理客户端一样管理任务进程。由于一个GPU-MPS中的所有客户端共享一个GPU上下文，因此，在一个GPU多进程代理服务器中，作为其客户端的多个任务进程也就只需共享一个GPU上下文。

另外，在资源调度时，基于各GPU的实际使用率调度逻辑单元，还可以避免出现GPU过度共享的问题。

附图说明

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

图1示意性地示出了根据本申请的实施方式的一种图形处理装置的结构图；

图2示意性地示出了根据本申请的实施方式的另一种图形处理装置的结构图；

图3示意性地示出了根据本申请的实施方式的另一种图形处理装置的结 构图；

图4示意性地示出了根据本申请的实施方式的另一种图形处理装置的结构图；

图5示意性地示出了根据本申请的实施方式的一种资源服务装置的结构图；

图6示意性地示出根据本申请的实施方式可以在其中实施的示例性应用场景；

图7示意性地示出了根据本申请的实施方式的一种资源调度装置的结构框图；

图8示意性地示出了根据本申请的实施方式的一种资源调度方法的流程图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图对本申请实施例进行详细描述。

用户提交的一个作业(job)是由多个任务(task)组成的，一个任务是由一个任务进程来完成的。因此，为用户的作业调度GPU资源实际上就是为完成该作业的所有任务进程调度GPU资源。

请参阅图1，图1示意性地示出了根据本申请的实施方式的一种图形处理装置的结构图，在该图形处理装置10中，逻辑单元11是最小的GPU资源调度单元，该图形处理装置映射一个GPU多进程代理服务器(GPU-MPS，Graphics Processing Unit-Multiple Process Server)20，该GPU-MPS 20具有的最大客户端数为16个，并且，该GPU-MPS 20为调度该图形处理装置10的代理，GPU-MPS20的一个客户端可调度一个逻辑单元11，一个任务进程为该GPU-MPS 20的一个客户端，该图形处理装置可包含的最大逻辑单元数为16个。

可以理解的，由于逻辑单元是最小的GPU资源调度单元，因此，可以将一个图形处理装置中不同的逻辑单元调度给不同的任务进程，使不同的用户作业共同占用同一个图形处理装置，保证图形处理装置中GPU资源的利用率。 同时，本申请利用GPU-MPS技术，使一个任务进程成为-GPU-MPS的一个客户端，这样，GPU-MPS就可以像管理客户端一样管理任务进程。由于一个GPU-MPS中的所有客户端共享一个GPU上下文，因此，在一个GPU-MPS中，作为其客户端的多个任务进程也就只需共享一个GPU上下文。例如，当一个图形处理装置映射一个GPU-MPS时，只需为调度该图形处理装置的所有任务进程共享一个GPU上下文，而不再需要分别建立GPU上下文，从而降低了GPU上下文的数量，最终节约了建立和切换GPU上下文的开销。

另外，在为该图形处理装置10配置逻辑单元时，可以在1至16之间(包括1和16)任意配置逻辑单元的数量。

GPU-MPS 20的一个客户端除了可以调度一个逻辑单元之外，可以调度多个逻辑单元，如，2个、3个，甚至更多个逻辑单元。例如，当GPU-MPS20的一个客户端可调度两个逻辑单元，并且，该图形处理装置10仍然映射一个GPU-MPS20时，该图形处理装置10可包含的最大逻辑单元数为32个，如图2所示。由此可见，在该图形处理装置10映射的GPU-MPS 20的个数固定不变的情况下，该图形处理装置10可包含的最大逻辑单元数与GPU-MPS20的一个客户端可调度的逻辑单元数有关，且成正比。

另外，该图形处理装置10可以只映射一个GPU-MPS20，也可以映射多个GPU-MPS 20，如，2个、3个，甚至更多个GPU-MPS 20。例如，当图形处理装置10映射两个GPU-MPS 20，并且，GPU-MPS20的一个客户端可调度一个逻辑单元时，该图形处理装置可包含的最大逻辑单元数为32个，如图3所示。由此可见，在GPU-MPS 20的一个客户端可调度的逻辑单元数固定不变的情况下，该图形处理装置10可包含的最大逻辑单元数与该图形处理装置10映射的GPU-MPS 20的个数有关，且成正比。

也就是说，该图形处理装置10可包含的最大逻辑单元数既与GPU-MPS20的一个客户端可调度的逻辑单元数有关，又与该图形处理装置10映射的GPU-MPS 20的个数有关，且成正比。例如，当图形处理装置10映射两个GPU-MPS 20，并且GPU-MPS 20的一个客户端可调度两个逻辑单元时，该图形处理装置可包含的最大逻辑单元数为64个，如图4所示。

因此，对于图形处理装置10来说，其可包含的最大逻辑单元数为M×N×K 个，其中，M为GPU-MPS的一个客户端可调度的逻辑单元数，N为一个GPU-MPS包含的最大客户端数，K为所述图形处理装置映射的GPU-MPS数，M、N和K均为非零正整数。

在配置该图形处理装置10中的逻辑单元时，只要在该图形处理装置10可包含的最大逻辑单元数以内配置即可。

在本申请的一个优选实施方式中，该图形处理装置10包含M×N×K个逻辑单元。

在本申请的另一个优选实施方式中，GPU-MPS的一个客户端可调度一个逻辑单元，图形处理装置10映射一个GPU-MPS 20。可以理解的，在这种优选实施方式中，一个图形处理装置包含的最大逻辑单元数与一个GPU-MPS包含的最大客户端数相等。

另外，需要说明的是，该图形处理装置10在物理形态上是一个图形处理器。

除了图形处理装置之外，本申请实施例还提供了一种资源服务装置。请参阅图5，图5示意性地示出了根据本申请的实施方式的一种资源服务装置的结构图，其中，该资源服务装置50包括，该资源服务装置50包括至少一个图形处理装置51、(例如，两个图形处理装置511和512)、监测单元52和第一通信单元53。并且，图形处理装置511与GPU-MPS611映射，GPU-MPS 611的一个客户端可调用图形处理装置511中的一个逻辑单元，图形处理装置512与GPU-MPS612映射，GPU-MPS 612的一个客户端可调用图形处理装置512中的一个逻辑单元，一个任务进程可以为GPU-MPS 611的一个客户端，也可以为GPU-MPS 612的一个客户端。

监测单元52，用于在监测周期到达时，监测当前周期内所述图形处理装置中剩余的逻辑单元的数量；

第一通信单元53，用于将监测到的数据发送给集群中的监控节点，以便所述监控节点在更新周期到达时利用监测到的数据原子更新预设的资源动态表；

其中，所述资源动态表至少包含图形处理装置中剩余的逻辑单元的数量。

其中，每一个逻辑单元都会在资源服务器的指定路径下生成一个PIPE文件，一旦该逻辑单元被使用，对应的PIPE文件即会被生成，因此，监测单元11只要监测该路径下的PIPE的数量，即可确定剩余的逻辑单元的数量。

可以理解的，当集群中的各从节点动态更新本地GPU中剩余的逻辑单元的数量时，该更新操作可以支持离线调度，即，不通过统一的调度器调度资源，而直接在本地使用GPU资源)。

需要说明的是，图5所示的资源服务装置的结构仅是一个示例，其还可以更多数量的图形处理装置。并且，本申请也不限定每一个图形处理装置映射的GPU-MPS数量、GPU-MPS的一个客户端可调用的逻辑单元的数量以及每一个图形处理装置包含的逻辑单元的数量。

在本申请的一个优选实施方式中，该资源服务装置50在物理形态上是一个资源服务器。

在申请的另一个优选实施方式中，该资源服务器可以为集群中的一个从节点。

例如，请参阅图6，图6示意性地示出根据本申请的实施方式可以在其中实施的示例性应用场景。其中，在一个集群中，包含有多个从节点10(为了方便描述和展示，图1中仅示出了一个从节点)、一个监控节点20和一个监控节点30。从节点10即为一个资源服务器，在从节点10中包含有多个图形处理器(GPU)，图1中仅示出了两个GPU，即，GPU-0和GPU-1，每一个GPU各包含16个逻辑单元，MPS-0为调度GPU-0的代理，MPS-1为调度GPU-1的代理，并且，MPS-0和MPS-1各具有16个客户端，MPS-0的一个客户端可调度GPU-0的一个逻辑单元，MPS-1的一个客户端可调度GPU-1的一个逻辑单元，用户作业中的一个任务进程既可以为MPS-0的一个客户端，也可以为MPS-1的一个客户端。

例如，当将GPU-0中的一个逻辑单元调度给某一个用户作业中的某一个任务进程时，该任务进程会连接到该逻辑单元所属的GPU-0的代理上，即，连接到MPS-0上。

监控节点30包括作业管理装置31和资源调度装置32，作业管理装置31先接收到集群客户端60发送的为目标用户作业分配GPU资源的请求 61，在该请求61中指示有请求调度的逻辑单元的数量。作业管理装置31将该请求转发给资源调度装置32。

如图7所示的资源调度装置的结构框图，资源调度装置32包括第二通信单元321和响应单元322，其中，第二通信单元321用于接收为目标作业调度图形处理器GPU资源的调度请求61；响应单元322用于响应于所述调度请求，从预设的资源动态表中查找剩余的逻辑单元的数量不为零的图形处理装置，并按照所述调度请求指示的数量，从查找到的图形处理装置中为所述目标作业调度逻辑单元；其中，所述资源动态表至少包含图形处理装置中剩余的逻辑单元的数量。

在本申请中，资源调度装置32可以采用现有技术中的任意一种调度方法调度逻辑单元。例如，First fit调度、Best fit调度、Backfill调度或CFS调度等。

资源调度装置32生成一个资源动态表，并由从节点10动态更新该资源动态表上GPU-0和GPU-1中剩余的逻辑单元的数量，以便资源调度装置32可以根据各GPU剩余的逻辑单元进行资源调度。剩余的逻辑单元就是指未调度给任务进程的逻辑单元。

当然，如果集群中还包括其他从节点，该资源动态表也同时由其它从节点动态维护，并且，该资源动态表中还包含有位于其它从节点上的各GPU中剩余的逻辑单元的数量。也就是说，该资源动态表中包含所有从节点上的GPU中剩余的逻辑单元的数量。

另外，该资源动态表中还可以包含有该资源动态表包含所有从节点的标识以及各从节点中的所有GPU的标识，以确定各个逻辑单元的所在位置。例如，如图6所示资源动态表，该资源动态表中包含从节点10的标识(例如，该标识可以为从节点10在集群中的全局编号)、从节点10包含的GPU-0和GPU-1的标识、以及GPU-0和GPU-1中剩余的逻辑单元的数量。

此外，考虑到作业实际使用的GPU资源很有可能比其请求的GPU资源大，针对一个GPU，其实际使用资源就可能比其调度资源大。当为不同作业调度该GPU中的资源时，也很容易产生过度共享该GPU的问题。

因此，为了避免过度共享GPU的问题，还可以在资源动态表中维护各 GPU的实际使用率，以便资源调度装置根据各GPU的实际使用率调度各GPU中的逻辑单元。也就是说，该资源动态表包含集群中的所有从节点的标识、各从节点中的所有GPU的标识、各GPU中剩余的逻辑单元的数量和各GPU的实际使用率。

在本申请的一个优选实施方式中，资源动态表还包含GPU-0和GPU-1的实际使用率，在从节点10中，监测单元11还用于在监测周期到达时，监测当前周期内GPU-0和GPU-1的实际使用率。

相应的，对于监控节点30，资源调度装置32中的响应单元322具体用于，响应于所述调度请求，从预设的资源动态表中查找实际使用率小于或等于预设的最大阈值且剩余的逻辑单元的个数不为零的图形处理装置，并按照所述调度请求指示的数量，从查找到的图形处理装置中为所述目标作业调度逻辑单元。

在本申请的另一个优选实施方式中，资源动态表还可以包含资源服务器集群中的资源服务装置的工作状态和资源服务装置中的图形处理装置的工作状态，并且由资源调度装置动态更新，资源调度装置32还包括：

更新单元，用于在更新周期到达时，原子更新所述资源动态表中资源服务装置的工作状态和图形处理装置的工作状态和使用状态，所述工作状态包括工作和非工作，使用状态包括逻辑单元的使用量和整体利用率。

例如，当删除从节点或GPU或者生从节点或GPU故障时，其工作状态从工作变为不工作，当添加新的从节点或新的GPU时，其工作状态被设定为工作。

在本申请中，更新单元323可以在集群初始化时，初始化该资源动态表，或者，在作业迁移时，因作业迁移失败或者QoS的原因，需要迁移任务时，更新单元323可以更新该资源动态表。另外，更新单元还可以根据资源调度响应更新资源动态表中各GPU中剩余的逻辑单元的数量。

与上述的资源调度装置相对应，本申请实施例还提供了资源调度方法。请参阅图8，图8示意性地示出了根据本申请的实施方式的一种资源调度方法的流程图，该方法可以由资源调度装置32执行，该方法例如可以包括：

步骤801：接收为目标作业调度图形处理器GPU资源的调度请求，所述调度请求中指示了请求调度的逻辑单元的数量。

步骤802：响应于所述调度请求，从预设的资源动态表中查找剩余的逻辑单元的数量不为零的图形处理装置，并按照所述调度请求指示的数量，从查找到的图形处理装置中为所述目标作业调度逻辑单元。

其中，所述资源动态表至少包含图形处理装置中剩余的逻辑单元的数量。

在本申请的一个优选实施方式中，资源动态表还包含图形处理装置的实际使用率；所述步骤802为：

响应于所述调度请求，从预设的资源动态表中查找实际使用率小于或等于预设的最大阈值且剩余的逻辑单元的个数不为零的图形处理装置，并按照所述调度请求指示的数量，从查找到的图形处理装置中为所述目标作业调度逻辑单元。

在本申请的另一个优选实施方式中，所述资源动态表还包含资源服务器集群中的资源服务装置的工作状态和资源服务装置中的图形处理装置的工作状态；该方法还可以包括：在更新周期到达时，原子更新所述资源动态表中资源服务装置的工作状态和图形处理装置的工作状态，所述工作状态包括工作和非工作。

由上述实施例可以看出，与现有技术相比，本申请的优点在于：

由于逻辑单元是最小的GPU资源调度单元，因此，可以将一个图形处理装置中不同的逻辑单元调度给不同的任务进程，使不同的用户作业共同占用同一个图形处理装置，保证图形处理装置中GPU资源的利用率。同时，本申请利用GPU-MPS技术，使一个任务进程成为GPU-MPS的一个客户端，这样，GPU-MPS就可以像管理客户端一样管理任务进程。由于一个GPU-MPS中的所有客户端共享一个GPU上下文，因此，在一个GPU-MPS中，作为其客户端的多个任务进程也就只需共享一个GPU上下文。

另外，在资源调度时，基于各GPU的实际使用率调度逻辑单元，还可以避免出现GPU过度共享的问题。

所述领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述 描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述到的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性、机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，可以采用软件功能单元的形式实现。

需要说明的是，本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。

以上对本申请所提供的图形处理装置、资源服务装置、资源调度方法和装置进行了详细介绍，本文中应用了具体实施例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。