Creation method, recovery method and creation device of GPU application program check point, equipment and storage medium

Abstract

The invention relates to a creation method, a recovery method, a creation device and equipment of a GPU application program check point, and a storage medium. The creation method comprises the following steps: setting a GPU environment variable in a client based on the demand of a GPU application program; configuring the GPU application program to call the compiled dynamic library; programs related to CPU operation in the GPU application program are executed through a CPU of the client; executing programs related to GPU operation in the GPU application program through remote procedure calling; recording first execution state information of a CPU in the client; recording second execution state information of the GPU in the server; checkpoint information is determined based on the first execution state information and the second execution state information. According to the method for creating the check points, the storage time and the space overhead of the check points can be reduced, and it is ensured that in a complex calculation task, creation of the check points cannot remarkably affect the overall performance of a GPU application program.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method for creating a GPU application checkpoint, a method for restoring a checkpoint, a creation device, a device, and a storage medium. Background Art

[0002] With the continuous development of GPU (Graphics Processing Unit) technology, GPU has been widely used in high-performance computing (HPC), artificial intelligence (AI), machine learning (ML), deep learning (DL), scientific computing and image processing. Compared with the traditional CPU (Central Processing Unit), GPU has powerful parallel computing capabilities and can process a large amount of data operations at the same time, thus showing significant performance advantages when processing graphics-intensive and computing-intensive tasks. However, as the complexity of GPU applications increases, long-running computing tasks may be affected by unforeseen events such as hardware failures, software errors, power outages, etc. during execution, resulting in computing interruptions. This not only wastes a lot of computing resources, but may also cause data loss and process termination.

[0003] In order to ensure the continuity and reliability of computing tasks, GPU applications need to have an effective fault-tolerant mechanism, among which checkpoint and recovery technology has become a key method to solve such problems. Checkpoint and recovery technology is a fault-tolerant technology widely used in distributed systems and high-performance computing. It saves the current state of the program as a checkpoint file regularly. When the program is interrupted due to a fault, it can be restarted from the most recent checkpoint, thus avoiding running the entire program from scratch. In the CPU field, checkpoint recovery technology is relatively mature, but how to perform checkpoint recovery on GPU applications is still an urgent problem to be solved. Summary of the invention

[0004] Based on this, it is necessary to provide a GPU application checkpoint creation method, recovery method, creation device, equipment and storage medium that can create and restore checkpoints for GPU applications in response to the above technical problems.

[0005] In the first aspect, the present application provides a method for creating a checkpoint of a GPU application. The method includes: setting GPU environment variables in a client based on the needs of the GPU application; configuring the GPU application to call a compiled dynamic library; executing a program in the GPU application involving CPU operation through the CPU of the client; executing a program in the GPU application involving GPU operation through a remote procedure call; wherein the remote procedure call is jointly executed by a server connected to the client; recording first execution status information of the CPU in the client; recording second execution status information of the GPU in the server; and determining checkpoint information based on the first execution status information and the second execution status information.

[0006] The above-mentioned method for creating a checkpoint for a GPU application sets the GPU environment variables in the client according to the needs of the GPU application, and then configures the GPU application to call the compiled dynamic library so that the dynamic library can intercept and process related API calls. When the GPU application is running, the program involving CPU operation in the GPU application is executed through the client's CPU, and the program involving GPU operation in the GPU application is executed through a remote procedure call. When creating a checkpoint, the first execution status information of the CPU in the client is recorded, and the second execution status information of the GPU in the server is recorded, and it is used as the checkpoint information, thereby completing the creation of the checkpoint. The checkpoint creation method of the present application can reduce the storage time and space overhead of the checkpoint, and ensure that in complex computing tasks, the creation of the checkpoint will not significantly affect the overall performance of the GPU application.

[0007] In one of the embodiments, the step of recording the second execution state information of the GPU in the server includes: obtaining the running information of the GPU application on the GPU; wherein the running information includes: memory allocation, thread synchronization, and kernel execution state; obtaining the internal information of the GPU through a debugger API; wherein the internal information includes: synchronization state, program counter, and call stack; obtaining memory information; wherein the memory information includes: static memory information and dynamic memory information; and using the running information, the internal information, and the memory information as the second execution state information.

[0008] In one embodiment, the step of obtaining memory information includes: obtaining the static memory information based on static memory area information; and obtaining the dynamic memory information based on dynamic memory area information.

