CN114048026A - 一种多任务并发情况下gpu资源动态分配方法 - Google Patents

一种多任务并发情况下gpu资源动态分配方法 Download PDF

Info

Publication number
CN114048026A
CN114048026A CN202111258248.4A CN202111258248A CN114048026A CN 114048026 A CN114048026 A CN 114048026A CN 202111258248 A CN202111258248 A CN 202111258248A CN 114048026 A CN114048026 A CN 114048026A
Authority
CN
China
Prior art keywords
gpu
program
kernel
worker
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202111258248.4A
Other languages
English (en)
Inventor
肖利民
常佳辉
秦广军
朱乃威
徐向荣
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beihang University
Original Assignee
Beihang University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beihang University filed Critical Beihang University
Priority to CN202111258248.4A priority Critical patent/CN114048026A/zh
Publication of CN114048026A publication Critical patent/CN114048026A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Multi Processors (AREA)

Abstract

本发明提供一种多任务情况下GPU资源的动态分配方法，以解决NVIDIA GPU多任务并发时，采用静态资源分配方法造成的大量资源空闲，***吞吐率下降，资源分配不合理的问题，具有三个明显的特征：(1)可配置性，原生GPU环境无法自主配置程序运行时占用的资源量，本***提出了一种软件的方法，在不修改任何硬件、驱动细节的情况下，实现了GPU程序运行时资源使用量的可配置性；(2)高效性，本方法考虑任务对不同种类资源的亲和性，将资源需求互补的任务并发执行，提高GPU资源的使用效率，加快多任务处理；(3)易用性，本方法提供了简易的程序转换模式，开发者只需要采用固定的操作步骤，即可将原生程序迁移至本***下运行。

Description

