资源需求感知的多队列调度方法、系统及服务器
技术领域
本发明涉及处理器
技术领域
，特别是涉及处理器任务调度管理技术领域
。背景技术
由于深度学习具有强大的特征表示能力，大量的领域开始采用深度学习来解决问题，比 如说物体识别，语音识别，自然语言处理等。深度学习的训练是一个需求巨大算力的过程。 为了解决这个问题，大量的企业开始在自己原有的CPU集群中引入GPU。GPU的引入导致 了原有的同构集群演化为同时包含CPU和GPU的异构集群。与此同时，除了原有的传统CPU 任务之外，异构集群开始要支持GPU任务，也就是深度学习训练任务。举例来说，Facebook 依赖CPU来支持深度学习推理任务与传统任务，依赖GPU来支持深度学习训练任务。新型 异构集群与新型的任务场景向调度系统提出了新的挑战。
深度学习的训练是一个复杂的过程。除了依赖GPU提供巨大算力之外，其仍然需要CPU 来支持必要的辅助工作。首先，当GPU进行计算的时候，CPU负责为GPU准备下一批的训练数据。其次，CPU负责收集所有GPU计算出的梯度，并进行统一更新，然后分发到所有 的GPU。由此可知，GPU任务除了申请一定数量的GPU之外，还需要申请一定数量的CPU。
目前，由于大家对GPU任务的CPU需求是不感知的，现有的GPU任务的CPU申请通 常落于两个范围：过多的CPU申请和过少的CPU申请。当一个GPU任务申请了过多的CPU 时，同一个GPU节点上的其他GPU则无法再承接任务，这导致了GPU碎片化，进而降低了 集群的吞吐率，并提高了其他任务的排队时间。当一个GPU任务申请了过少的CPU时，该 GPU任务很可能会受到相应的性能损失，这同样导致了集群的吞吐率降低，进而也提高了其 他任务的排队时间。
除了训练任务不合理的CPU申请之外，GPU任务仍然需要与CPU任务竞争整个集群的 CPU资源。由于新型异构集群需要同时支持CPU任务与GPU任务，CPU任务与GPU任务 需要竞争集群的CPU资源。当CPU任务大量到来的时候，GPU任务可能因为CPU被全部申 请完毕而遭受长时间等待。除此之外，CPU任务和GPU任务还需要共享GPU节点的CPU端 内存系统，比如说缓存和内存带宽。即使CPU任务没有影响到GPU任务的提交，当CPU任 务占据一个节点的大量内存资源时，GPU任务的性能也可能受到严重影响。
DRF调度算法是加州大学伯克利分校在NSDI2011提出的一个调度算法。现阶段大部 分的主流系统都支持DRF调度算法。DRF调度算法是一种多资源的最大化最小资源分配的分 配策略。换句话说，在多资源的调度环境下，DRF认为一个用户的资源分配应该由该用户的 主导份额资源决定。主导份额资源是该用户申请的所有资源中占整体资源最大份额的一种资 源。DRF调度算法尝试最大化所有用户中最小的主导份额资源。
目前DRF算法存在三个缺点。第一，虽然DRF算法虽然本质上保证了用户间的公平性， 由于GPU任务需求的CPU未知，DRF算法仍然不能避免GPU任务不合理的CPU申请而导 致的吞吐问题和排队问题。第二，DRF算法不能区分两种任务，CPU任务仍然可能占据掉大 量的CPU资源，导致GPU任务的大量排队。第三，由于GPU是粗粒度的资源，当一个用户 申请了一定量的GPU后，GPU非常容易成为其主导份额资源，因此其提交的CPU任务非常 容易遭遇长时间的排队，这事实上影响了用户间的公平性。
发明内容
鉴于以上所述现有技术的缺点，本发明的目的在于提供一种资源需求感知的多队列调度 方法、系统及服务器，用于控制CPU任务与GPU任务的资源任务调度、提高吞吐减少排队 的资源需求。
为实现上述目的及其他相关目的，本发明提供一种资源需求感知的多队列调度方法，包 括：获取用户提交的任务，并判断任务为CPU任务或GPU任务；在任务为GPU任务时，基于调整CPU核数并检查GPU利用率确定最优的CPU配置，进入GPU任务任务调度；在任 务为CPU任务时，直接进入CPU任务调度；执行GPU任务调度或CPU任务调度：对CPU 资源划进行划分，并根据当前CPU任务队列和GPU任务队列的排队状况调整CPU资源队列； 对GPU资源划进行划分，并根据当前GPU任务队列的排队状况调整GPU资源队列；消除 GPU任务与CPU任务在同一个节点上的内存系统的竞争。
于本发明的一实施例中，所述调整CPU核数的一种实现方式为：基于历史信息获取CPU 搜索初始点；根据用户提供的流水线信息、权重信息和CPU计算复杂度中的一个或多个确定 对所述CPU搜索初始点的增减；增减之后的CPU搜索初始点形成任务的搜索初始点。
于本发明的一实施例中，所述根据用户提供的流水线信息、权重信息和CPU计算复杂度 中的一个或多个确定对所述CPU搜索初始点的增减中：若用户提交的任务中包含有流水线信 息，且使用了流水线优化，则对所述CPU搜索初始点进行减1操作；若用户提交的任务中包 含有权重信息，且权重达到预设权重值，则对所述CPU搜索初始点进行减1操作；若用户提 交的任务中包含有CPU端计算复杂度，且CPU计算复杂度达到预设复杂度，则对所述CPU 搜索初始点进行加1操作。
于本发明的一实施例中，所述基于调整CPU核数并检查GPU利用率确定最优的CPU配 置的一种实现方式包括：基于所述任务的搜索初始点获取在当前CPU配置下的GPU利用率； 对所述任务的搜索初始点进行减1循环操作，直到GPU利用率不再提升；对所述任务的搜索 初始点进行加1循环操作，直到GPU利用率不再提升；输出GPU利用率不再提升时对应的 CPU配置即为最优的CPU配置。
于本发明的一实施例中，所述对CPU资源划进行划分包括：将CPU资源划分为CPU任务CPU资源队列和GPU任务CPU资源队列；所述根据当前CPU任务队列和GPU任务队列 的排队状况调整CPU资源队列的一种方式包括：当CPU任务到来而GPU任务队列比较空闲 时，则允许CPU任务抢占GPU任务CPU资源队列中的CPU资源进行预先运算；当GPU任 务到来需要抢占所述GPU任务CPU资源队列中的CPU资源时，中止当前正在运行的CPU 任务，使得GPU任务可以运行；中止的CPU任务重新进入CPU任务CPU资源队列的队列 头，等待被重新被调度。
于本发明的一实施例中，所述GPU任务CPU资源队列由历史GPU任务需求的最高CPU资源确定。
于本发明的一实施例中，所述对GPU资源划进行划分包括：将GPU任务划分为单GPU任务与多GPU任务，对应地将GPU资源划分为单GPU资源队列和多GPU资源队列；所述 根据当前GPU任务队列的排队状况调整GPU资源队列的一种方式包括：当多GPU资源队列 中的GPU被使用完而单GPU任务队列为空时，多GPU任务尝试抢占单GPU资源队列的GPU； 当单GPU资源队列的GPU被使用完而多GPU任务队列为空，单GPU任务尝试抢占多GPU 资源队列的GPU。
于本发明的一实施例中，所述消除GPU任务与CPU任务在同一个节点上的内存系统的 竞争的一种实现方式包括：监控所有进程带宽的使用情况；当CPU任务的带宽使用情况达到 宽带预设值，且该节点上GPU任务的GPU利用率降低预设值时，将该CPU任务的CPU使用核数压缩，且降低该CPU任务的带宽使用率。
本发明的实施例还提供一种资源需求感知的多队列调度系统，所述资源需求感知的多队 列调度系统包括：自感知的CPU分配模块，用于将获取用户提交的任务，判断任务为CPU 任务或GPU任务，并在任务为GPU任务时，基于调整CPU核数并检查GPU利用率确定最 优的CPU配置，进入GPU任务任务调度；多队列的资源调整模块，用于执行GPU任务调度 或CPU任务调度：对CPU资源划进行划分，并根据当前CPU任务队列和GPU任务队列的 排队状况调整CPU资源队列；对GPU资源划进行划分，并根据当前GPU任务队列的排队状 况调整GPU资源队列；实时的竞争消除模块，用于消除GPU任务与CPU任务在同一个节点 上的内存系统的竞争。
本发明的实施例还提供一种服务器，包括CPU和GPU；所述CPU和所述GPU运行时执行如上所述的资源需求感知的多队列调度方法。
如上所述，本发明的资源需求感知的多队列调度方法、系统及服务器具有以下有益效果：
本发明可以有效控制CPU任务与GPU任务的资源任务调度、提高吞吐减少排队的资源 需求，在无需用户感知的前提下，最大化系统的吞吐和最小化系统的排队，可以间接为潜在 的异构集群提供调度技术的支持，为基于异构集群的云环境提供任务调度服务。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附 图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域 普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1显示为本申请一实施例中的资源需求感知的多队列调度方法的整体流程示意图。
图2显示为本申请一实施例中的资源需求感知的多队列调度方法中的确定最优的CPU配 置的一种实现方式流程示意图。
图3显示为本申请一实施例中的资源需求感知的多队列调度方法的执行过程示意图。
图4显示为本申请一实施例中的资源需求感知的多队列调度系统的原理框图。
图5显示为本申请一实施例中的资源需求感知的多队列调度系统的执行过程原理示意 图。
元件标号说明
100 资源需求感知的多队列调度系统
110 自感知的CPU分配模块
120 多队列的资源调整模块
130 实时的竞争消除模块
S100～S600 步骤
具体实施方式
以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露 的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加 以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精 神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征 可以相互组合。
本实施例的目的在于提供一种资源需求感知的多队列调度方法、系统及服务器，用于控 制CPU任务与GPU任务的资源任务调度、提高吞吐减少排队的资源需求。
本实施例旨在设计、实现一个运行于能耗受限数据中心上，管理混合部署的云服务与后 台应用程序间的共享资源的系统和方法，在同时保证云服务的服务质量、满足服务器能耗限 制的基础上，最大化后台批处理任务的吞吐量。
以下将详细阐述本发明的资源需求感知的多队列调度方法、系统及服务器的原理及实施 方式，使本领域技术人员不需要创造性劳动即可理解本发明的资源需求感知的多队列调度方 法、系统及服务器。
实施例1
具体地，如图1所示，本实施例提供一种资源需求感知的多队列调度方法，所述资源需 求感知的多队列调度方法包括：
步骤S100，获取用户提交的任务，并判断任务为CPU任务或GPU任务；
步骤S200，在任务为CPU任务时，直接进入CPU任务调度；
步骤S300，在任务为GPU任务时，基于调整CPU核数并检查GPU利用率确定最优的CPU配置，进入GPU任务任务调度；
步骤S400，对CPU资源划进行划分，并根据当前CPU任务队列和GPU任务队列的排队状况调整CPU资源队列；
步骤S500，对GPU资源划进行划分，并根据当前GPU任务队列的排队状况调整GPU资源队列；
步骤S600，消除GPU任务与CPU任务在同一个节点上的内存系统的竞争。
以下将结合图2对本实施例的资源需求感知的多队列调度方法的步骤S100至步骤S600 进行详细说明。
步骤S100，获取用户提交的任务，并判断任务为CPU任务或GPU任务。
步骤S200，在任务为CPU任务时，直接进入CPU任务调度。
步骤S300，在任务为GPU任务时，基于调整CPU核数并检查GPU利用率确定最优的CPU配置，进入GPU任务任务调度。
由于GPU任务对其需求的CPU是不感知的，本实施例自动化的搜索到GPU任务的最优CPU配置。经过相应的实验，本实施例有三个发现。第一，一个模型训练任务的GPU利用率，即GPU任务的GPU利用率，与该任务的性能有一个相似的变化趋势，并且在同一个CPU 配置下同时达到最优值。第二，GPU任务的GPU利用率与分配的CPU数量有线性的关系。 第三，GPU任务可以简单分为三类，图像任务，语音任务，自然语言任务。每一类内的任务 在CPU端的处理工作是相似的，因此，每一类任务的GPU利用率变化曲线也是相似的。基 于上述三个发现，本实施例通过调整CPU核数来寻找和确认GPU任务获得了最优性能，进 而确认该任务最优的CPU配置。
于本实施例中，所述调整CPU核数的一种实现方式为：基于历史信息获取CPU搜索初 始点；根据用户提供的流水线信息、权重信息和CPU计算复杂度中的一个或多个确定对所述 CPU搜索初始点的增减；增减之后的CPU搜索初始点形成任务的搜索初始点。
其中，所述根据用户提供的流水线信息、权重信息和CPU计算复杂度中的一个或多个确 定对所述CPU搜索初始点的增减中：若用户提交的任务中包含有流水线信息，且使用了流水 线优化，则对所述CPU搜索初始点进行减1操作；若用户提交的任务中包含有权重信息，且 权重达到预设权重值，则对所述CPU搜索初始点进行减1操作；若用户提交的任务中包含有 CPU端计算复杂度，且CPU计算复杂度达到预设复杂度，则对所述CPU搜索初始点进行加 1操作。
具体地，如图2所示，首先通过历史信息获得一个CPU搜索初始点，然后，若用户提供 了流水线信息，且使用了流水线优化，则相应的CPU搜索初始点减1；若用户提供了权重信 息，且权重较多，则相应的CPU搜索初始点减1；若用户提供了CPU端计算复杂度，且CPU计算复杂度较高，则CPU搜索初始点加1；由此确定了每个任务的搜索初始点。
于本实施例中，所述基于调整CPU核数并检查GPU利用率确定最优的CPU配置的一种 实现方式包括：基于所述任务的搜索初始点获取在当前CPU配置下的GPU利用率；对所述任务的搜索初始点进行减1循环操作，直到GPU利用率不再提升；对所述任务的搜索初始点进行加1循环操作，直到GPU利用率不再提升；输出GPU利用率不再提升时对应的CPU配 置即为最优的CPU配置。
搜索最优CPU配置即找到GPU任务获得最大GPU利用率的CPU配置。具体地，如图3所示，首先，根据确定的每个任务的搜索初始点，进行将任务进行预设时间(例如90秒)的运行，并检测该CPU配置下的GPU利用率。其次，尝试减少1个核，检查应用的GPU利用 率是否有提升，若有提升，则继续尝试减少一个核，直到找到最优的CPU核数；若没有提升， 则进入下一阶段。然后，尝试增加1个核，检查应用的GPU利用率是否有提升，若有提升， 则继续尝试增加一个核；若没有提升，则找到了最优的CPU核数。
本实施例执行GPU任务调度或CPU任务调度主要是解决GPU任务与CPU任务的CPU资源竞争问题和不同配置GPU任务之间的GPU资源竞争问题。
本实施例首先执行CPU任务调度，然后执行CPU任务调度。
步骤S400，对CPU资源划进行划分，并根据当前CPU任务队列和GPU任务队列的排队状况调整CPU资源队列。
于本实施例中，所述对CPU资源划进行划分包括：将CPU资源划分为CPU任务CPU 资源队列和GPU任务CPU资源队列；所述根据当前CPU任务队列和GPU任务队列的排队 状况调整CPU资源队列的一种方式包括：当CPU任务到来而GPU任务队列比较空闲时，则 允许CPU任务抢占GPU任务CPU资源队列中的CPU资源进行预先运算；当GPU任务到来 需要抢占所述GPU任务CPU资源队列中的CPU资源时，中止当前正在运行的CPU任务， 使得GPU任务可以运行；中止的CPU任务重新进入CPU任务CPU资源队列的队列头，等 待被重新被调度。
其中，于本实施例中，所述GPU任务CPU资源队列由历史GPU任务需求的最高CPU 资源确定。
本实施例的步骤S400，负责GPU任务与CPU任务的CPU资源划分与调整。具体地，如图 4所示，本实施例首先将任务划分为CPU任务与GPU任务，然后将CPU资源划分为CPU任 务CPU资源队列和GPU任务CPU资源队列，GPU任务CPU资源队列为为GPU任务预留的 CPU资源。相应资源队列的划分，由历史任务的统计信息决定。GPU资源队列由历史GPU 任务需求的最高CPU资源决定。对于CPU任务队列，本实施例采用DRF调度算法，根据用 户对CPU的使用进行调度。对于GPU任务队列，本实施例也采用DRF调度算法，根据用户 对GPU的使用进行调度，GPU任务的CPU使用则基于最优的CPU配置决定。
实际运行过程中，当CPU任务爆发式到来而GPU任务队列比较空闲时，则允许CPU任务抢占GPU任务CPU资源队列中的CPU资源进行预先运算。当GPU任务到来需要这些抢 占的CPU资源时，中止正在运行的CPU任务，使得GPU任务可以运行。而中止的CPU任 务重新进入队列头，等待被重新调度合适的节点上。相反，当GPU任务爆发式到来时，GPU 任务也可以抢占CPU资源队列的资源。
步骤S500，对GPU资源划进行划分，并根据当前GPU任务队列的排队状况调整GPU资源队列。
于本实施例中，所述对GPU资源划进行划分包括：将GPU任务划分为单GPU任务与多GPU任务，对应地将GPU资源划分为单GPU资源队列和多GPU资源队列；所述根据当前 GPU任务队列的排队状况调整GPU资源队列的一种方式包括：当多GPU资源队列中的GPU 被使用完而单GPU任务队列为空时，多GPU任务尝试抢占单GPU资源队列的GPU；当单 GPU资源队列的GPU被使用完而多GPU任务队列为空，单GPU任务尝试抢占多GPU资源 队列的GPU。
本实施例的步骤S500负责单GPU任务与多GPU任务的GPU资源划分与调整。首先将GPU任务划分为单GPU任务与多GPU任务，单GPU任务为申请小于4GPU的任务，多GPU 任务为申请大于等于4GPU的GPU任务。其次，将GPU资源划分为单GPU资源队列和多 GPU资源队列，对应于单GPU任务队列和多GPU任务队列。当多GPU资源队列中的GPU 被使用完而单GPU任务队列为空时，多GPU任务尝试抢占单GPU资源队列的GPU。相反， 当单GPU资源队列的GPU被使用完而多GPU任务队列为空，单GPU任务尝试抢占多GPU 资源队列的GPU。
步骤S600，消除GPU任务与CPU任务在同一个节点上的内存系统的竞争。
于本实施例中，所述消除GPU任务与CPU任务在同一个节点上的内存系统的竞争的一 种实现方式包括：监控所有进程带宽的使用情况；当CPU任务的带宽使用情况达到宽带预设 值，且该节点上GPU任务的GPU利用率降低预设值时，将该CPU任务的CPU使用核数压缩，且降低该CPU任务的带宽使用率。
具体地，步骤S600负责消除GPU任务与CPU任务在同一个节点上的内存系统的竞争。 因为CPU任务更加多样，任务的带宽使用是无法预测的，本实施例通过Intel MBM来监控所 有进程带宽的使用情况。当CPU任务的带宽使用情况达到75％以上，且该节点上GPU任务 的GPU利用率有相应的降低时，选择将该CPU任务的CPU使用核数压缩一半，降低该CPU任务的带宽使用率，进而减少对GPU任务的影响。而对于剩下的CPU核，在该GPU任务完 成之前，都不调度新的CPU任务上去。
为使本领域技术人员进一步理解本实施例的资源需求感知的多队列调度方法，如图4所 示，对本实施例的资源需求感知的多队列调度方法的具体执行流程进行说明。
1)用户提交任务：用户通过调用相应的API，按照需求编写自己的程序。
2)判断任务类型：若任务为CPU任务，则调度到CPU任务队列，若任务为GPU任务，则调度到GPU任务队列。
3)CPU任务调度：根据任务申请的CPU数和CPU任务CPU资源队列中可用的资源来调度CPU任务。
4)确定GPU任务的搜索初始点：根据任务的相关信息决定该任务的最优CPU配置搜索 的初始点。
5)搜索该GPU任务的最优CPU配置：按照搜索最优CPU配置子模块设计的流程进行最优CPU配置的搜索。
6)GPU任务调度：根据任务申请的GPU数和GPU资源队列中可用的资源来调度GPU任务。
7)CPU资源队列的动态调整：按照当前CPU任务队列和GPU任务队列的排队状况，实时决定是否需要调整CPU资源的划分。
8)GPU资源队列的动态调整：按照当前单GPU任务队列和多GPU任务队列的排队状况，实时决定是否需要调整GPU资源的划分
9)实时的CPU端资源竞争消除：消除GPU任务与CPU任务在同一个节点上的内存系统的竞争。通过监控CPU任务使用的内存带宽。当CPU任务使用的带宽超过一定的阈值后，限制该任务使用的CPU核数，以减少CPU任务对带宽的需求。
10)任务执行：任务开始在相应节点上进行执行，执行完毕后返回实验结果。
所以本实施例的资源需求感知的多队列调度方法可以有效控制CPU任务与GPU任务的 资源任务调度、提高吞吐减少排队的资源需求，在无需用户感知的前提下，最大化系统的吞 吐和最小化系统的排队。
实施例2
如图5所示，本实施例提供一种资源需求感知的多队列调度系统100，所述资源需求感 知的多队列调度系统100包括：自感知的CPU分配模块110，多队列的资源调整模块120以 及实时的竞争消除模块130。
具体地，于本实施例中，如图6所示，所述自感知的CPU分配模块110用于将获取用户 提交的任务，判断任务为CPU任务或GPU任务，并在任务为GPU任务时，基于调整CPU 核数并检查GPU利用率确定最优的CPU配置，进入GPU任务任务调度。
所述自感知的CPU分配模块110包括初始点搜索单元和最优CPU配置单元。
所述初始点搜索单元基于历史信息获取CPU搜索初始点；根据用户提供的流水线信息、 权重信息和CPU计算复杂度中的一个或多个确定对所述CPU搜索初始点的增减；增减之后 的CPU搜索初始点形成任务的搜索初始点。
其中，所述根据用户提供的流水线信息、权重信息和CPU计算复杂度中的一个或多个确 定对所述CPU搜索初始点的增减中：若用户提交的任务中包含有流水线信息，且使用了流水 线优化，则对所述CPU搜索初始点进行减1操作；若用户提交的任务中包含有权重信息，且 权重达到预设权重值，则对所述CPU搜索初始点进行减1操作；若用户提交的任务中包含有 CPU端计算复杂度，且CPU计算复杂度达到预设复杂度，则对所述CPU搜索初始点进行加 1操作。
具体地，首先通过历史信息获得一个CPU搜索初始点，然后，若用户提供了流水线信息， 且使用了流水线优化，则相应的CPU搜索初始点减1；若用户提供了权重信息，且权重较多， 则相应的CPU搜索初始点减1；若用户提供了CPU端计算复杂度，且CPU计算复杂度较高， 则CPU搜索初始点加1；由此确定了每个任务的搜索初始点。
所述最优CPU配置单元基于所述任务的搜索初始点获取在当前CPU配置下的GPU利用 率；对所述任务的搜索初始点进行减1循环操作，直到GPU利用率不再提升，对所述任务的 搜索初始点进行加1循环操作，直到GPU利用率不再提升，输出GPU利用率不再提升时对应的CPU配置即为最优的CPU配置。
具体地，首先，根据确定的每个任务的搜索初始点，进行将任务进行预设时间(例如90 秒)的运行，并检测该CPU配置下的GPU利用率。其次，尝试减少1个核，检查应用的GPU利用率是否有提升，若有提升，则继续尝试减少一个核，直到找到最优的CPU核数；若没有提升，则进入下一阶段。然后，尝试增加1个核，检查应用的GPU利用率是否有提升，若有 提升，则继续尝试增加一个核；若没有提升，则找到了最优的CPU核数。
于本实施例中，如图6所示，所述多队列的资源调整模块120用于执行GPU任务调度或 CPU任务调度。所述多队列的资源调整模块120包括CPU资源调整单元和GPU资源调整单元。
所述CPU资源调整单元对CPU资源划进行划分，并根据当前CPU任务队列和GPU任务队列的排队状况调整CPU资源队列。
所述CPU资源调整单元负责GPU任务与CPU任务的CPU资源划分与调整。具体地，所述 多队列的资源调整模块120首先将任务划分为CPU任务与GPU任务，然后将CPU资源划分为CPU任务CPU资源队列和GPU任务CPU资源队列，GPU任务CPU资源队列为为GPU 任务预留的CPU资源。相应资源队列的划分，由历史任务的统计信息决定。GPU资源队列 由历史GPU任务需求的最高CPU资源决定。对于CPU任务队列，所述CPU资源调整单元 采用DRF调度算法，根据用户对CPU的使用进行调度。对于GPU任务队列，所述CPU资 源调整单元也采用DRF调度算法，根据用户对GPU的使用进行调度，GPU任务的CPU使用 则基于最优的CPU配置决定。
实际运行过程中，当CPU任务爆发式到来而GPU任务队列比较空闲时，则允许CPU任务抢占GPU任务CPU资源队列中的CPU资源进行预先运算。当GPU任务到来需要这些抢 占的CPU资源时，中止正在运行的CPU任务，使得GPU任务可以运行。而中止的CPU任 务重新进入队列头，等待被重新调度合适的节点上。相反，当GPU任务爆发式到来时，GPU 任务也可以抢占CPU资源队列的资源。
所述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资源调整单元负责单GPU任务与多GPU任务的GPU资源划分与调整。首先将GPU任务划分为单GPU任务与多GPU任务，单GPU任务为申请小于4GPU 的任务，多GPU任务为申请大于等于4GPU的GPU任务。其次，将GPU资源划分为单GPU 资源队列和多GPU资源队列，对应于单GPU任务队列和多GPU任务队列。当多GPU资源 队列中的GPU被使用完而单GPU任务队列为空时，多GPU任务尝试抢占单GPU资源队列 的GPU。相反，当单GPU资源队列的GPU被使用完而多GPU任务队列为空，单GPU任务 尝试抢占多GPU资源队列的GPU。
于本实施例中，所述实时的竞争消除模块130用于消除GPU任务与CPU任务在同一个 节点上的内存系统的竞争。
具体地，于本实施例中，如图6所示，所述实时的竞争消除模块130监控所有进程带宽 的使用情况；当CPU任务的带宽使用情况达到宽带预设值，且该节点上GPU任务的GPU利用率降低预设值时，将该CPU任务的CPU使用核数压缩，且降低该CPU任务的带宽使用率。
于本实施例中，所述实时的竞争消除模块130负责消除GPU任务与CPU任务在同一个 节点上的内存系统的竞争。因为CPU任务更加多样，任务的带宽使用是无法预测的，本实施 例通过Intel MBM来监控所有进程带宽的使用情况。当CPU任务的带宽使用情况达到75％以 上，且该节点上GPU任务的GPU利用率有相应的降低时，选择将该CPU任务的CPU使用核数压缩一半，降低该CPU任务的带宽使用率，进而减少对GPU任务的影响。而对于剩下 的CPU核，在该GPU任务完成之前，都不调度新的CPU任务上去。
实施例3
本实施例提供本发明的实施例还提供一种服务器，所述服务器为集群中的服务器，所述 服务器包括CPU和GPU；所述CPU和所述GPU运行时执行如实施例1所述的资源需求感知 的多队列调度方法。实施例1中已经对资源需求感知的多队列调度方法进行了详细说明，在 此不再赘述。
综上所述，本发明可以有效控制CPU任务与GPU任务的资源任务调度、提高吞吐减少 排队的资源需求，在无需用户感知的前提下，最大化系统的吞吐和最小化系统的排队，可以 间接为潜在的异构集群提供调度技术的支持，为基于异构集群的云环境提供任务调度服务。 所以，本发明有效克服了现有技术中的种种缺点而具高度产业利用价值。
上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技 术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡 所属技术领域中包括通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等 效修饰或改变，仍应由本发明的权利要求所涵盖。