[0009] In one of the embodiments, the step of obtaining the dynamic memory information based on the dynamic memory area information includes: using API call information related to the dynamic memory as the dynamic memory area information.

[0010] In a second aspect, the present application also provides a method for recovering a GPU application checkpoint, the method comprising: loading checkpoint information; wherein the checkpoint information is created by the method for creating a GPU application checkpoint described in the embodiment of the first aspect above; and continuing to execute the GPU application based on the recovery point and the checkpoint information.

[0011] The above-mentioned GPU application checkpoint recovery method, by loading the stored checkpoint information and continuing to execute the GPU application according to the recovery point and checkpoint information, can achieve rapid recovery and continued execution of the GPU application in the face of hardware failure, software error or other unforeseen events, thereby significantly improving the reliability and stability of the system.

[0012] In one of the embodiments, the method further includes: determining the recovery point by modifying a jump instruction in the GPU application.

[0013] In the third aspect, the present application also provides a device for creating a checkpoint of a GPU application. The device includes: an environment setting module, which is used to set GPU environment variables in the client based on the needs of the GPU application; a dynamic library update module, which is used to configure the GPU application to call the compiled dynamic library; a program running module, which is used to execute the program involving CPU operation in the GPU application through the CPU of the client; a remote call module, which is used to execute the program involving GPU operation in the GPU application through a remote procedure call; wherein the remote procedure call is jointly executed by a server connected to the client; a first information recording module, which is used to record the first execution status information of the CPU in the client; a second information recording module, which is used to record the second execution status information of the GPU in the server; a checkpoint determination module, which is used to determine the checkpoint information based on the first execution status information and the second execution status information.

[0014] In one of the embodiments, the second information recording module is also used to obtain the running information of the GPU application on the GPU; wherein the running information includes: memory allocation, thread synchronization, kernel execution status; obtain the internal information of the GPU through the debugger API; wherein the internal information includes: synchronization status, program counter, call stack; obtain memory information; wherein the memory information includes: static memory information and dynamic memory information; use the running information, the internal information and the memory information as the second execution status information.

[0015] In a fourth aspect, the present application further provides a computer device, wherein the computer device comprises a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the above method when executing the computer program.

[0016] In a fifth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, and the computer program implements the steps of the above method when executed by a processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 An application environment diagram of a creation method and a recovery method in one embodiment;

[0018] Figure 2 A schematic diagram of a process for creating a method in one embodiment;

[0019] Figure 3 A schematic diagram of a process for recording second execution state information in an embodiment;

[0020] Figure 4 A schematic diagram of a recovery method in one embodiment;

[0021] Figure 5 A schematic diagram of a process of creating a method and restoring a method in an embodiment;

[0022] Figure 6 A schematic diagram of a module for creating a device in one embodiment;

[0023] Figure 7 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0024] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0025] First, some nouns involved in this application are analyzed:

[0026] API (Application Programming Interface): is a set of predefined functions that aims to provide applications and developers with the ability to access a set of routines based on certain software or hardware without having to access the source code or understand the details of the internal working mechanism.

[0027] RPC (Remote Procedure Call) is a technology for requesting services from a remote computer program over a network. It allows a program to call a procedure or function on another computer just like calling a local function.

[0028] CUDA API: A parallel computing platform and programming model launched by NVIDIA that enables developers to use NVIDIA's GPUs for general computing.

[0029] As described in the background technology, since the execution time of long-running GPU applications usually ranges from a few hours to a few days, the currently executing application can be changed dynamically, which significantly improves flexibility. However, long-running GPU applications are inherently more susceptible to statistical failures, because the longer the execution time, the greater the possibility of errors in the operation. For example, memory failures and hardware errors require the GPU application to be restarted. Checkpoint technology can suspend the execution of an application without losing the computing progress, save the execution state of the application, and restore the computing progress at a subsequent time point. However, the architecture of the GPU is significantly different from that of the CPU. The multi-threaded parallel execution model and large-scale data processing capabilities of the GPU place higher requirements on the creation and recovery of checkpoints. Secondly, due to the complex data transmission between the GPU memory and the main memory, how to achieve efficient checkpoint storage without significantly affecting the system performance is a difficult problem. In addition, GPU applications usually involve a large number of computing states and data dependencies. How to accurately capture and restore these states to ensure the correctness and consistency of the program is also an important challenge in checkpoint recovery technology.