一种多任务并发情况下GPU资源动态分配方法
技术领域：
本发明公开了一种多任务情况下GPU资源的动态分配方法，涉及高性能计算面临的挑战，属于计算机技术领域。
背景技术：
GPU作为拥有大量计算核心，能提供高速并行计算的设备，其用途早已超出图形计算和渲染的范畴而广泛应用于高性能计算、海量数据处理和人工智能等大规模的并行计算。作为新兴的异构计算平台，许多编程框架对其提供了支持，包括英伟达提出的CUDA编程模型，以及被众多厂商支持的OpenCL编程语言。虽然现在已有针对GPU设备的高效开发编程模型，然而在运行时由于GPU驱动采用的leftover资源分配策略大大损坏了GPU设备在多任务情况下的并行性。即使开发人员编写出了合理、高性能的GPU处理程序，在多任务并发下，由于驱动程序不够智能的调度策略，会直接导致GPU资源利用不充分，进而导致GPU加速效果的不明显，甚至失效。如何设计并实现一个智能的，能够针对负载特征做出调度决策的多任务并发平台，是当前使用GPU做高性能计算需要解决的重点。
为了解决多任务情况下GPU资源分配不合理的问题，近些年出现了不少解决的方法：
1)Hyper-Q技术：在nvidiaFermi架构时GPU就已经支持基础的空间复用了，用户可以指定哪些Kernel是无关的，可以同时运行的，GPU在任务调度时会尽量将剩余资源分配给其他可并行的Kernel。Kepler架构进一步提高了GPU并行多个Kernel的支持，它通过设置多个相互无依赖关系的Kernel队列，当一个队列中的任务没有占用全部的GPU资源时，GPU将另一队列中的任务调入GPU。这样的Kernel队列技术叫做Hyper-Q技术，CPU上的每一个核都可以提交一个GPU任务队列，在GPU运行时从多个并列的队列上选择可并行Kernel进行运算。与Fermi架构不同的是，Kepler架构真实地支持多个队列并发调度，而Fermi架构是在编译时将多个队列合并成一个执行队列，对上提供一个伪并发的效果。
2)MPS技术：MPS是英伟达公司开发的一个GPU多任务并发运行框架。Hyper-Q解决了GPU硬件上的并发问题，而MPS解决软件上多进程的并发问题。MPS通过C-S架构将多个进程的CUDA上下文映射到同一个CUDA上下文，但是任务调度模式封闭于GPU driver内部，不允许开发者针对需求进行修改。
3)GPU-Sim：GPU-Sim是一个开源的GPU模拟器，他能模拟一个GPU的工作过程。研究者可以通过修改GPU-Sim的源代码从而实现自己对GPU硬件或调度策略的改进。许多研究人员基于GPU-Sim研究了基于硬件的GPU调度方法，例如在运行过程中尝试不同资源配比时SM的吞吐量，从而修改两个kernel占用的资源量；使用共享内存和L1 cache做GPU上下文的快速切换等等。这些方法的实验验证都通过GPU-Sim得出模拟结果，然而现实GPU并不存在对应的硬件功能，其实验展示的资源分配和调度策略并不能真实的用于生产环境中。
现有的GPU多任务并发支持以及资源分配策略没有从高效性和可行性两个角度出发解决多任务并发情况下的GPU资源调度。MPS与Hyper-Q存在严重的资源浪费，而基于GPU-Sim做的硬件改造没有现实中的GPU设备支持，无法真实解决多任务并发情况下的GPU资源浪费的问题。
具体而言，现有的多任务GPU并发存在的问题在于：没有较有效的GPU可控GPU资源分配方法，运行时无法针对任务负载特征做智能资源分配选择，导致GPU资源浪费严重，无法发挥并行计算的最大能力。
发明内容：
本发明的主要目的是提供一种多任务情况下GPU资源的动态分配方法，以解决NVIDIA GPU多任务并发时，采用静态资源分配方法造成的大量资源空闲，***吞吐率下降，资源分配不合理的问题，具有三个明显的特征：(1)可配置性，原生GPU环境无法自主配置程序运行时占用的资源量，本***提出了一种软件的方法，在不修改任何硬件、驱动细节的情况下，实现了GPU程序运行时资源使用量的可配置性；(2)高效性，本方法考虑任务对不同种类资源的亲和性，将资源需求互补的任务并发执行，提高GPU资源的使用效率，加快多任务处理；(3)易用性，本方法提供了简易的程序转换模式，开发者只需要采用固定的操作步骤，即可将原生程序迁移至本***下运行。
本发明的技术方案是：
一种多任务情况下GPU资源的动态分配方法，首先通过一个固定的源码修改模式，将控制代码段***CUDA程序，使得程序运行时占用的资源量可控制。然后将CUDA程序的运行模式修改成C/S架构，客户端为一套自实现的CUDAAPI，替换原主机程序中的CUDAAPI。服务端采用一个后端进程接收来自不同客户端的CUDA调用，并将调用进行排队处理。最后服务端进行资源使用量的动态调控，服务端遍历CUDA请求队列，将计算任务放在GPU上执行，当队首的任务与正在运行的任务资源需求互补时，服务端动态缩减正在运行的任务占用的资源量，并启动等待中的任务，实现并发处理。
包括以下步骤，具体如下：
1)修改GPU程序，***具有控制程序资源使用量的代码段，将cuda程序中动态分配的block变成worker，循环拉取block执行。
2)对GPU程序采样，运行GPU程序一段时间，保证GPU资源全部被占用，并且持续一段时间，获取此时间段GPU程序执行的总指令数量以及获取全部内存指令的数量。
3)使用Json格式文本保存GPU程序采样数据，以及占用寄存器、共享内存数量；
4)程序编译时，替换原生CUDAAPI，并链接本***实现的CUDAAPI库。本***实现的CUDAAPI库会将CUDA请求通过socket发送给服务端。
5)服务端为每个活跃客户端连接创建一个线程，线程保存CUDA任务队列。
6)启动kernel前，在GPU显存上开辟一块空间，保存程序运行时的资源分配配置。程序运行时，控制代码段控制GPU使用的资源量。
7)当有两个及以上GPU程序需要运行时，通过对比样本数据，计算最优分配方法，设置GPU显存上的配置数据，运行kernel。
8)当有GPU任务运行完成后，通知服务端，服务端选择从队列中拉取新的任务再并发执行，或者扩容正在运行的GPU程序。
其中，步骤1)包括以下步骤：
步骤(1.1)开发人员在GPU代码段增加一处全局内存的使用声明，此全局内存即保存在显存上的配置，及以完成工作量，运行中的kernel线程可并发读；
步骤(1.2)***控制代码段，该代码段在程序启动时立刻执行，判断自身所处的SM编号，并设置自己的worker编号；
步骤(1.3)复制一份源程序副本，替换源程序中的blockIdx变量和gridDim变量；
步骤(1.4)worker循环拉取block执行，直到全部任务执行完成；
其中，步骤2)包括以下步骤：
步骤(2.1)设置合适规模数据，使kernel程序可以占据全部GPU资源，并持续运行1ms以上；
步骤(2.2)使用nvprof运行测试程序，输出该程序指令执行总量，以及全局内存存取指令数量；
其中，步骤3)包括以下步骤：
步骤(3.1)使用nvvp运行测试程序，记录kernel一个线程占用的寄存器数量以及一个block占用的共享内存数量；
步骤(3.2)使用json格式文本保存程序样本数据，包含四个字段：采样全局内存存取指令数量；采样总指令数量；寄存器数量；共享内存数量；
步骤(3.3)服务端初始化时读取该配置文件；
其中，步骤4)包括以下步骤：
步骤(4.1)修改GPU程序编译时链接的cudaapi库路径，指向本***的cudaapi实现；
步骤(4.2)替换源程序中的cuda头文件，修改为本***的cudaapi头文件；
步骤(4.3)将源程序中以三重尖括号调用kernel程序的方式修改为使用cudaLaunchKernel接口调用；
步骤(4.4)源程序中的cudaapi调用全部会转到本***实现的cudaapi；
步骤(4.5)本***实现的cudaapi库在初始化时，首先尝试连接cudaapi服务端，若服务端未开启则通知用户开启服务端再运行；
步骤(4.6)cudaapi库连接成功后，服务端会创建一个线程用于处理新连接的api客户端；
其中，步骤5)包括以下步骤：
步骤(5.1)服务端监听一个socket文件，等待客户端的连接；
步骤(5.2)客户端通过socket与服务端建立连接，并使用规定消息格式传递cuda调用请求；
步骤(5.3)服务端接受到客户端连接请求后，开辟一个新的线程与该客户端连接；
步骤(5.4)服务端为每个客户端建立一个任务队列；
其中，步骤6)包括以下步骤：
步骤(6.1)服务端启动kernel前，在GPU显存上分配一块全局内存，保存kernel可占用的SM编号、每个SM上可并存的最大worker数量、当前每个SM上已存在的worker数量、已完成block数量、全部block数量、kernel的GridDim；
步骤(6.2)服务端启动kernel，分配到SM上的block会变成worker，worker循环拉取block执行；
步骤(6.3)worker初始化时，首先检查身处的sm_id，以及该sm上能存在的最大worker数量。当该worker超过限制时会直接退出，未超出限制时会持续存在设备上；
步骤(6.4)持续存在设备上的worker包含一个循环体，每次循环会拉取一个block；
步骤(6.5)worker计算该block的blockIdx，传入步骤(1.3)中说明的源程序副本，执行副本程序；
步骤(6.6)block执行完成后，worker检查任务是否已全部完成，若已完成worker会退出执行，否则进入下一轮循环；
其中，步骤7)包括以下步骤：
步骤(7.1)服务端计算运行中kernel的内存指令比，即采样数据中的全局内存指令数量除以指令总量；
步骤(7.2)计算待运行kernel的内存指令比；
步骤(7.3)根据采样数据中的寄存器字段和共享内存字段，得出两个kernel配对运行的所有资源分配组合；
步骤(7.4)若组合中存在一种情况，两个kernel并发运行时，***内存指令比接近0.05，则按照该配置进行并发运行；
步骤(7.5)若所有组合的***内存指令比均大于0.055或小于0.045，则不进行并发运行；
其中，步骤8)包括以下步骤：
步骤(8.1)服务端检查任务队列，若存在可运行任务则再进行步骤(7)，若队列为空，则进入步骤(8.2)；
步骤(8.2)服务端更新运行中的kernel配置，使其占据全部资源；
步骤(8.3)读取kernel的运行时配置，若剩余存活worker满足资源配置，则保持原状继续运行；若剩余存活worker少于配置，则进入步骤(8.4)
步骤(8.4)启动该kernel新实例，与原实例共享配置，使***上该kernel的活跃worker数达到配置的要求；
本发明的优点包括：
本发明所提出的一种多任务情况下GPU资源的动态分配方法，与现有技术相比，其优点是：
针对NVIDIAGPU多任务并发时，采用静态资源分配方法造成的大量资源空闲，***吞吐率下降，资源分配不合理的问题，提出了一种高效的GPU多任务运行时***，该***具备三个明显的特征：(1)可配置性，原生GPU环境无法自主配置程序运行时占用的资源量，本***提出了一种软件的方法，在不修改任何硬件、驱动细节的情况下，实现了GPU程序运行时资源使用量的可配置性。(2)高效性，本方法考虑任务对不同种类资源的亲和性，将资源需求互补的任务并发执行，提高GPU资源的使用效率，加快多任务处理。(3)易用性，本方法提供了简易的程序转换模式，开发者只需要采用固定的操作步骤，即可将原生程序迁移至本***下运行。
附图说明：
图1是实施本发明一种多任务并发情况下GPU资源动态分配方法的流程示意图。
图2是GPU资源配置数据结构图。
图3是worker执行模式示意图。
图4是GPU多任务并发执行***结构图。
图5是启动kernel流程图。
图6是动态资源分配流程图。
具体实施方式：
以下结合附图对本发明作进一步详细的说明。
如图1所示，是GPU程序运行时资源配置数据结构图。该配置由32位，4Byte的固定资源限制段以及不定长度的运行状态段组成。固定资源限制段前2Byte表明每个SM上能运行的最大worker数量，第3个和第4个字节分别表明可以使用的SM编号上限和SM编号下限；运行状态段前三个字段保存该kernel的Grid维度，之后的首个字段“已完成block数量”记录当前已完成的block数量，第2个字段为该任务需要完成的block总量；从第3个字段开始，保存的内容为编号为0,1,2,…n的SM上活跃worker的数量，该字段的条目数量与GPU硬件的SM数量一致，记录kernel在每个SM上活跃的worker数量；在kernel初始化时，***首先为其分配一块GPU内存，保存图1所示的运行时配置，该配置的生命周期与kernel运行时长相同；
Worker的执行流程如图2所示，当一个block被分配到SM上之后变成worker。Worker首先通过PTX汇编代码获取当前SMid以及worker编号，同时通过原子操作将活跃worker数加一；worker读取图1中的运行时配置，比较SMid和配置中的上下限，workerid和配置中的worker上限，判断该worker是否超出配置限制。若超出SM或worker限制，则该worker退出，且将活跃worker数减一；若未超出配置限制，则拉取未完成block，并将已完成block数量加一，比较该block编号和block总量，若编号超出block总量，则worker退出，并将活跃worker数减一；若编号未超出block总量，则根据配置中的GridDIM计算blockIdx并调用源程序副本。源程序副本退出后，worker拉取下一个未执行的block，并重复以上过程，直到已完成的block数量超过block总量。
GPU多任务并发执行***结构图如图3所示，***总体架构分为客户端和服务端，客户端由cudaapi和GPU程序组成，该***支持多个GPU程序并发执行。cudaapi底层使用了IPC库和服务端通信。服务端支持多客户端的并发连接，其中receiver模块为每个客户端连接建立一个线程，用于处理一个客户端的全部cuda请求。客户端的cuda请求会被放入统一的Commandlists中，服务端的scheduler模块会轮询commandlist中的cuda请求，在做出决策结果后scheduler会启动一个APIconductor用于执行真实的cuda任务。Device模块保存了当前设备的计算能力和资源总量，以及正在运行的kernel和它占用的资源量。Scheduler做调度决策时，会调用Device模块以获取设备当前最新状态。
一个kernel的启动流程图如图4所示，启动kernel前调度器会检查当前设备是否空闲，当设备完全空闲时，调度器会设置kernel完全占据GPU资源。如果设备不空闲，调度器会检查当前设备只运行着一个kernel还是两个kernel，如果当前设备被两个kernel占据，那么待调度的kernel会阻塞等待GPU上的任务释放资源。如果当前设备被一个kernel占据，调度器会计算当前kernel与正在运行的kernel的内存指令比，如果存在接近0.05的组合则会设置该运行时配置，并保存在GPU上。如果不存在这样的组合，待调度的kernel则进入阻塞状态。当调度器决定待调度的kernel可以运行在GPU上时，它会先设置运行时配置，然后启动kernel。当kernel完成后，它会释放占用的GPU资源并通知调度器，调度器会选择唤醒原本阻塞的kernel，或者从等待队列中拉取新的kernel进行调度。
图5展示GPU资源的动态调度过程，初始状态GPU上存在一个正在运行的kernel，当调度器调度新的任务时，会首先计算不同组合的内存指令比，如果存在内存指令在0.045-0.055范围内的组合，则会设置并发执行，如果不存在这样的组合，调度器会阻塞新调度的任务，等待已有的kernel释放资源。如果调度器设置了并发执行，它首先会设置GPU上kernel的运行时配置，造成正在运行的kernel占用资源的减少。然后调度器会启动新的任务，两个任务会持续并发执行。若原先的kernel先执行完成，它会释放资源并通知调度器。若后来的kernel先执行完成，它会先检查是否有阻塞的任务等待调度，若存在阻塞的任务，则kernel会立刻释放资源，并通知调度器。若不存在阻塞的任务，调度器会使原先的kernel重新占据全部GPU资源。调度器首先读取该kernel保存在GPU上的运行时配置，若活跃worker数量少于最大限制，则调度器会启用该kernel的备用kernel，来提高GPU上的活跃worker数量。若活跃worker数量本就满足最大限制，则调度器什么也不做。等待该kernel执行完成后会释放资源，并通知调度器，调度器会进入新的一轮任务调度。
最后所应说明的是：本发明还可有其它多种应用场景，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明做出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明的保护范围。

