KR102001641B1 - Method and apparatus for managing gpu resource in virtualization environment - Google Patents

Abstract

A GPU (Graphics Processing Unit) resource management method in a virtualization environment according to the present invention includes the steps of a host OS receiving a graphic processing command request from at least one guest OS of a plurality of guest OSs, Determining whether to allocate GPU resources to the guest OS based on a graphics processing instruction request, and delivering the graphics processing command request to the GPU according to the determination result.

Description

[0001] METHOD AND APPARATUS FOR MANAGING GPU RESOURCE IN VIRTUALIZATION ENVIRONMENT [0002]

The present invention relates to a method and apparatus for managing GPU resources in a virtualized environment.

The Graphics Processing Unit (GPU) is an important device used in all areas of high-performance computing (HPC) such as molecular simulation, financial engineering, cloud gaming, and 2D / 3D graphics operations. In particular, a compute node with a GPU in a cloud environment provides users with high energy and resource efficiency while reducing operating costs. Virtualization technology is required to operate the GPU at a low cost while providing high efficiency, and high utilization can be achieved through GPU operation using this virtualization. Therefore, it provides a virtualization method that can more efficiently and flexibly manage GPU resources than the GPU virtualization method currently used in most public clouds, thereby providing resource efficiency and cost savings to both cloud service providers and users And the like.

The present invention provides a method and apparatus for managing GPU resources in a virtualized environment that efficiently distributes a GPU to a plurality of virtual machines without depending on specific hardware.

A GPU (Graphics Processing Unit) resource management method in a virtualization environment according to an embodiment of the present invention includes a step of a host OS receiving a graphic processing command request from at least one guest OS of a plurality of guest OSs, The host OS determining whether to allocate GPU resources to the guest OS based on the graphics processing command request, and delivering the graphics processing command request to the GPU according to the determination result .

In one embodiment, the step of determining whether or not to allocate the GPU resource may include the steps of: when the graphic processing command request performs parallel computing processing, if the host OS determines that the time quota of the guest OS is greater than a predetermined condition And determining whether or not it satisfies a predetermined condition.

In one embodiment, the step of determining whether or not to allocate the GPU resource includes: allocating a stream processor of the GPU for the parallel operation processing to the guest OS when the time allocation amount of the guest OS satisfies a preset condition Calculates a time allocation amount of the guest OS by reflecting the allocation time of the GPU stream processor according to a result of allocating the stream processor of the GPU to the guest OS, And determining whether the quota satisfies the predetermined condition.

In one embodiment, the step of determining whether or not to allocate the GPU resource may include determining a GPU resource allocation ratio of the guest OS and a unit time per unit time of the GPU resource when the time allocation amount of the guest OS does not satisfy the pre- And storing the graphics processing instruction request until the time allocation amount of the guest OS satisfies the preset condition based on the refresh rate of the time allocation amount.

In one embodiment, the step of determining whether to allocate the GPU resource comprises: if the graphics processing instruction request attempts to access a memory of the GPU, the graphics library of the host OS requests the GPU Determining whether the memory usage of the guest OS exceeds the memory amount of the GPU allocated to the guest OS.

In one embodiment, the step of determining whether or not to allocate the GPU resource may include determining whether to allocate the GPU resource if the memory usage of the GPU according to the graphics processing instruction request does not exceed the memory amount of the GPU allocated to the guest OS, The graphic library of the OS may transmit the graphic processing command request to the device driver of the host OS.

In one embodiment, the step of determining whether or not to allocate the GPU resource may include the steps of: when the memory usage of the GPU according to the graphic processing command request exceeds the memory amount of the GPU allocated to the guest OS, To prevent the graphics library of the GPU from forwarding the graphics processing instruction request to the GPU.

In one embodiment, a method for managing GPU resources in a virtualized environment includes the steps of: receiving a request for a graphics processing instruction from an application, the virtual GPU driver of the guest OS; Comparing a memory amount of the GPU with a memory usage amount of the GPU according to the graphic processing command request; and controlling the virtual GPU driver of the guest OS to transmit the graphic processing command request to the host OS And determining whether to deliver the message.

In one embodiment, a GPU resource management method in the virtualization environment includes: receiving the graphic processing command request generated by an application from the application OS; receiving, by the graphics library of the guest OS, Processing into the GPU API format of the host OS, and the virtual GPU driver of the guest OS transferring the processed graphics processing instruction request to the host OS.