[0030] Existing GPU checkpoint recovery schemes often have the following shortcomings: First, due to the parallelism and large-scale data processing characteristics of the GPU architecture, the checkpoint creation and storage process may cause significant performance overhead; second, when a failure occurs, the recovery process may not be able to accurately reproduce the computing state, thus affecting the correctness and consistency of the program; third, the storage strategy of checkpoint data may not be flexible enough to adapt to the needs of different application scenarios.

[0031] Based on this, the present application provides a GPU application checkpoint creation method, recovery method, creation device, equipment and storage medium to solve the above problems.

[0032] The creation method and recovery method provided in the embodiments of the present application can be applied to Figure 1In the application environment shown. Among them, the terminal 102 communicates with the server 104 through the network. The data storage system can store the data that the server 104 needs to process. The data storage system can be integrated on the server 104, or it can be placed on the cloud or other network servers. Among them, the terminal 102 can be, but is not limited to, various personal computers, laptops, tablet computers, etc. The server 104 can be implemented with an independent server or a server cluster consisting of multiple servers.

[0033] The terminal 102 in the embodiment of the present application may be provided with a GPU device or may not be provided with a GPU device. When the terminal 102 is provided with a GPU device, the client may be a client virtual machine, and the server may be a master virtual machine that can directly drive the GPU device. When the terminal 102 is not provided with a GPU device, the client is the terminal device, and the server is the remote device provided with a GPU device.

[0034] In one embodiment, Figure 2 As shown, a method for creating a checkpoint of a GPU application is provided, and the method is applied to Figure 1 The terminal 102 in the example is used as an example to illustrate, and the following steps are included:

[0035] Step S110, setting GPU environment variables in the client based on the requirements of the GPU application.

[0036] Specifically, in the client environment, you first need to configure the GPU environment variables related to the operation of the GPU application. The GPU environment variables include the size of the GPU video memory, the GPU computing power requirements, the number of GPU cards required, and other parameters. By setting the GPU environment variables, you can ensure that GPU resources can be reasonably allocated and used, while meeting the current GPU application operation requirements. For example, set the Linux GPU environment variables in the client virtual machine, for example, specify the use of 1 GPU card (eGPU=0), limit the GPU utilization to 10%, and limit the GPU video memory size to 500M (eGPUMEM=500, eGPUWEIGHT=10).

[0037] Step S120, configuring the GPU application to call the compiled dynamic library.

[0038] Specifically, in the running environment of the client's GPU application, it is also necessary to replace the GPU API-related dynamic link library with a pre-compiled dynamic library so that the compiled dynamic library can be called by the GPU application to ensure that the GPU application uses the dynamic library first when it starts running, thereby achieving the interception and hijacking of the GPU API. For example, the pre-compiled dynamic library is: eCUDA-client.so. At this time, set the environment variable LD_PRELOAD=eCUDA-client.so to ensure that the dynamic library is called when the GPU application starts.

[0039] Step S130: executing the program in the GPU application program that involves CPU operation through the client's CPU.

[0040] Specifically, a GPU application includes programs run by the CPU and programs run by the GPU. When the GPU application runs on the client, the CPU part of the code will run normally on the local client. This part of the code is mainly responsible for tasks such as logic control and data preprocessing.

[0041] Step S140, executing a program related to GPU operation in the GPU application program through a remote procedure call;

[0042] Specifically, since the remote procedure call is jointly executed by the server connected to the client, when the GPU application needs to execute GPU-related code, the client sends the request to the server on the remote GPU node through a remote procedure call (RPC). After receiving the request, the server uses GPU resources to perform the corresponding computing task and returns the result to the client. For example, in the initialization phase, the dynamic library eCUDA-client.so reads the configured environment variables and polls the GPU node. Then the GPU computing task is sent to the remote GPU server through RPC for execution.

[0043] Step S150: Record first execution state information of the CPU in the client.

[0044] Specifically, when creating a checkpoint, the execution state information of the CPU part in the client is recorded and used as the first execution state information. The first execution state information includes register content, program counter (PC), call stack, etc., so that the execution environment of the CPU part can be rebuilt during recovery. For example, the Checkpoint / Restore InUserspace tool can be used to record the first execution state information.

[0045] Step S160, recording the second execution state information of the GPU in the server.

[0046] Specifically, when creating a checkpoint, the execution state information of the GPU in the server needs to be recorded and used as the second execution state information. The second execution state information includes memory allocation, thread synchronization status, kernel execution progress, etc. This information is crucial to ensure the consistency of the GPU state after recovery.

[0047] Step S170: Determine checkpoint information based on the first execution status information and the second execution status information.

[0048] Specifically, the first execution state information of the client CPU part and the second execution state information of the server GPU part are finally integrated to determine the complete checkpoint information. The checkpoint information is used to resume execution from the checkpoint after the program is interrupted. The checkpoint information can be saved to a persistent storage (such as a disk, network storage, etc.) so that it can be restored when needed.

[0049] The above-mentioned method for creating a checkpoint for a GPU application sets the GPU environment variables in the client according to the needs of the GPU application, and then configures the GPU application to call the compiled dynamic library so that the dynamic library can intercept and process related API calls. When the GPU application is running, the program involving CPU operation in the GPU application is executed through the client's CPU, and the program involving GPU operation in the GPU application is executed through a remote procedure call. When creating a checkpoint, the first execution status information of the CPU in the client is recorded, and the second execution status information of the GPU in the server is recorded, and it is used as the checkpoint information, thereby completing the creation of the checkpoint. The checkpoint creation method of the present application can reduce the storage time and space overhead of the checkpoint, and ensure that in complex computing tasks, the creation of the checkpoint will not significantly affect the overall performance of the GPU application.

[0050] In one embodiment, Figure 3 As shown, in step S160, the step of recording the second execution state information of the GPU in the server includes:

[0051] Step S161, obtaining the running information of the GPU application on the GPU.

[0052] Specifically, when recording the second execution state information of the GPU in the server, first obtain the running information of the GPU application on the GPU. The running information includes: memory allocation, thread synchronization, and kernel execution state. Memory allocation is used to record the size, location, and ownership of all allocated memory blocks on the GPU, which helps to reallocate these memory blocks during recovery and ensure data consistency; thread synchronization is used to record the execution state and synchronization points of all threads on the GPU, which includes the dependencies between threads, waiting conditions, and semaphore states, etc., which is crucial for correctly arranging the execution order of threads during recovery. Kernel execution state is used to record the state of the currently executing GPU kernel, including the kernel's startup parameters, execution progress, and any suspended operations, which helps to restart the kernel during recovery and continue execution from the correct position. For example, when the GPU application uses the CUDA API to execute code on the GPU, the API provided by the GPU driver (such as the CUDA Runtime API) can be used to query the memory allocation; monitor the execution of GPU threads, and use synchronization primitives (such as CUDA events and streams) to track thread states and synchronization points.

[0053] Step S162, obtaining internal information of the GPU through a debugger API.

[0054] Specifically, in order to gain a deeper understanding of the state of the GPU, it is necessary to use the debugger API to access the internal information of the GPU. The internal information includes: synchronization state, program counter, and call stack. The synchronization state is used to obtain the current state of all synchronization primitives (such as semaphores, fences, and events) on the GPU, which helps to re-establish the correct synchronization relationship upon recovery. The program counter is used to record the program counter value of each GPU thread, which reflects the location of the instruction currently executed by the thread. When resuming, the thread can be relocated to the correct execution point based on this information. The call stack is used to obtain the call stack information of each GPU thread, including the function call sequence and parameters, which helps to reconstruct the execution context of the thread upon recovery. For example, when a GPU application uses the CUDA API to execute code on the GPU, the GPU debugger API (NVIDIA NsightCompute) can be used to connect to the GPU and query its internal state.

[0055] Step S163, obtaining memory information.

[0056] Specifically, memory information is an important part of the GPU state, which records the allocation and usage of all memory blocks on the GPU. Memory information includes: static memory information and dynamic memory information. Static memory information is used to record the size and location of statically allocated memory blocks on the GPU (such as global variables and constant memory). This information usually does not change during program execution. Dynamic memory information is used to record the size, location, and current content of dynamically allocated memory blocks on the GPU (such as memory allocated by cudaMalloc). This information may change as the program executes.

[0057] Step S164: Use the running information, internal information and memory information as the second execution state information.

[0058] Specifically, all the information collected in the above steps is finally integrated to form complete second execution state information. The second execution state information can be saved to a persistent storage (such as a disk, network storage, etc.) so as to be restored when needed.

[0059] In one embodiment, in step S163, the step of obtaining memory information includes: obtaining static memory information based on static memory area information; and obtaining dynamic memory information based on dynamic memory area information.

[0060] Specifically, a static memory area refers to a memory area whose size and location have been determined when the program is compiled, and is usually used to store global variables and constants. When identifying a static memory area based on static memory area information, it can be achieved by viewing the compiled binary file or using a debugging tool. After determining the location and size of the static memory area, the API provided by the GPU (such as CUDA's cudaMemcpy function) can be used to copy the contents of these areas to the client's memory for recording. A dynamic memory area refers to a memory area that is dynamically allocated and released as needed when the program is running. The size and location of these areas are uncertain at compile time, but are determined by the program as needed at runtime. In some embodiments, a specific memory address can be attempted to be requested when allocating memory, so as to determine the corresponding dynamic memory area information, and the memory can be restored to the original address when restoring. In some embodiments, the memory allocation function provided by the GPU can be used to track dynamic memory allocation, and the memory size, address, and related metadata (such as allocation time, thread to which it belongs, etc.) of each allocation need to be recorded.

[0061] In one embodiment, the step of obtaining dynamic memory information based on dynamic memory area information includes: using API call information related to dynamic memory as dynamic memory area information. Specifically, in this embodiment, the API call information related to dynamic memory is recorded and used as dynamic memory area information. When the recording point is restored, these API calls are executed again in the order and parameters of the records. Since the parameters of the API call (such as the allocation size) are consistent with the original checkpoint, the dynamic memory is likely to be allocated to the same or similar location as when the checkpoint was created.

[0062] In one embodiment, Figure 4 As shown, the present application also provides a method for recovering a GPU application checkpoint, comprising the following steps:

[0063] Step S210, loading checkpoint information.

[0064] Specifically, during the running process of the GPU application, checkpoints can be created in multiple nodes, thereby obtaining multiple checkpoint information. The checkpoint information is created by the method for creating a checkpoint of the GPU application in the above embodiment. When it is necessary to restore the GPU application from the most recent checkpoint, the previously stored checkpoint information needs to be loaded first. That is, the corresponding data is read from the storage medium and deserialized into a format recognizable by the program.

[0065] Step S220: Continue executing the GPU application based on the recovery point and checkpoint information.

[0066] Specifically, after loading the checkpoint information, the GPU application can continue to execute from the recovery point based on the checkpoint information. Checkpoint recovery includes: restoring the execution status of the CPU code and the execution status on the GPU. For example, when restoring the execution status of the CPU code, use the Checkpoint / Restore In Userspace tool to restore the execution status of the CPU code in the GPU application. When restoring the execution status on the GPU, use the debugger API or other tools to access and restore the execution status information of the GPU application on the GPU. The restored information is the same as the information recorded in the above embodiment, and will not be repeated here.

[0067] The above-mentioned GPU application checkpoint recovery method, by loading the stored checkpoint information and continuing to execute the GPU application according to the recovery point and checkpoint information, can achieve rapid recovery and continued execution of the GPU application in the face of hardware failure, software error or other unforeseen events, thereby significantly improving the reliability and stability of the system.

[0068] In one embodiment, the method for restoring a GPU application checkpoint further includes: determining a recovery point by modifying a jump instruction in the GPU application. Specifically, the recovery point is a specific location where the GPU application can continue to execute after an interruption. By modifying the jump instruction in the GPU application, the recovery point can be flexibly set so that the execution of the GPU application can be resumed from this point when needed. In some embodiments, by modifying key instructions such as a program counter (PC), it is ensured that the GPU application starts executing from a recovery point rather than an initial location.

[0069] The following is a detailed description of the method for creating and restoring a GPU application checkpoint in the present application using a specific embodiment. Figure 5 As shown, the GPU application uses the CUDA API to execute code on the GPU. When the GPU application is running, according to the GPU resources required by the GPU running part of the GPU application, the GPU environment variables are set in the client, so as to complete the setting of the program's GPU resource parameters, so as to execute the corresponding code through the remote GPU in the server, and return the result of the GPU API through the remote procedure call. At the same time, the program involving CPU running in the GPU application is run through the local CPU. After the results returned by the remote procedure call are aggregated with the results of the local CPU running, the running of the GPU application can be completed. When creating a checkpoint, a CUDA-GDB session is attached to the client CPU so that the client CPU can debug the GPU application. The client CPU obtains the CPU debugger API to stop the function (kernel) executed in parallel on the GPU. At the same time, the execution state of the CPU and GPU at runtime (the specific state at the current running time, such as the program counter, register content, memory allocation, etc.) and the persistent execution state (the state information saved during the entire execution cycle, such as the initialization configuration, loaded library files, key data, etc.) are saved, and finally the CUDA-GDB session is separated from the client CPU. When performing checkpoint recovery, first patch the jump instructions in the GPU application binary file, then start applying for the corresponding checkpoint information, and at the same time, obtain the CPU debugger API, view and prepare the code for recovery and patching, then restore the execution state and persistent execution state of the CPU and GPU runtime, complete the checkpoint recovery, and separate the corresponding recovery and patched code.

[0070] The creation method and recovery method of the present application have the following advantages:

[0071] Improve the efficiency of checkpoint creation: By improving the checkpoint creation method, the storage time and space overhead of the checkpoint are reduced, ensuring that checkpoint creation does not significantly affect the overall performance of the GPU application in complex computing tasks.

[0072] Enhance the accuracy and speed of the recovery process: This application provides a recovery mechanism that can accurately capture the GPU computing state, ensuring that the GPU application can continue to execute in the shortest time after recovering from a checkpoint without affecting the correctness and consistency of the computing results.

[0073] Improve the flexibility and scalability of checkpoint storage: The checkpoint creation method of this application can efficiently manage checkpoint data according to different application scenarios and requirements to adapt to the application requirements of GPU applications in various environments.

[0074] Enhance the fault tolerance of the system: Through the checkpoint recovery method of this application, GPU applications can quickly recover and continue execution when facing hardware failures, software errors or other unforeseen events, thereby significantly improving the reliability and stability of the system.

[0075] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0076] Based on the same inventive concept, the embodiment of the present application also provides a GPU application checkpoint creation device and a recovery device for implementing the above-mentioned GPU application checkpoint creation method and recovery method. The implementation solution provided by the device to solve the problem is similar to the implementation solution recorded in the above-mentioned method, so the specific limitations in the embodiments of the one or more GPU application checkpoint creation device and recovery device provided below can refer to the above-mentioned limitations on the creation method and recovery method, and will not be repeated here.

[0077] In one embodiment, Figure 6 As shown, a device for creating a checkpoint of a GPU application is provided, comprising: an environment setting module 310, a dynamic library update module 320, a program running module 330, a remote call module 340, a first information recording module 350, a second information recording module 360 ​​and a checkpoint determination module 370, wherein:

[0078] An environment setting module 310, for setting GPU environment variables in the client based on the requirements of the GPU application;

[0079] The dynamic library update module 320 is used to configure the GPU application to call the compiled dynamic library;

[0080] A program running module 330 is used to execute a program related to CPU running in a GPU application program through a CPU of a client;

[0081] A remote calling module 340 is used to execute a program related to GPU operation in a GPU application program through a remote procedure call; wherein the remote procedure call is jointly executed by a server connected to a client;

[0082] A first information recording module 350, used to record first execution state information of the CPU in the client;

[0083] A second information recording module 360, used to record second execution state information of the GPU in the server;

[0084] The checkpoint determination module 370 is configured to determine the checkpoint information based on the first execution status information and the second execution status information.

[0085] In one embodiment, the second information recording module 360 ​​is also used to obtain the running information of the GPU application on the GPU; wherein the running information includes: memory allocation, thread synchronization, and kernel execution status; obtain the internal information of the GPU through the debugger API; wherein the internal information includes: synchronization status, program counter, and call stack; obtain memory information; wherein the memory information includes: static memory information and dynamic memory information; use the running information, internal information, and memory information as the second execution status information.

[0086] In one embodiment, the second information recording module 360 ​​is further used to obtain static memory information based on the static memory area information; and to obtain dynamic memory information based on the dynamic memory area information.

[0087] In one embodiment, the second information recording module 360 ​​is further configured to use API call information related to the dynamic memory as dynamic memory area information.

[0088] In one embodiment, a device for recovering a GPU application checkpoint is provided, comprising: an information loading module and a program execution module, wherein:

[0089] An information loading module, used for loading checkpoint information; wherein the checkpoint information is created by the method for creating a GPU application checkpoint in the above embodiment;