Claims (10)

1.一种多任务情况下GPU资源的动态分配方法，首先通过一个固定的源码修改模式，将控制代码段***CUDA程序，使得程序运行时占用的资源量可控制，然后将CUDA程序的运行模式修改成C/S架构，客户端为一套自实现的CUDA API，替换原主机程序中的CUDA API，服务端采用一个后端进程接收来自不同客户端的CUDA调用，并将调用进行排队处理，最后服务端进行资源使用量的动态调控，服务端遍历CUDA请求队列，将计算任务放在GPU上执行，当队首的任务与正在运行的任务资源需求互补时，服务端动态缩减正在运行的任务占用的资源量，并启动等待中的任务，实现并发处理。
2.根据权利要求1所述的方法，其特征在于，包括以下步骤：
包括以下步骤，具体如下：
1)修改GPU程序，***具有控制程序资源使用量的代码段，将cuda程序中动态分配的block变成worker，循环拉取block执行；
2)对GPU程序采样，运行GPU程序一段时间，保证GPU资源全部被占用，并且持续一段时间，获取此时间段GPU程序执行的总指令数量以及获取全部内存指令的数量；
3)使用Json格式文本保存GPU程序采样数据，以及占用寄存器、共享内存数量；
4)程序编译时，替换原生CUDAAPI，并链接本***实现的CUDAAPI库。本***实现的CUDAAPI库会将CUDA请求通过socket发送给服务端；
5)服务端为每个活跃客户端连接创建一个线程，线程保存CUDA任务队列；
6)启动kernel前，在GPU显存上开辟一块空间，保存程序运行时的资源分配配置。程序运行时，控制代码段控制GPU使用的资源量；
7)当有两个及以上GPU程序需要运行时，通过对比样本数据，计算最优分配方法，设置GPU显存上的配置数据，运行kernel；
8)当有GPU任务运行完成后，通知服务端，服务端选择从队列中拉取新的任务再并发执行，或者扩容正在运行的GPU程序。
3.根据权利要求2所述的方法，其特征在于，所述步骤1)包括以下步骤：
步骤(1.1)开发人员在GPU代码段增加一处全局内存的使用声明，此全局内存即保存在显存上的配置，及以完成工作量，运行中的kernel线程可并发读；
步骤(1.2)***控制代码段，该代码段在程序启动时立刻执行，判断自身所处的SM编号，并设置自己的worker编号；
步骤(1.3)复制一份源程序副本，替换源程序中的blockIdx变量和gridDim变量；
步骤(1.4)worker循环拉取block执行，直到全部任务执行完成。
4.根据权利要求2所述的方法，其特征在于，所述步骤2)包括以下步骤：
步骤(2.1)设置合适规模数据，使kernel程序可以占据全部GPU资源，并持续运行1ms以上；
步骤(2.2)使用nvprof运行测试程序，输出该程序指令执行总量，以及全局内存存取指令数量。
5.根据权利要求2所述的方法，其特征在于，所述步骤3)包括以下步骤：
步骤(3.1)使用nvvp运行测试程序，记录kernel一个线程占用的寄存器数量以及一个block占用的共享内存数量；
步骤(3.2)使用json格式文本保存程序样本数据，包含四个字段：采样全局内存存取指令数量；采样总指令数量；寄存器数量；共享内存数量；
步骤(3.3)服务端初始化时读取该配置文件。
6.根据权利要求2所述的方法，其特征在于，所述步骤4)包括以下步骤：
步骤(4.1)修改GPU程序编译时链接的cudaapi库路径，指向本***的cudaapi实现；
步骤(4.2)替换源程序中的cuda头文件，修改为本***的cudaapi头文件；
步骤(4.3)将源程序中以三重尖括号调用kernel程序的方式修改为使用cudaLaunchKernel接口调用；
步骤(4.4)源程序中的cudaapi调用全部会转到本***实现的cudaapi；
步骤(4.5)本***实现的cudaapi库在初始化时，首先尝试连接cudaapi服务端，若服务端未开启则通知用户开启服务端再运行；
步骤(4.6)cudaapi库连接成功后，服务端会创建一个线程用于处理新连接的api客户端。
7.根据权利要求2所述的方法，其特征在于，所述步骤5)包括以下步骤：
步骤(5.1)服务端监听一个socket文件，等待客户端的连接；
步骤(5.2)客户端通过socket与服务端建立连接，并使用规定消息格式传递cuda调用请求；
步骤(5.3)服务端接受到客户端连接请求后，开辟一个新的线程与该客户端连接；
步骤(5.4)服务端为每个客户端建立一个任务队列。
8.根据权利要求2所述的方法，其特征在于，所述步骤6)包括以下步骤：
步骤(6.1)服务端启动kernel前，在GPU显存上分配一块全局内存，保存kernel可占用的SM编号、每个SM上可并存的最大worker数量、当前每个SM上已存在的worker数量、已完成block数量、全部block数量、kernel的GridDim；
步骤(6.2)服务端启动kernel，分配到SM上的block会变成worker，worker循环拉取block执行；
步骤(6.3)worker初始化时，首先检查身处的sm_id，以及该sm上能存在的最大worker数量。当该worker超过限制时会直接退出，未超出限制时会持续存在设备上；
步骤(6.4)持续存在设备上的worker包含一个循环体，每次循环会拉取一个block；
步骤(6.5)worker计算该block的blockIdx，传入步骤(1.3)中说明的源程序副本，执行副本程序；
步骤(6.6)block执行完成后，worker检查任务是否已全部完成，若已完成worker会退出执行，否则进入下一轮循环。
9.根据权利要求2所述的方法，其特征在于，所述步骤7)包括以下步骤：
步骤(7.1)服务端计算运行中kernel的内存指令比，即采样数据中的全局内存指令数量除以指令总量；
步骤(7.2)计算待运行kernel的内存指令比；
步骤(7.3)根据采样数据中的寄存器字段和共享内存字段，得出两个kernel配对运行的所有资源分配组合；
步骤(7.4)若组合中存在一种情况，两个kernel并发运行时，***内存指令比接近0.05，则按照该配置进行并发运行；
步骤(7.5)若所有组合的***内存指令比均大于0.055或小于0.045，则不进行并发运行。
10.根据权利要求2所述的方法，其特征在于，所述步骤8)包括以下步骤：
步骤(8.1)服务端检查任务队列，若存在可运行任务则再进行步骤(7)，若队列为空，则进入步骤(8.2)；
步骤(8.2)服务端更新运行中的kernel配置，使其占据全部资源；
步骤(8.3)读取kernel的运行时配置，若剩余存活worker满足资源配置，则保持原状继续运行；若剩余存活worker少于配置，则进入步骤(8.4)
步骤(8.4)启动该kernel新实例，与原实例共享配置，使***上该kernel的活跃worker数达到配置的要求。
CN202111258248.4A 2021-10-27 2021-10-27 一种多任务并发情况下gpu资源动态分配方法 Pending CN114048026A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111258248.4A CN114048026A (zh) 2021-10-27 2021-10-27 一种多任务并发情况下gpu资源动态分配方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111258248.4A CN114048026A (zh) 2021-10-27 2021-10-27 一种多任务并发情况下gpu资源动态分配方法