The GPU virtualization apparatus according to an embodiment of the present invention includes a guest OS for transferring a request for a graphics processing command generated from an application to a host OS, and for determining whether to allocate a GPU resource to the guest OS based on the graphics processing command request And a host OS for transferring the graphic processing command request to the GPU according to the determination result.

In one embodiment, the host OS may determine whether the time quota of the guest OS satisfies a predetermined condition when the graphics processing command request performs parallel computing processing.

In one embodiment, the host OS determines that a stream processor of the GPU performing the parallel operation processing is allocated to the guest OS when the time allocation amount of the guest OS satisfies a predetermined condition, Calculating a time allocation amount of the guest OS by reflecting the allocation time of the GPU stream processor according to a result of allocating the stream processor of the GPU to the OS, and if the time allocation amount of the recalculated guest OS satisfies predetermined conditions Can be determined.

In one embodiment, the host OS determines, based on the GPU resource allocation rate of the guest OS and the playback rate of the time allocation amount per unit time for the GPU resource, when the time allocation amount of the guest OS does not satisfy the pre- And a buffer unit for storing the graphics processing instruction request until the time allocation amount of the guest OS satisfies the predetermined condition.

In one embodiment, the host OS determines that the memory usage of the GPU in response to the graphics processing instruction request is greater than the memory amount of the GPU allocated to the guest OS when the graphic processing command request tries to access the GPU memory And a graphic library for determining whether the value exceeds the threshold value.

In one embodiment, if the memory usage of the GPU according to the graphics processing instruction request does not exceed the memory amount of the GPU allocated to the guest OS, the graphic library may transmit the graphic processing command request to the host OS Device driver.

In one embodiment, if the memory usage of the GPU according to the graphics processing instruction request exceeds the memory amount of the GPU allocated to the guest OS, the graphics library does not transfer the graphics processing command request to the GPU Can not be controlled.

In one embodiment, the guest OS receives the graphics processing instruction request from an application, verifies the amount of memory of the GPU allocated to the guest OS, and compares it with the memory usage of the GPU in response to the graphics processing instruction request And a virtual GPU driver that determines whether to transmit the graphic processing command request to the host OS according to the comparison result.

In one embodiment, the guest OS includes a graphic library that receives the graphics processing instruction request generated from an application and processes the received graphics processing instruction request into a GPU API format of the host OS, The GPU driver may forward the processed graphics processing instruction request to the host OS.

The present invention includes a computer-readable recording medium storing a program for causing a computer to execute a method according to an embodiment of the present invention.

According to the present invention, a GPU can be efficiently distributed to a plurality of virtual machines without specific hardware dependency in a cloud environment, so that it is more flexible than a pass-through method or SR-IOV depending on hardware functions and can improve price competitiveness.

According to the present invention, since the paravirtualization technique is used while using the driver of the actual GPU maker, the GPU utilization rate and performance can be improved.

According to the present invention, it is possible to prevent a problem due to a noisy neighbor effect (GPU resource increase) and a DOS attack problem in a cloud environment by providing a GPU resource management method.

1 is a diagram for explaining a method of virtualizing a GPU device in a hardware manner.
FIG. 2 illustrates a GPU virtualization apparatus using a paravirtualization technique according to an exemplary embodiment of the present invention. Referring to FIG.
3 is a block diagram of a GPU virtualization apparatus for performing a GPU resource management method according to an embodiment of the present invention.
4 is a flowchart illustrating a GPU resource management method using a paravirtualization technique according to an embodiment of the present invention.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings in order to clarify the technical idea of the present invention. In the following description of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a block diagram of a computer system according to an embodiment of the present invention; Fig. For convenience of explanation, the apparatus and method are described together when necessary.

Virtualization technology is one of the core technologies that enable the cloud. Virtualization technology is a hardware-based virtualization method that abstracts CPUs, memories, and peripherals to virtual machines, and creates an isolated space called a container that shares an operating system (OS) kernel, And OS-based virtualization methods that allocate resources such as memory to run application programs.

In hardware-based virtualization, hardware resources are generally virtualized to create logical hardware, and a separate OS is installed in each logical hardware to execute desired software. At this time, the OS installed in the logical hardware is referred to as a guest OS, and additional software for creating the logical hardware and running the guest OS is required, which is called a hypervisor or a virtual machine monitor. Also, the OS is required to run the hypervisor, which is called the host OS.

In general, hardware techniques are used to virtualize I / O devices such as GPUs. Hardware techniques include a passthrough scheme and a single root input / output virtualization (SR-IOV) scheme.

1 is a diagram for explaining a method of virtualizing a GPU device in a hardware manner. FIG. 1 (a) shows a pass-through system, and FIG. 1 (b) shows an SR-IOV system.

Referring to FIG. 1 (a), a pass-through method is a method of allocating one hardware (e.g., GPU) 140 to one virtual machine 110 or 111. At this time, the hypervisor 120 uses the virtual I / O auxiliary function of the CPU to compare the virtual address of a device (e.g., a GPU) recognized by the virtual machine 110 or 111 and the virtual address of a device recognized by the host OS 130 : GPU), and do not intervene later. When the guest OS 110 or 111 accesses the GPU 140, the virtual address of the GPU recognized by the guest OS 110 or 111 by the virtual I / O function of the CPU is transferred to the host OS 130 And converts it into an actual physical address so that the guest OS 110 or 111 can use the GPU 140. [

The hardware technique using the pass-through method is advantageous in that the virtual machine directly accesses the actual hardware, so that the performance is high and it is executed using the optimized driver provided by the hardware manufacturer. However, it is very inflexible because it allocates hardware to one virtual machine. For example, if a virtual machine using a GPU uses about 10% of the GPU's performance, the remaining 90% of the GPU's performance will be wasted. Also, when there are several virtual machines in one physical machine, resource efficiency is degraded since the number of virtual machines must be prepared by the number of GPUs.

Referring to FIG. 1B, the SR-IOV method divides one piece of hardware (e.g., GPU) 240 into a plurality of pieces of virtual hardware 241 and 242 as part of a PCI standard, . That is, according to the SR-IOV standard, since the GPU itself is divided into a plurality of logical GPUs, each logical GPU can be assigned to each virtual machine, and each virtual machine can use a logical GPU like a pass-through technique.

Therefore, the SR-IOV scheme has the merit of allowing multiple virtual machines to share one hardware while having the performance advantages of pass-through. In addition, since it supports sharing between virtual machines in hardware, it is more flexible than a pass-through method in which one virtual machine monopolizes hardware. However, devices using the SR-IOV method are expensive and it may be difficult to lower the cost of providing services in a cloud environment. In addition, since the types of devices supporting the SR-IOV specification do not vary, it may be difficult to find a device that fits the use case.

In order to solve the problem of using the hardware virtualization method described above, a GPU device can be virtualized using a software technique. Software techniques include full virtualization and paravirtualization.

The former virtualization method is to emulate GPU operation using CPU resources instead of actually using the GPU when the GPU needs to be used. When the guest OS wants to use the GPU, a graphic command reaches the GPU driver of the guest OS through the graphic stack of the guest OS, at which time the GPU driver requests the GPU emulation. Pre-virtualization may be appropriate for applications that do not require a high-performance GPU, such as Remote Desktop Services. However, in the virtualization method, the hypervisor uses the CPU to perform all operations of the GPU, which is less efficient than using the GPU directly in terms of performance. Therefore, unless you are only using the limited features of the GPU, there are limitations to the use of virtualization because of GPU performance issues. Also, since CPU and GPU have fundamentally different concepts in computation processing, it is difficult to develop GPU functions using a CPU.

The paravirtualization method uses an API forwarding method in which a guest OS executes an API call using OpenGL or the like and a host OS receives an API call and processes a GPU command when the guest OS uses the GPU. This API forwarding method has a high degree of development difficultness because it needs to implement an API call for all GPU commands. Also, in large clusters, all API calls must be forwarded over the network to other machines, resulting in network overhead and performance degradation.

GPU virtualization, on the other hand, has problems such as non-standardization of GPU design among GPU makers and fragmentation of graphics API version such as OpenGL. Because of this problem, public cloud service providers are generally taking the pass-through approach for high-performance GPU virtualization. This method is easy to implement technically because the GPU driver maker writes directly, and also supports high-performance communication between the virtual machine and the GPU device in hardware. However, as described above, since the pass-through method uses a single GPU in a single virtual machine, the GPU resources are wasted if the virtual machine does not use all the capabilities of the GPU.

In order to solve the above-described problems, the present invention proposes a method for applying GPU resources more efficiently and flexibly without relying on hardware functions by applying a paravirtualization technique.

FIG. 2 is a schematic diagram of a GPU virtualization apparatus using a paravirtualization technique according to an embodiment of the present invention. Referring to FIG.

Referring to FIG. 2, a GPU virtualization apparatus 300 (hereinafter referred to as a GPU virtualization apparatus) using a paravirtualization technique according to an embodiment of the present invention includes a plurality of guest OSs 310 and 320, a host OS 340, and a GPU 350.

The plurality of guest OSes 310 and 320 may each be operable on a virtual machine and may include graphics stacks 311 and 321 and virtual GPU drivers 312 and 322, respectively. Although FIG. 2 illustrates two guest OSs for convenience of explanation, the GPU virtualization apparatus according to the present invention may include two or more guest OSes.

The host OS 340 may include a graphics stack 341 and a hypervisor 330. The hypervisor 330 is a logical platform that performs resource management and scheduling between OSs so that a plurality of guest OSes 310 and 320 can use one GPU 350 logically. For example, the hypervisor 330 may be a hypervisor, such as Xen, Citrix XenServer, VMware's ESX Server, L4 microkernel, TRANGO, IBM's POWER hypervisor (PR / SM), Microsoft Hyper- You can use Logical Domain Hypervisor, VMware Server, VMware Workstation, VMware Fusion, QEMU, Microsoft's Virtual PC and Virtual Server, Oracle (SUN) VirtualBox, SWsoft's Parallels Workstation and Parallels Desktop.

In one embodiment, the guest OSes 310 and 320 may load and install the virtual GPU drivers 312 and 322 shown by the hypervisor 330. The guest OS 310 and 320 generates a graphic processing command and transfers the graphic processing command to the graphic stacks 311 and 321. The received graphic processing command is transmitted to the graphic stack 311 , 321, and is transmitted to the virtual GPU drivers 312, 322. At this time, the graphics processing command can be processed into the standardized GPU API format, which is a promised form between the guest OS 310, 320 and the host OS 340. The virtual GPU drivers 312 and 322 may communicate the processed graphics processing instructions to the graphics stack 341 of the host OS 340. [ The host OS 340 may request the graphics processing command from the actual physical GPU 350. [ At this time, the host OS 340 can process graphics processing commands in conjunction with the GPU context of the application requesting the graphics processing command in the guest OS 310, 320. [ In addition, the host OS 340 can process graphic processing commands using a high-performance device driver provided by an actual GPU manufacturer. In other words, regardless of which OS the guest OS 310 or 320 uses, the guest OS 310 or 320 uses the virtual GPU driver 312 or 322 to instruct the host OS 340 to execute a graphic processing command The host OS 340 can support a graphic processing command request using a high-performance driver. Therefore, in a cloud environment, a virtual device driver in a user's virtual machine can flexibly support GPU resources regardless of the type of OS. In addition, since the GPU context is managed in units of applications of the guest OSs 310 and 320, one physical GPU can naturally be shared by a plurality of guest OSes 310 and 320 and used.

3 is a block diagram of a GPU virtualization apparatus for performing a GPU resource management method according to an embodiment of the present invention.

3, a GPU virtualization device 400 may include a guest OS 410, a host OS 420, and a GPU 430. Although the GPU virtualization apparatus 400 of FIG. 3 is illustrated as including one guest OS 410 for convenience of explanation, this is only an example, and may include a plurality of guest OSes. In addition, the GPU virtualization apparatus 400 of FIG. 3 shows only the components related to the present embodiment and includes the contents described in FIG. 2, and the duplicated description will be omitted.

The guest OS 410 may operate on a virtual machine and may include an application 411, a graphics library 412, and a virtual GPU driver 413.

The guest OS 410 may receive graphics processing instructions that are executed using the GPU 430 resources from the application 411 and may pass it to the graphics library 412 of the guest OS 410. [ The graphics library 412 may process graphics processing instructions into the host OS 420's GPU API format. For example, the graphics library 412 may use OpenGL libraries that support standard APIs such as Mesa, which are implemented in software. The virtual GPU driver 413 can transfer the graphics processing command processed by the graphics library 412 to the host OS 420. [ For example, the virtual GPU driver 413 may use a Virtual I / O (Virtio) driver that is a standard interface for supporting a paravirtualized device between the guest OS 410 and the host OS 420.

The host OS 420 receives the graphics processing command from the virtual GPU driver 413 and determines whether to allocate the GPU 430 resource to the guest OS 410 based on the received graphics processing command, To request a graphics processing command.

More specifically, the host OS 420 may include a hypervisor 421, a graphics library 423, and a device driver 424. For example, the hypervisor 421 may select one of a number of hypervisors as described in FIG. 2, and may use, for example, a QEMU, and the graphics library 423 may be a GPU The device driver 424 may be operated using a DRM that is a sub-system of the Linux kernel that supports the interface with the GPU .

, i번째 게스트 OS의 자원 배분률을

, 단위 시간 당 시간 할당량에 대한 재생률을 r이라고 정의하면, 시간 할당량은 다음 수학식 1과 같이 계산될 수 있다.In one embodiment, when the application 411 of the guest OS 410 requests a graphics processing instruction to perform parallel computing processing, the hypervisor 421 determines whether the time quota of the guest OS 410 has been set It is possible to judge whether or not the condition is satisfied. In this case, the time quota can be defined as a ratio of the time when the guest OS does not use the GPU resource for a unit time. In one embodiment, the time quota of the i-th guest OS at time t

, the resource allocation rate of the i-th guest OS

, And the reproduction rate with respect to the time allocation per unit time is defined as r, the time allocation can be calculated as shown in the following equation (1).

로 정의될 수 있다. 하이퍼바이저(421)는 수학식 1에 의해 계산된 게스트 OS(410)의 시간 할당량이

조건을 만족하는 경우에 그래픽 처리 명령을 디바이스 드라이버(424)로 전달하고, 이 명령을 다시 디바이스 드라이버(424)가 GPU(430)로 전달할 수 있다. 이 경우, 게스트 OS(410)는 자신의 시간 할당량 내에서 GPU(430)의 스트림 프로세서를 할당 받아 그래픽 처리 명령을 병렬 연산으로 수행할 수 있다. 그 결과, 게스트 OS(410)의 시간 할당량은 GPU(430)의 스트림 프로세서를 할당 받은 시간만큼 감소된다. 하이퍼바이저(421)는 GPU(430)의 스트림 프로세서를 할당 받은 시간을 반영하여 게스트 OS(410)의 시간 할당량을 재계산할 수 있으며, 재계산된 시간 할당량이 기 설정된 조건을 만족한다면 게스트 OS(410)가 다음 그래픽 처리 명령을 수행할 수 있도록 한다. 또한 하이퍼바이저(421)는 재계산된 시간 할당량이 기 설정된 조건을 만족하지 않는 경우 재생률이 일정하기 때문에 기 설정된 조건을 언제 만족할지 예측 시간을 계산할 수도 있다. 이때, 시간 할당량의 재계산은 특정한 시간 단위로 수행될 수도 있고, 다음 그래픽 처리 명령을 요청 받았을 때에 수행될 수도 있다. When the time allocation amount of the guest OS 410 satisfies the predetermined condition, the hypervisor 421 can determine that the guest OS 410 allocates the stream processor of the GPU 430 performing the parallel operation processing . In one embodiment, the predetermined condition is

. ≪ / RTI > The hypervisor 421 determines whether the time allocation of the guest OS 410 calculated by Equation (1)

If the condition is satisfied, a graphics processing command is sent to the device driver 424 and the device driver 424 can pass the command to the GPU 430 again. In this case, the guest OS 410 can allocate a stream processor of the GPU 430 within its own time allocation amount and perform graphics processing instructions in parallel operation. As a result, the amount of time allocated to the guest OS 410 is reduced by the time that the stream processor of the GPU 430 is allocated. The hypervisor 421 can recalculate the time allocation amount of the guest OS 410 in accordance with the time allocated to the stream processor of the GPU 430. If the recalculated time allocation amount satisfies the predetermined condition, ) To perform the next graphics processing instruction. Also, the hypervisor 421 may calculate the predicted time when the preset condition is satisfied because the recalculation rate is constant if the recalculated time allocation amount does not satisfy the predetermined condition. At this time, the recalculation of the time allocation amount may be performed in a specific time unit, or may be performed when a next graphic processing command is received.

)을 만족할 때까지 그래픽 처리 명령을 디바이스 드라이버(424)로 전달하지 않고 버퍼부(미도시)에 저장할 수 있다.If the time allocation amount of the guest OS 410 does not satisfy the predetermined condition, the hypervisor 421 determines that the time allocation amount of the guest OS 410 calculated according to Equation (1)

) May be stored in the buffer unit (not shown) without passing the graphics processing command to the device driver 424.

On the other hand, in the case of the graphics processing instruction processed by the GPU, since the computing time of the graphics processing instruction may be influenced not only by the GPU but also by various factors such as the CPU, memory, and workload characteristics, Hard. However, according to the time distribution method of GPU resources according to the embodiment of the present invention, only when a time allocation amount remains in each virtual machine, the graphics processing command requested by the corresponding virtual machine is transmitted to the GPU, If not, it waits for a graphics processing instruction until the time quota is restored and distributes the GPU resources after recovery. Therefore, in the present invention, since only the time allocation amount of the guest OS is managed in the host OS without having to predict the time required for the GPU to calculate the graphics processing command, the implementation is easy and high reliability can be obtained. Also, there is a physical distribution method of stream processor resources in comparison with the time distribution method of GPU resources according to an embodiment of the present invention. This method is a method of distributing GPU resources based on the number of stream processors. For example, when there are N stream processors, 0.4 * N stream processors are allocated in a virtual machine with 40% resource occupancy. This physical distribution scheme has the advantage of being able to distribute GPU resources accurately, but it can not be implemented without information about the devices of the GPU manufacturer. However, in the case of the time distribution method of the GPU resources according to the present invention, since only the time quota information of the guest OS is calculated without information about the GPU, there is an advantage that it can be implemented for any GPU.

In another embodiment, if the application 411 of the guest OS 410 requests a graphics processing instruction to access memory resources of the GPU 430, the graphics library 423 of the host OS 420 may perform graphics processing It is possible to determine whether the memory usage of the GPU 430 in accordance with the execution of the command exceeds the memory amount of the GPU 430 allocated to the guest OS 410. [ The graphic library 423 can control the graphic processing command according to the determination result.

If the memory usage of the GPU 430 due to performing the graphics processing command does not exceed the amount of memory of the GPU 430 allocated to the guest OS 410, the graphics library 423 sends graphics processing instructions to the device driver 424, respectively. In this case, the guest OS 410 can allocate memory resources of the GPU 430 and execute graphics processing instructions.

If the memory usage of the GPU 430 due to performing the graphics processing instructions exceeds the amount of memory of the GPU 430 allocated to the guest OS 410, the graphics library 423 sends graphics processing instructions to the device driver 424 ) To be transmitted. In this case, the guest OS 410 can not allocate the memory resources of the GPU 430 and can not process the graphics processing command. Through this process, the guest OS 410 can use only the permitted resources without exceeding the memory resources allocated to the guest OS 410. [

In addition, in the memory distribution method of the GPU according to the embodiment of the present invention, the guest OS 410 can perform memory management by itself. In one embodiment, the guest OS 410 may be installed so as to grasp the amount of memory of the GPU 430 allocated to the guest OS 410 when the virtual GPU driver 413 is loaded. For example, if the memory of the actual GPU 430 is 8 GB and the occupancy rate of one virtual machine on the whole machine is 40%, the virtual machine can be allocated the memory of the 3.2 GB GPU 430, The user can know his / her memory allocation amount through the memory 413. According to one embodiment of the present invention, when the guest OS 410 receives a graphics processing command from an application 411 that attempts to access memory resources of the GPU 430, it sends this command to the host OS 420 To the virtual GPU driver 413 before doing so. The virtual GPU driver 413 can check the amount of memory of the GPU 430 allocated to the guest OS 410 and compare the amount of memory of the GPU 430 with the amount of memory used by the GPU 430 for executing the graphics processing command. According to the comparison result, the virtual GPU driver 413 can determine whether to transmit the graphic processing command to the host OS 420. [ When the graphics processing command is transmitted to the host OS 420, the memory resource allocation process of the GPU 430 on the host OS 420 side may be performed as described in the graphic library 423.

As described above, according to the embodiment of the present invention, the amount of the GPU memory allocated to the virtual machine is displayed through the virtual GPU driver on the virtual machine, so that the software running on the virtual machine can induce memory management by itself. Therefore, when the present invention is applied to an environment in which high-performance software such as a cloud environment (for example, simulation, game, etc.) is executed, the guest OS can manage the GPU- swap) to prevent performance degradation.

4 is a flowchart illustrating a GPU resource management method using a paravirtualization technique according to an embodiment of the present invention. The method of FIG. 4 may be performed by the GPU virtualization apparatuses of FIGS. 2 and 3 described above. In this embodiment, the GPU virtualization apparatus of FIG. 3 will be described for convenience of explanation.

Referring to FIG. 4, the guest OS 410 may receive a graphics processing instruction request generated from the application 411 (S500). The graphic library 412 of the guest OS 410 may process the received graphics processing command request into the GPU API format of the host OS 420 (S510). The virtual GPU driver 413 of the guest OS 410 may forward the processed graphics processing instruction request to the host OS 420 (S520). At this time, the GPU API converter 422 of the host OS 420 can change the graphics processing command request to a form understandable in the graphic stack of the host OS 420, and send the graphics processing command request of the changed form to the host OS 420 To the hypervisor 421 of FIG.

In accordance with an embodiment, the graphics library 412 of the guest OS 410 may communicate a graphics processing instruction request in a form that is understandable in the graphics stack of the host OS 420. In this case, it is not necessary to convert the graphics processing instruction request of the guest OS 410 in the GPU API converter 422. In another embodiment, a graphics processing instruction request is generated in a separate intermediate form, such as an IR (Intermediate representation), different from that processed by the host OS 420 in the graphics library 412 of the guest OS 410 To the host OS 420. A typical specification of IR is Tungsten Graphics Shader Infrastructure (TGSI). In this case, the GPU API converter 422 may convert the graphics processing command request received from the guest OS 410 into a form understandable in the graphics stack of the host OS 420 and deliver it to the hypervisor 421.

The host OS 420 may determine whether to allocate the GPU 430 resource to the guest OS 410 based on the graphic processing command request received from the virtual GPU driver 413 of the guest OS 410 ). According to the determination result, the host OS 420 may transmit a graphic processing command request to the GPU 430 (S540).

In one embodiment, when the application 411 of the guest OS 410 requests a graphics processing instruction to perform a parallel computing process, the hypervisor 421 of the host OS 420 determines the time quota of the guest OS 410 It can be determined whether or not the predetermined condition is satisfied. According to the determination result, the hypervisor 421 can determine whether to allocate the stream processor of the GPU 430 that performs the parallel operation processing to the guest OS 410. [

In another embodiment, if the application 411 of the guest OS 410 requests a graphics processing instruction to access memory resources of the GPU 430, the graphics library 423 of the host OS 420 may perform graphics processing It is possible to determine whether the memory usage of the GPU 430 in accordance with the execution of the command exceeds the memory amount of the GPU 430 allocated to the guest OS 410. [ According to the determination result, the graphic library 423 can control whether to transfer the graphics processing command to the device driver 424, and can determine the allocation of the memory resource of the GPU 430 according to the control.

The process performed in each step has been described in detail with reference to FIG. 2 and FIG. 3. Therefore, a detailed description thereof will be omitted in the present embodiment.

The above-described method according to the present invention can also be implemented as computer-readable codes on a computer-readable recording medium. Computer-readable recording media include all physical storage media such as magnetic storage media, optical reading media, and the like. It is also possible to record the data format of the message used in the present invention on a recording medium.

The present invention has been described in detail with reference to the preferred embodiments shown in the drawings. These embodiments are to be considered as illustrative rather than limiting, and should be considered in an illustrative rather than a restrictive sense. The true scope of protection of the present invention should be determined by the technical idea of the appended claims rather than the above description. Although specific terms are used herein, they are used for the purpose of describing the concept of the present invention only and are not used to limit the scope of the present invention described in the claims or the claims. Each step of the present invention need not necessarily be performed in the order described, but may be performed in parallel, selectively, or individually. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. It is to be understood that the equivalents include all components that are invented in order to perform the same function irrespective of the currently known equivalents as well as the equivalents to be developed in the future.

Claims (19)

A method of managing GPU (Graphics Processing Unit) resources in a virtualized environment,
The method comprising: receiving a graphics processing instruction request from a guest OS of at least one of a plurality of guest OSs;
Determining whether the host OS allocates GPU resources to the guest OS based on the graphics processing instruction request; And
And forwarding the graphics processing instruction request to the GPU by the host OS according to the determination result,
Wherein the determining whether to allocate the GPU resource comprises:
Determining whether a quota of the guest OS satisfies a predetermined condition when the graphic processing command request performs parallel computing processing; And
If the time allocation amount of the guest OS satisfies a predetermined condition, it is determined that the stream processor of the GPU for parallel operation processing is allocated to the guest OS, and the result of allocating the stream processor of the GPU to the guest OS Calculating a time allocation amount of the guest OS by reflecting the allocation time of the stream processor of the GPU and determining whether the time allocation amount of the re-calculated guest OS satisfies a preset condition How to manage GPU resources. delete delete The method according to claim 1,
Wherein the determining whether to allocate the GPU resource comprises:
If the time allocation amount of the guest OS does not meet the predetermined condition, the time allocation amount of the guest OS is updated based on the GPU resource allocation rate of the guest OS and the playback rate of the time allocation amount per unit time with respect to the GPU resource And storing the graphics processing instruction request until it is satisfied. The method according to claim 1,
Wherein the determining whether to allocate the GPU resource comprises:
If the graphics processing instruction request attempts to access the GPU's memory,
And determining whether the memory usage of the GPU according to the graphics processing instruction request exceeds the memory amount of the GPU allocated to the guest OS by the graphics library of the host OS. 6. The method of claim 5,
Wherein the determining whether to allocate the GPU resource comprises:
If the memory usage of the GPU according to the graphics processing instruction request does not exceed the memory amount of the GPU allocated to the guest OS, the graphics library of the host OS forwards the graphics processing command request to the device driver of the host OS The GPU resource management method comprising: 6. The method of claim 5,
Wherein the determining whether to allocate the GPU resource comprises:
Controlling to prevent the graphics library of the host OS from forwarding the graphics processing instruction request to the GPU when the memory usage of the GPU according to the graphics processing instruction request exceeds the amount of memory of the GPU allocated to the guest OS The GPU resource management method comprising: 6. The method of claim 5,
The virtual GPU driver of the guest OS receiving the graphics processing instruction request from an application;
The virtual GPU driver of the guest OS checks the memory amount of the GPU allocated to the guest OS and compares the memory amount with the memory usage amount of the GPU according to the graphic processing command request; And
Further comprising determining whether the virtual GPU driver of the guest OS transfers the graphics processing instruction request to the host OS according to the comparison result. The method according to claim 1,
The guest OS receiving the graphics processing instruction request generated from an application;
Processing the received graphics processing command request into the GPU API format of the host OS by the graphics library of the guest OS; And
And the virtual GPU driver of the guest OS transfers the processed graphics processing instruction request to the host OS. A guest OS for delivering a graphics processing instruction request generated from an application to a host OS; And
And a host OS for determining whether to allocate GPU resources to the guest OS based on the request for the graphics processing command and delivering the graphics processing command request to the GPU according to the determination result,
The host OS,
When the graphic processing command request performs parallel computing processing, it is determined whether the time quota of the guest OS satisfies a predetermined condition,
And determines that the stream processor of the GPU performing the parallel operation processing is allocated to the guest OS when the time allocation amount of the guest OS satisfies the predetermined condition,
Calculating a time allocation amount of the guest OS by reflecting the allocation time of the stream processor of the GPU according to a result of allocating the stream processor of the GPU to the guest OS, And determines whether the condition is satisfied. delete delete 11. The method of claim 10,
The host OS,
If the time allocation amount of the guest OS does not meet the predetermined condition, the time allocation amount of the guest OS is updated based on the GPU resource allocation rate of the guest OS and the playback rate of the time allocation amount per unit time with respect to the GPU resource And a buffer unit for storing the graphic processing command request until it is satisfied. 11. The method of claim 10,
The host OS,
If the graphics processing instruction request attempts to access the GPU's memory,
And a graphics library for determining whether the memory usage of the GPU according to the graphics processing instruction request exceeds a memory amount of the GPU allocated to the guest OS. 15. The method of claim 14,
The graphic library includes:
And when the memory usage of the GPU according to the graphic processing command request does not exceed the memory amount of the GPU allocated to the guest OS, the graphic processing command request is transmitted to the device driver of the host OS. Device. 15. The method of claim 14,
The graphic library includes:
And controls the GPU not to forward the graphic processing command request to the GPU when the memory usage of the GPU according to the graphic processing command request exceeds the memory amount of the GPU allocated to the guest OS. 15. The method of claim 14,
The guest OS,
Receiving the graphics processing instruction request from an application,
Comparing a memory usage of the GPU allocated to the guest OS with a memory usage amount of the GPU according to the graphics processing instruction request,
And a virtual GPU driver for determining whether to transmit the graphic processing command request to the host OS according to the comparison result. 18. The method of claim 17,
The guest OS,
Receiving the graphics processing instruction request generated from the application,
And a graphics library for processing the received graphics processing command request into the GPU API format of the host OS,
The virtual GPU driver,
And delivers the processed graphics processing instruction request to the host OS. A computer-readable recording medium storing a program for causing a computer to execute the method according to any one of claims 1 to 9.

Images