[0090] The program execution module is used to continue executing the GPU application based on the recovery point and checkpoint information.

[0091] In one embodiment, the device for restoring a checkpoint of a GPU application further includes: a recovery point setting module, configured to determine a recovery point by modifying a jump instruction in the GPU application.

[0092] Each module in the above-mentioned creation device and recovery device can be implemented in whole or in part by software, hardware and a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute the operations corresponding to each module above.

[0093] In one embodiment, a computer device is provided. The computer device may be a terminal, and its internal structure diagram may be as follows: Figure 7 As shown. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit and an input device. The processor, the memory and the input / output interface are connected through a system bus, and the communication interface, the display unit and the input device are connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and the external device. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner can be implemented through WIFI, a mobile cellular network, NFC (near field communication) or other technologies. When the computer program is executed by the processor, a creation method and a recovery method are implemented. The display unit of the computer device is used to form a visually visible picture, which can be a display screen, a projection device or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covering the display screen, or a button, trackball or touchpad set on the computer device shell, or an external keyboard, touchpad or mouse.

[0094] Those skilled in the art will understand that Figure 7 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0095] In one embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above-mentioned method embodiments when executing the computer program.

[0096] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the processor executes the computer program, the steps in the above-mentioned method embodiments are implemented.

[0097] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0098] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0099] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A method for creating a GPU application checkpoint, characterized in that: The method comprises: Set GPU environment variables in the client based on the needs of the GPU application; Configure the GPU application to call the compiled dynamic library; Executing, by the CPU of the client, a program in the GPU application program that involves CPU operation; Executing a program in the GPU application program related to GPU operation through a remote procedure call; wherein the remote procedure call is jointly executed by a server connected to the client; Recording first execution state information of the CPU in the client; Recording second execution state information of the GPU in the server; Checkpoint information is determined based on the first execution state information and the second execution state information.

2. The method for creating a GPU application checkpoint according to claim 1, characterized in that: The step of recording the second execution state information of the GPU in the server includes: Obtaining the running information of the GPU application on the GPU; wherein the running information includes: memory allocation, thread synchronization, and kernel execution status; Obtaining internal information of the GPU through a debugger API; wherein the internal information includes: synchronization status, program counter, and call stack; Acquire memory information; wherein the memory information includes: static memory information and dynamic memory information; The running information, the internal information and the memory information are used as the second execution state information.

3. The method for creating a GPU application checkpoint according to claim 2, characterized in that: The step of obtaining memory information includes: Acquire the static memory information based on the static memory area information; The dynamic memory information is acquired based on the dynamic memory area information.

4. The method according to claim 3, characterized in that The step of acquiring the dynamic memory information based on the dynamic memory area information includes: The API call information related to the dynamic memory is used as the dynamic memory area information.

5. A method for recovering a GPU application checkpoint, characterized in that: The method comprises: Loading checkpoint information; wherein the checkpoint information is created by the method for creating a GPU application checkpoint according to any one of claims 1 to 4; The GPU application is continued to be executed based on the recovery point and the checkpoint information.

6. The method for recovering a GPU application checkpoint according to claim 5, characterized in that: The method further comprises: The recovery point is determined by modifying a jump instruction in the GPU application.

7. A device for creating a GPU application checkpoint, characterized in that: The device comprises: Environment setting module, used to set GPU environment variables in the client based on the needs of GPU applications; A dynamic library update module, used to configure the GPU application to call the compiled dynamic library; A program running module, used for executing a program involving CPU running in the GPU application program through the CPU of the client; A remote calling module, used for executing a program related to GPU operation in the GPU application through a remote procedure call; wherein the remote procedure call is jointly executed by a server connected to the client; A first information recording module, used to record first execution state information of the CPU in the client; A second information recording module, used to record second execution state information of the GPU in the server; A checkpoint determination module is used to determine checkpoint information based on the first execution status information and the second execution status information.

8. The device for creating a GPU application checkpoint according to claim 7, characterized in that: The second information recording module is also used to obtain the running information of the GPU application on the GPU; wherein the running information includes: memory allocation, thread synchronization, and kernel execution status; obtain the internal information of the GPU through the debugger API; wherein the internal information includes: synchronization status, program counter, and call stack; obtain memory information; wherein the memory information includes: static memory information and dynamic memory information; use the running information, the internal information, and the memory information as the second execution status information.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images