Publications (1)

Publication Number Publication Date
CN114048026A true CN114048026A (zh) 2022-02-15

Family

ID=80206147

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111258248.4A Pending CN114048026A (zh) 2021-10-27 2021-10-27 一种多任务并发情况下gpu资源动态分配方法

Country Status (1)

Country Link
CN (1) CN114048026A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115718665A (zh) * 2023-01-10 2023-02-28 北京卡普拉科技有限公司 异步i/o线程处理器资源调度控制方法、装置、介质及设备

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115718665A (zh) * 2023-01-10 2023-02-28 北京卡普拉科技有限公司 异步i/o线程处理器资源调度控制方法、装置、介质及设备

Similar Documents

Publication Publication Date Title
Wang et al. Simultaneous multikernel GPU: Multi-tasking throughput processors via fine-grained sharing
US9274832B2 (en) Method and electronic device for thread scheduling
JP5367816B2 (ja) オペレーションの保護モードスケジューリング
EP3425502A1 (en) Task scheduling method and device
KR20050000487A (ko) 스케줄링 방법 및 실시간 처리시스템
KR20170116439A (ko) 태스크 스케줄링 방법 및 장치
KR20050004688A (ko) 스케줄링 방법 및 정보처리시스템
KR20090061177A (ko) 동적 로드 밸런싱을 지원하는 멀티 쓰레딩 프레임워크 및이를 이용한 프로세싱 방법
Margiolas et al. Portable and transparent software managed scheduling on accelerators for fair resource sharing
Calandrino et al. Soft real-time scheduling on performance asymmetric multicore platforms
CN111209046A (zh) 一种面向多任务处理的嵌入式sparc处理器操作***设计方法
Siavashi et al. GPUCloudSim: an extension of CloudSim for modeling and simulation of GPUs in cloud data centers
CN104090826B (zh) 基于相关性的任务优化部署方法
CN114048026A (zh) 一种多任务并发情况下gpu资源动态分配方法
Suo et al. Preserving i/o prioritization in virtualized oses
CN101976201A (zh) 基于cpu亲和力的虚拟cpu动态绑定方法
Marau et al. Performing flexible control on low-cost microcontrollers using a minimal real-time kernel
CN112860396A (zh) 一种基于分布式深度学习的gpu调度方法及***
Ino et al. Cooperative multitasking for GPU‐accelerated grid systems
Baek et al. CARSS: Client-aware resource sharing and scheduling for heterogeneous applications
CN116225688A (zh) 一种基于gpu指令转发的多核协同渲染处理方法
CN111124691B (zh) 多进程共享的gpu调度方法、***及电子设备
Elrad Comprehensive race control: A versatile scheduling mechanism for real-time applications
Beronić et al. On Analyzing Virtual Threads–a Structured Concurrency Model for Scalable Applications on the JVM
Zerzelidis et al. Getting more flexible scheduling in the rtsj

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination