CN113051059B - 一种多gpu的任务实时调度方法及装置 - Google Patents

Abstract

本发明涉及图形处理器技术领域，公开了一种多GPU的任务实时调度方法及装置，所述的多GPU的任务实时调度方法包括：各GPU初始化与显卡同等数量的信号标记，信号标记包括任务锁lock；根据待执行任务的相关参数，判断是否执行任务锁lock抢占策略。本发明的多GPU的任务实时调度方法针对多线程方式接收任务处理时，通过抢占GPU的任务锁lock的方式，任务才能被执行，对于单个GPU避免多任务同时处理造成计算任务之间存在资源竞争，可有效提高GPU实时计算场景下的单卡性能表现，提高吞吐。

Description

一种多GPU的任务实时调度方法及装置

技术领域

本发明涉及图形处理器技术领域，具体的涉及一种多GPU的任务实时调度方法及装置。

背景技术

部分线上GPU在线预测服务请求量巨大，出于性能的考虑，关键算法是自行实现，调用GPU完成计算。常用的GPU服务器都是单机多卡，例如单机4卡，单机8卡等，对于同时要处理的请求来说，计算设备的数量是有限的。这是一种典型的M：N的多生产者多消费者的问题，通常会选择计算模型如图1所示。

图1中上面多个信封代表在线场景下同时到达的计算任务，下面框内的信封排成一列代表一个任务队列，每个GPU上有一个或多个工作线程(实验表明一个更合适，多个存在资源竞争，还得单独设计调度策略)，队列可以是有锁队列，也可以是无锁队列。常见的实现下，队列是FIFO(先进先出)，任务在队列中排序，然后依次处理。

正常情况，任务队列的存在一定程度上就能做到负载均衡，后面的计算设备只会在处理完任务之后再去拿下一个，保证每个时间只有一个任务在显卡上执行。前提是，这台GPU服务器上只有1个服务在运行。

对于多个不同的服务同时运行在一台GPU服务器上的时候，1个GPU上实际对应的就是多个任务队列(如图2所示)，我们发现，即使资源还比较空闲的时候，起多个服务实例也没有等比例提升吞吐。实际数据和理论数据存在gap，这个gap就是损耗，造成损耗的原因最终定位如下：

(1)计算任务之间存在资源竞争，多个同时执行会造成data race，并行的部分变成串行，性能变差。

(2)多个队列反而造成显卡任务不均衡，如图3任务密度图，纵向宽度代表同时执行的任务数量，可以看到不少时刻，四个色带宽度不均匀，说明显卡间任务不均衡，多的就会出现(1)中所说的问题。

因GPU多数应用场景是离线，现有大多数专利描述的任务调度均为离线任务调度，这与我们针对在线服务任务调度的问题不同、场景不同。部分GPU AI场景相关的任务调度也是多卡之间的任务调度策略，目的是多卡负载均衡。而我们的目的是提高GPU实时计算场景下的单卡性能表现，提高吞吐。

有鉴于此，特提出本发明。

发明内容

本发明的目的在于：如何解决多线程方式接收任务时的任务实时调度问题，提高GPU实时计算场景下的单卡性能表现，提高吞吐。

为了实现上述发明目的，本发明提供了以下技术方案：

一种多GPU的任务实时调度方法，包括：

各GPU初始化与显卡同等数量的信号标记，信号标记包括任务锁lock；

根据待执行任务的相关参数，判断是否执行任务锁lock抢占策略。

作为本发明的可选实施方式，每个所述显卡的信号标记在全局范围内唯一，所述信号标记包括任务预计完成时间戳fin_time；

所述相关参数包括：配置服务所属任务的平均运行时间cost_time及默认等待时间wait_time。

作为本发明的可选实施方式，所述的任务锁抢占策略包括：根据各GPU的任务预计完成时间戳变量fin_time，实时返回的当前时间戳变量cur_time以及待执行任务的平均运行时间cost_time、默认等待时间wait_time之间的相互关系判断是否抢占GPU的任务锁；

可选地，所述抢占策略设置为：

判断待执行任务的默认等待时间wait_time的大小；

如wait_time>0，则判断GPU的任务预计完成时间戳变量fin_time当前时间戳变量cur_time早晚关系，以判断当前设备执行任务的情况；

根据当前设备执行任务的情况，待执行任务进行任务锁抢占。

作为本发明的可选实施方式，所述判断GPU的任务预计完成时间戳变量fin_time当前时间戳变量cur_time早晚关系包括：

若GPU的任务预计完成时间戳变量fin_time-当前时间戳变量cur_time≤0，则当前设备无任务执行，抢占该GPU的任务锁lock；若GPU的任务预计完成时间戳变量fin_time-当前时间戳变量cur_time＞0，则进一步判断与待执行任务的平均运行时间cost_time。

作为本发明的可选实施方式，所述进一步判断与待执行任务的平均运行时间cost_time包括：

若GPU的任务预计完成时间戳变量fin_time-当前时间戳变量cur_time≥待执行任务的平均运行时间cost_time，则抢占该GPU的任务锁lock；

若GPU的任务预计完成时间戳变量fin_time-当前时间戳变量cur_time＜待执行任务的平均运行时间cost_time，则放弃抢占该GPU的任务锁lock。

作为本发明的可选实施方式，配置服务所属任务的轮询时间try_time，待执行任务放弃抢占GPU的任务锁lock之后，等待轮询时间try_time后，再次判断待执行任务的默认等待时间wait_time的大小。

作为本发明的可选实施方式，所述的抢占策略还包括：当待执行任务的默认等待时间wait_time≤0时，待执行任务直接抢占GPU的任务锁lock；

或者，当待执行任务的默认等待时间wait_time≤0时，待执行任务绕过任务锁lock直接执行，由GPU视自己资源情况决定是并行还是串行执行。

作为本发明的可选实施方式，待执行任务抢占GPU的任务锁lock之后，将抢占时刻的当前时间戳变量cur_time+待执行任务的平均运行时间cost_time写入被抢占GPU的任务预计完成时间戳变量fin_time，用于其它队列的任务判断是否抢占；然后开始执行。

作为本发明的可选实施方式，所述GPU的工作线程结束运算任务时，修改任务预计完成时间戳变量fin_time为运算任务完成时的当前时间戳cur_time，释放任务锁lock。

可选地，所述平均运行时间cost_time的获取方式为：通过离线测试获取，或者，程序启动前设置默认值，程序运行后，通过统计实际计算任务的平均耗时动态修改默认值；

所述默认等待时间wait_time为预设值；

可选地，所述默认等待时间wait_time＜平均运行时间cost_time；

可选地，所述默认等待时间wait_time不超过平均运行时间cost_time的10％。

本发明同时提供一种多GPU的任务实时调度装置，包括：

初始化模块，对各GPU进行初始化信号标记，信号标记包括任务锁lock，各GPU分别具有任务锁lock；

工作线程模块，从任务队列中获取待执行任务，执行任务锁lock抢占策略；

所述的待执行任务由被抢占任务锁lock的GPU执行。

与现有技术相比，本发明的有益效果：

本发明的多GPU的任务实时调度方法针对GPU服务器“单机多卡”的特点，通过在各个GPU上标记任务锁lock，在进行多线程方式接收任务请求时，通过抢占GPU的任务锁lock的方式使得每个GPU上绑定1个工作线程，从任务队列获取任务，计算完成之后返回给业务线程。

因此，本发明的多GPU的任务实时调度方法针对多线程方式接收任务处理时，通过抢占GPU的任务锁lock的方式，任务才能被执行，对于单个GPU避免多任务同时处理造成计算任务之间存在资源竞争，可有效提高GPU实时计算场景下的单卡性能表现，提高吞吐。

本发明的多GPU的任务实时调度方法通过增加抢占式的近似最短完成时间优先的策略，与原始计算模型相比，总耗时平均减少13.2％，实测同样部署情况下，服务吞吐提升8～15％左右，效果非常明显。

因为GPU作为一种独立的运算设备，操作系统并不会像对CPU一样优化对GPU的任务实时调度，可以说是完全没有调度策略。如果用户程序不考虑这个事情，GPU本身不会做任何优化，完全由用户编写的程序控制，因此，需要通过本发明的多GPU的任务实时调度方法自行实现相关调度策略。实时任务处理场景下，期望平均响应时间最短，最适合的是最短完成时间优先(STCF)，但因为我们并不知道每个实时任务的具体完成时间，这里只能根据实际情况做一些修改，实现一个抢占式的近似最短完成时间优先的策略。

综上，本发明的多GPU的任务实时调度方法具有如下特点：

一、多线程方式接收业务请求，请求是实时产生，实时处理，业务线程将任务放进任务队列，等待GPU上的工作线程计算完成之后接收结果，再将结果向上返回。

二、每个GPU上绑定1个工作线程，从任务队列获取任务，计算完成之后返回给业务线程。

三、单任务队列，有锁和无锁均可，数据结构使用数组和链表均可，先进先出。

附图说明：

图1背景技术中多GPU单任务队列场景示意图；

图2背景技术中多GPU多任务队列场景示意图；

图3背景技术中多GPU多任务队列场景下的任务密度示意图；

图4本发明多GPU的任务实时调度方法处理多任务队列场景的示意图；

图5本发明多GPU的任务实时调度方法的流程图；

图6本发明多GPU的任务实时调度方法的对比效果图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图，对本发明实施例中的技术方案进行清楚、完整的描述。显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。

因此，以下对本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的部分实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征和技术方案可以相互组合。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

在本发明的描述中，需要说明的是，术语“上”、“下”等指示的方位或位置关系为基于附图所示的方位或位置关系，或者是该发明产品使用时惯常摆放的方位或位置关系，或者是本领域技术人员惯常理解的方位或位置关系，这类术语仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

参见图5所示，本实施例提供的一种多GPU的任务实时调度方法，包括：各GPU初始化与显卡同等数量的信号标记，信号标记包括任务锁lock；根据待执行任务的相关参数，判断是否执行任务锁lock抢占策略。

本实施例的任务锁lock是GPU执行任务的锁，每个GPU上只有1个，只有抢到这把锁的任务才能被执行。

本实施例的多GPU的任务实时调度方法针对GPU服务器“单机多卡”的特点，通过在各个GPU上标记任务锁lock，在进行多线程方式接收任务请求时，通过抢占GPU的任务锁lock的方式使得每个GPU上绑定1个工作线程，从任务队列获取任务，计算完成之后返回给业务线程。

本实施例提供的一种多GPU的任务实时调度方法从任务队列中获取待执行任务，执行任务锁lock抢占策略，所述的待执行任务由被抢占任务锁lock的GPU执行。

因此，本实施例的多GPU的任务实时调度方法针对多线程方式接收任务处理时，通过抢占GPU的任务锁lock的方式，任务才能被执行，对于单个GPU避免多任务同时处理造成计算任务之间存在资源竞争，可有效提高GPU实时计算场景下的单卡性能表现，提高吞吐。

参见图4所示的多GPU的任务实时调度方法处理多任务队列场景的示意图，多任务队列里的任务被执行前需要按照预设的任务锁lock抢占策略进行任务锁lock的抢占，只有抢占了任务锁lock任务才能由被抢占任务锁lock的GPU执行，使得在多任务队列场景通过本实施例的多GPU的任务实时调度方法能够将任务实时调度给资源合适的GPU显卡，从而确保GPU显卡的单卡性能表现。

本实施例的一种多GPU的任务实时调度方法中，每个所述显卡的信号标记在全局范围内唯一，所述信号标记包括任务预计完成时间戳fin_time；所述相关参数包括：配置服务所属任务的平均运行时间cost_time及默认等待时间wait_time。

本实施例的一种多GPU的任务实时调度方法提供了一种高效率的任务锁抢占策略，具体实现方式如下：

所述信号标记包括任务预计完成时间戳变量fin_time；

配置服务所属任务的平均运行时间cost_time及默认等待时间wait_time；

所述的任务锁抢占策略包括：根据各GPU的任务预计完成时间戳变量fin_time，实时返回的当前时间戳变量cur_time以及待执行任务的平均运行时间cost_time、默认等待时间wait_time之间的相互关系判断是否抢占GPU的任务锁。

本实施例的多GPU的任务实时调度方法通过引入各GPU的任务预计完成时间戳变量fin_time，实时返回的当前时间戳变量cur_time以及待执行任务的平均运行时间cost_time、默认等待时间wait_time四个时间参数，按照一定的比较算法使得GPU在待执行任务在默认等待时间wait_time内优先处理平均运行时间cost_time短的任务，避免平均运行时间cost_time长的任务长时间占用GPU资源，在待执行任务的默认等待时间wait_time耗尽时，优先执行。

需要说明的是，本实施例的任务预计完成时间戳变量fin_time及当前时间戳变量cur_time均是变量参数，在运行过程中，会根据任务的进展进行实时数据返回及修改的，直至服务完成运算。本实施例的待执行任务的平均运行时间cost_time、默认等待时间wait_time是可以进行预先设置的。

其中：

任务预计完成时间戳变量fin_time：GPU上用于标记当前任务结束时刻的变量，每个GPU上只有1个标记。

当前时间戳变量cur_time：返回当前时刻，每次调用结果都是调用的时刻，每次都会不同。

待执行任务的平均运行时间cost_time：服务的配置参数，表示该服务所属计算任务的平均耗时。

默认等待时间wait_time：服务的配置参数，表示该服务所属计算任务能忍受的默认等待时间，根据经验设置，一般不会超过cost_time的10％。

本实施例程序初始化时，通过驱动程序获取GPU设备数量，初始化与显卡同等数量的标记，这个标记包含一个任务锁lock和一个任务预计完成时间戳变量fin_time。信号标记需要使用共享内存实现，确保每个显卡全局范围内只有唯一一个信号标记，即使这个显卡上启动多个服务，对应了多个工作线程。

作为本实施例的一种可选实施方式，本实施例所述的任务锁抢占策略包括：

步骤S101，当待执行任务的默认等待时间wait_time＞0时，则判断GPU的任务预计完成时间戳变量fin_time当前时间戳变量cur_time早晚关系，以判断当前设备执行任务的情况；根据当前设备执行任务的情况，待执行任务进行任务锁抢占。

进一步地，所述判断GPU的任务预计完成时间戳变量fin_time当前时间戳变量cur_time早晚关系包括：

步骤S102，若GPU的任务预计完成时间戳变量fin_time-当前时间戳变量cur_time≤0，说明当前GPU没有任务执行，资源空闲，则抢占该GPU的任务锁lock；

步骤S103，若GPU的任务预计完成时间戳变量fin_time-当前时间戳变量cur_time＞0，则进一步判断与待执行任务的平均运行时间cost_time。

进一步地，所述进一步判断与待执行任务的平均运行时间cost_time包括：

若GPU的任务预计完成时间戳变量fin_time-当前时间戳变量cur_time≥待执行任务的平均运行时间cost_time，说明当前待执行任务可以被更快的完成，则抢占该GPU的任务锁lock，若GPU的任务预计完成时间戳变量fin_time-当前时间戳变量cur_time＜待执行任务的平均运行时间cost_time，说明可有更短运行时间的任务执行，则放弃抢占该GPU的任务锁lock，进行等待一定时间后再次进行抢占任务锁lock的尝试。

进一步地，本实施例多GPU的任务实时调度方法配置服务所属任务的轮询时间try_time，待执行任务放弃抢占GPU的任务锁lock之后，等待轮询时间try_time后，再次执行所述步骤S101至步骤S103。其中，轮询时间try_time为计算任务等待的最小时间片，任务让出执行权力的时候等待轮询时间try_time时间再次查询任务预计完成时间戳变量fin_time来判断是否继续等待。可选地，本实施例的轮询时间try_time可配置为平均运行时间cost_time的10％。

本实施例的待执行任务在进行等待的过程中，每隔一个轮询时间try_time进行一次判断，若满足抢占任务锁lock的条件时即可抢占并提前执行；若将默认等待时间wait_time轮询完之后，依然不满足抢占任务锁lock的条件时，本实施例所述的任务锁抢占策略包括：

步骤S201，当待执行任务的默认等待时间wait_time≤0时，待执行任务直接抢占GPU的任务锁lock，或者，待执行任务直接绕过抢占GPU的任务锁lock，由GPU并行或者串行执行，具体执行方式由GPU视自身资源情况决定。本实施例的任务锁抢占策略通过引入待执行任务的默认等待时间wait_time这一参数，在任务实时调度时，避免长时间任务无限制等待不被执行，达到了GPU资源的均衡化。

进一步地，本实施例的多GPU的任务实时调度方法，待执行任务抢占GPU的任务锁lock之后，将抢占时刻的当前时间戳变量cur_time+待执行任务的平均运行时间cost_time写入被抢占GPU的任务预计完成时间戳变量fin_time，用于其它队列的任务判断是否抢占；然后开始执行。这样，可以在当前执行任务运算的过程中，任务锁lock被抢占。

进一步地，本实施例的多GPU的任务实时调度方法，所述GPU的工作线程结束运算任务时，修改任务预计完成时间戳变量fin_time为运算任务完成时的当前时间戳，释放任务锁lock。这样，在当前任务运算过程中任务锁lock未被抢占，将任务预计完成时间戳变量fin_time修改为任务结束运算的时间戳，便于针对队列里的其它任务执行任务锁抢占策略。

作为本实施例的可选实施方式，本实施例所述平均运行时间cost_time的获取方式为：通过离线测试获取，由于在GPU上部署的服务一般都需要进行离线测试，因此，通过获取离线测试的运行时间配置为平均运行时间cost_time。或者，程序启动前设置默认值，程序运行后，通过统计实际计算任务的平均耗时动态修改默认值，这样可根据经验先设定平均运行时间cost_time，经过几次的运行后，获取实际的运算耗时，对应进行修改。

本实施例所述默认等待时间wait_time为预设值，一般根据经验设置，但最大不超过平均运行时间cost_time的10％；运行时间长的任务可以多等一会，让运行时间短的任务先执行。

可选地，所述默认等待时间wait_time＜平均运行时间cost_time。

可选地，所述默认等待时间wait_time不超过平均运行时间cost_time的10％。

参见图6所示，本实施例的多GPU的任务实时调度方法通过增加抢占式的近似最短完成时间优先的策略(曲线M2)，与原始计算模型(曲线M1)相比，总耗时平均减少13.2％，实测同样部署情况下，服务吞吐提升8～15％左右，效果非常明显。

因为GPU作为一种独立的运算设备，操作系统并不会像对CPU一样优化对GPU的任务实时调度，可以说是完全没有调度策略。如果用户程序不考虑这个事情，GPU本身不会做任何优化，完全由用户编写的程序控制，因此，需要通过本实施例的多GPU的任务实时调度方法自行实现相关调度策略。实时任务处理场景下，期望平均响应时间最短，最适合的是最短完成时间优先(STCF)，但因为我们并不知道每个实时任务的具体完成时间，这里只能根据实际情况做一些修改，实现一个抢占式的近似最短完成时间优先的策略。

综上，本实施例的多GPU的任务实时调度方法具有如下特点：

一、多线程方式接收业务请求，请求是实时产生，实时处理，业务线程将任务放进任务队列，等待GPU上的工作线程计算完成之后接收结果，再将结果向上返回。

二、每个GPU上绑定1个工作线程，从任务队列获取任务，计算完成之后返回给业务线程。

三、单任务队列，有锁和无锁均可，数据结构使用数组和链表均可，先进先出。

本实施例同时提供一种多GPU的任务实时调度装置，包括：

初始化模块，对各GPU进行初始化信号标记，信号标记包括任务锁lock，各GPU分别具有任务锁lock；

工作线程模块，从任务队列中获取待执行任务，执行任务锁lock抢占策略；

所述的待执行任务由被抢占任务锁lock的GPU执行。

本实施例的任务锁lock是GPU执行任务的锁，每个GPU上只有1个，只有抢到这把锁的任务才能被执行。

本实施例的多GPU的任务实时调度装置针对GPU服务器“单机多卡”的特点，通过在各个GPU上标记任务锁lock，在进行多线程方式接收任务请求时，通过抢占GPU的任务锁lock的方式使得每个GPU上绑定1个工作线程，从任务队列获取任务，计算完成之后返回给业务线程。

因此，本实施例的多GPU的任务实时调度装置针对多线程方式接收任务处理时，通过抢占GPU的任务锁lock的方式，任务才能被执行，对于单个GPU避免多任务同时处理造成计算任务之间存在资源竞争，可有效提高GPU实时计算场景下的单卡性能表现，提高吞吐。

本实施例的一种多GPU的任务实时调度装置可执行一种高效率的任务锁抢占策略，具体实现方式如下：

任务实时调度装置包括配置模块，配置服务所属任务的平均运行时间cost_time及默认等待时间wait_time；所述信号标记包括任务预计完成时间戳变量fin_time；

所述的任务锁抢占策略包括：工作线程模块根据各GPU的任务预计完成时间戳变量fin_time，实时返回的当前时间戳变量cur_time以及待执行任务的平均运行时间cost_time、默认等待时间wait_time之间的相互关系判断是否抢占GPU的任务锁。

本实施例的多GPU的任务实时调度装置通过引入各GPU的任务预计完成时间戳变量fin_time，实时返回的当前时间戳变量cur_time以及待执行任务的平均运行时间cost_time、默认等待时间wait_time四个时间参数，按照一定的比较算法使得GPU在待执行任务在默认等待时间wait_time内优先处理平均运行时间cost_time短的任务，避免平均运行时间cost_time长的任务长时间占用GPU资源，在待执行任务的默认等待时间wait_time耗尽时，优先执行。

需要说明的是，本实施例的任务预计完成时间戳变量fin_time及当前时间戳变量cur_time均是变量参数，在运行过程中，会根据任务的进展进行实时数据返回及修改的，直至服务完成运算。本实施例的待执行任务的平均运行时间cost_time、默认等待时间wait_time是可以进行预先设置的。

其中：

任务预计完成时间戳变量fin_time：GPU上用于标记当前任务结束时刻的变量，每个GPU上只有1个标记。

当前时间戳变量cur_time：返回当前时刻，每次调用结果都是调用的时刻，每次都会不同。

待执行任务的平均运行时间cost_time：服务的配置参数，表示该服务所属计算任务的平均耗时。

默认等待时间wait_time：服务的配置参数，表示该服务所属计算任务能忍受的默认等待时间，根据经验设置，一般不会超过cost_time的10％。

本实施例初始化模块在进行程序初始化时，通过驱动程序获取GPU设备数量，初始化与显卡同等数量的标记，这个标记包含一个任务锁lock和一个任务预计完成时间戳变量fin_time。信号标记需要使用共享内存实现，确保每个显卡全局范围内只有唯一一个信号标记，即使这个显卡上启动多个服务，对应了多个工作线程。

作为本实施例的一种可选实施方式，本实施例所述的多GPU的任务实时调度装置包括：

时间获取模块，获取当待执行任务的默认等待时间wait_time；

时间判断模块，判断默认等待时间wait_time是否大于0：

当默认等待时间wait_time＞0时，时间获取模块获取任务预计完成时间戳变量fin_time和当前时间戳变量cur_time，时间判断模块判断GPU的任务预计完成时间戳变量fin_time-当前时间戳变量cur_time≤0，说明当前GPU没有任务执行，资源空闲，则抢占该GPU的任务锁lock；

时间判断模块判断GPU的任务预计完成时间戳变量fin_time-当前时间戳变量cur_time＞0，则进一步判断与待执行任务的平均运行时间cost_time，若GPU的任务预计完成时间戳变量fin_time-当前时间戳变量cur_time≥待执行任务的平均运行时间cost_time，说明当前待执行任务可以被更快的完成，则抢占该GPU的任务锁lock，若GPU的任务预计完成时间戳变量fin_time-当前时间戳变量cur_time＜待执行任务的平均运行时间cost_time，说明可有更短运行时间的任务执行，则放弃抢占该GPU的任务锁lock，进行等待一定时间后再次进行抢占任务锁lock的尝试。

进一步地，本实施例多GPU的任务实时调度装置包括轮询模块，配置模块配置服务所属任务的轮询时间try_time，待执行任务放弃抢占GPU的任务锁lock之后，轮询模块执行轮询时间try_time后，再次执行所述步骤S101至步骤S103。其中，轮询时间try_time为计算任务等待的最小时间片，任务让出执行权力的时候等待轮询时间try_time时间再次查询任务预计完成时间戳变量fin_time来判断是否继续等待。

本实施例的待执行任务在进行等待的过程中，每隔一个轮询时间try_time进行一次判断，若满足抢占任务锁lock的条件时即可抢占并提前执行；若将默认等待时间wait_time轮询完之后，依然不满足抢占任务锁lock的条件时，本实施例所述的任务锁抢占策略包括：

时间判断模块判断待执行任务的默认等待时间wait_time≤0时，待执行任务直接抢占GPU的任务锁lock，或者，待执行任务直接绕过抢占GPU的任务锁lock，由GPU并行或者串行执行，具体执行方式由GPU视自身资源情况决定。本实施例的任务锁抢占策略通过引入待执行任务的默认等待时间wait_time这一参数，在任务实时调度时，避免长时间任务无限制等待不被执行，达到了GPU资源的均衡化。

进一步地，本实施例的多GPU的任务实时调度装置，待执行任务抢占GPU的任务锁lock之后，将抢占时刻的当前时间戳变量cur_time+待执行任务的平均运行时间cost_time写入被抢占GPU的任务预计完成时间戳变量fin_time，用于其它队列的任务判断是否抢占；然后开始执行。这样，可以在当前执行任务运算的过程中，任务锁lock被抢占。

进一步地，本实施例的多GPU的任务实时调度装置，所述GPU的工作线程结束运算任务时，修改任务预计完成时间戳变量fin_time为运算任务完成时的当前时间戳，释放任务锁lock。这样，在当前任务运算过程中任务锁lock未被抢占，将任务预计完成时间戳变量fin_time修改为任务结束运算的时间戳，便于针对队列里的其它任务执行任务锁抢占策略。

作为本实施例的可选实施方式，本实施例所述平均运行时间cost_time的获取方式为：通过离线测试获取，或者，程序启动前设置默认值，程序运行后，通过统计实际计算任务的平均耗时动态修改默认值；所述默认等待时间wait_time为预设值。

可选地，所述默认等待时间wait_time＜平均运行时间cost_time。

可选地，所述默认等待时间wait_time不超过平均运行时间cost_time的10％。

本实施例的多GPU的任务实时调度装置通过增加抢占式的近似最短完成时间优先的策略，与原始计算模型相比，总耗时平均减少13.2％，实测同样部署情况下，服务吞吐提升8～15％左右，效果非常明显。

因为GPU作为一种独立的运算设备，操作系统并不会像对CPU一样优化对GPU的任务实时调度，可以说是完全没有调度策略。如果用户程序不考虑这个事情，GPU本身不会做任何优化，完全由用户编写的程序控制，因此，需要通过本实施例的多GPU的任务实时调度装置自行实现相关调度策略。实时任务处理场景下，期望平均响应时间最短，最适合的是最短完成时间优先(STCF)，但因为我们并不知道每个实时任务的具体完成时间，这里只能根据实际情况做一些修改，实现一个抢占式的近似最短完成时间优先的策略。

综上，本实施例的多GPU的任务实时调度装置具有如下特点：

一、多线程方式接收业务请求，请求是实时产生，实时处理，业务线程将任务放进任务队列，等待GPU上的工作线程计算完成之后接收结果，再将结果向上返回。

二、每个GPU上绑定1个工作线程，从任务队列获取任务，计算完成之后返回给业务线程。

三、单任务队列，有锁和无锁均可，数据结构使用数组和链表均可，先进先出。

本实施例还提供一种电子设备，包括处理器和存储器，所述存储器用于存储计算机可执行程序，

当所述计算机程序被所述处理器执行时，所述处理器执行所述多GPU的任务实时调度方法。

本实施例同时还提供一种计算机可读介质，存储有计算机可执行程序，所述计算机可执行程序被执行时，实现所述的基于多图片上传的防作弊方法。

通过以上对实施方式的描述，本领域的技术人员易于理解，本发明可以由能够执行特定计算机程序的硬件来实现，例如本发明的系统，以及系统中包含的电子处理单元、服务器、客户端、手机、控制单元、处理器等。本发明也可以由执行本发明的方法的计算机软件来实现，例如由微处理器、电子控制单元，客户端、服务器端等执行的控制软件来实现。但需要说明的是，执行本发明的方法的计算机软件并不限于由一个或特定个的硬件实体中执行，其也可以是由不特定具体硬件的以分布式的方式来实现。对于计算机软件，软件产品可以存储在一个计算机可读的存储介质(可以是CD-ROM，U盘，移动硬盘等)中，也可以分布式存储于网络上，只要其能使得电子设备执行根据本发明的方法。

以上实施例仅用以说明本发明而并非限制本发明所描述的技术方案，尽管本说明书参照上述的各个实施例对本发明已进行了详细的说明，但本发明不局限于上述具体实施方式，因此任何对本发明进行修改或等同替换；而一切不脱离发明的精神和范围的技术方案及其改进，其均涵盖在本发明的权利要求范围当中。

Claims (9)

1.一种多GPU的任务实时调度方法，其特征在于，包括：

各GPU初始化与显卡同等数量的信号标记，信号标记包括任务锁lock；

根据待执行任务的相关参数，判断是否执行任务锁lock抢占策略；

每个所述显卡的信号标记在全局范围内唯一，所述信号标记包括任务预计完成时间戳fin_time；

所述相关参数包括：配置服务所属任务的平均运行时间cost_time及默认等待时间wait_time；

所述的任务锁抢占策略包括：根据各GPU的任务预计完成时间戳变量fin_time，实时返回的当前时间戳变量cur_time以及待执行任务的平均运行时间cost_time、默认等待时间wait_time之间的相互关系判断是否抢占GPU的任务锁；

所述抢占策略设置为：

判断待执行任务的默认等待时间wait_time的大小；

当待执行任务的默认等待时间wait_time＞0时，则判断GPU的任务预计完成时间戳变量fin_time当前时间戳变量cur_time早晚关系，以判断当前设备执行任务的情况，根据当前设备执行任务的情况，待执行任务进行任务锁抢占；

所述判断GPU的任务预计完成时间戳变量fin_time当前时间戳变量cur_time早晚关系包括：

若GPU的任务预计完成时间戳变量fin_time-当前时间戳变量cur_time≤0，则当前设备无任务执行，抢占该GPU的任务锁lock；若GPU的任务预计完成时间戳变量fin_time-当前时间戳变量cur_time＞0，则进一步判断与待执行任务的平均运行时间cost_time；

所述进一步判断与待执行任务的平均运行时间cost_time包括：

若GPU的任务预计完成时间戳变量fin_time-当前时间戳变量cur_time≥待执行任务的平均运行时间cost_time，则抢占该GPU的任务锁lock；

若GPU的任务预计完成时间戳变量fin_time-当前时间戳变量cur_time＜待执行任务的平均运行时间cost_time，则放弃抢占该GPU的任务锁lock。

2.根据权利要求1所述的一种多GPU的任务实时调度方法，其特征在于，配置服务所属任务的轮询时间try_time，待执行任务放弃抢占GPU的任务锁lock之后，等待轮询时间try_time后，再次判断待执行任务的默认等待时间wait_time的大小。

3.根据权利要求1所述的一种多GPU的任务实时调度方法，其特征在于，所述的抢占策略还包括：当待执行任务的默认等待时间wait_time≤0时，待执行任务直接抢占GPU的任务锁lock；

或者，当待执行任务的默认等待时间wait_time≤0时，待执行任务绕过任务锁lock直接执行，由GPU视自己资源情况决定是并行还是串行执行。

4.根据权利要求1-3任意一项所述的一种多GPU的任务实时调度方法，其特征在于，待执行任务抢占GPU的任务锁lock之后，将抢占时刻的当前时间戳变量cur_time+待执行任务的平均运行时间cost_time写入被抢占GPU的任务预计完成时间戳变量fin_time，用于其它队列的任务判断是否抢占；然后开始执行。

5.根据权利要求1-3任意一项所述的一种多GPU的任务实时调度方法，其特征在于，所述GPU的工作线程结束运算任务时，修改任务预计完成时间戳变量fin_time为运算任务完成时的当前时间戳cur_time，释放任务锁lock。

6.根据权利要求5所述的一种多GPU的任务实时调度方法，所述平均运行时间cost_time的获取方式为：通过离线测试获取，或者，程序启动前设置默认值，程序运行后，通过统计实际计算任务的平均耗时动态修改默认值；

所述默认等待时间wait_time为预设值。

7.根据权利要求6所述的一种多GPU的任务实时调度方法，所述默认等待时间wait_time＜平均运行时间cost_time。

8.根据权利要求7所述的一种多GPU的任务实时调度方法，所述默认等待时间wait_time不超过平均运行时间cost_time的10％。

9.一种执行如权利要求1-8任意一项所述多GPU的任务实时调度方法的多GPU的任务实时调度装置，其特征在于，包括：

初始化模块，对各GPU进行初始化信号标记，信号标记包括任务锁lock，各GPU分别具有任务锁lock；

工作线程模块，从任务队列中获取待执行任务，执行任务锁lock抢占策略；

所述的待执行任务由被抢占任务锁lock的GPU执行。

Images