A GPU multi-threaded log storage processing method

Abstract

The present application relates to the field of electronic digital data processing technology, and more particularly to a method for processing multi-threaded simultaneous log storage on a GPU. The method comprises: in response to a request from a first thread of the GPU to store a first log, assigning a first line number to the first log; storing the first log starting from the starting address corresponding to the first line number; if the first log has not yet been fully stored and the first thread is cut off by a second thread, and the second thread needs to store a second log, recording the first line number and the first interrupt address corresponding to the first log, and assigning a second line number to the second log; storing the second log starting from the starting address corresponding to the second line number; if the second log has not yet been fully stored and the second thread is cut off by the first thread, recording the second line number and the interrupt address corresponding to the second log, and continuing to store the unstored portion of the first log starting from the first interrupt address. The present invention solves the problem of log confusion in multi-threaded scenarios.

Description

Technical Field

[0001] The present invention relates to the technical field of electronic digital data processing, and in particular to a processing method for GPU multi-threaded simultaneous log storage. Background Art

[0002] In the prior art, logs are printed in bytes. In a multi-threaded scenario, the following problem may occur: a thread (for example, thread a) is cut off by another thread (for example, thread b) during log printing, causing the printed log of thread b to be inserted inside a log of thread a, resulting in log printing confusion. To solve this log confusion problem, the prior art adopts a method of allocating different log storage spaces for different threads, that is, different threads write to different log files. However, this method requires more storage space and also results in more log files to be managed and aggregated. Summary of the Invention

[0003] The present invention aims to provide a method for processing GPU multi-threaded simultaneous log storage to solve the problem in the prior art that more storage space is required and more log files need to be managed and aggregated.

[0004] According to the present invention, a method for processing GPU multi-threaded simultaneous log storage is provided, the method comprising the following steps:

[0005] S100 , in response to a demand of a first thread of a GPU to store a first log, assign a first line number to the first log; when the first line number is assigned to the first log, a storage space size corresponding to the first line number is d1 .

[0006] S200 , storing the first log in a storage space corresponding to the first row number starting from a starting address corresponding to the first row number.

[0007] S300: If the first log has not been stored completely, the first thread of the GPU is cut off by the second thread of the GPU, and the second thread of the GPU needs to store the second log, then enter S400.

[0008] S400: Record a first line number and a first interrupt address addr1 corresponding to the first log when the first thread of the GPU is cut off by the second thread of the GPU, and assign a second line number to the second log; the second line number is the line number next to the first line number; when the second line number is assigned to the second log, the size of the storage space corresponding to the second line number is d2.

[0009] S500 : Store the second log in a storage space corresponding to the second row number starting from a start address corresponding to the second row number.

[0010] S600: If the second log is not completely stored and the second thread of the GPU is cut off by the first thread of the GPU, record the second line number and the interrupt address addr3 corresponding to the second log when the second thread of the GPU is cut off by the first thread of the GPU, and continue to store the unstored portion of the first log in the storage space corresponding to the first line number starting from addr1.

[0011] Compared with the prior art, the present invention has at least the following beneficial effects:

[0012] The processing method for GPU multi-threaded simultaneous log storage of the present invention can solve the log confusion problem in a multi-threaded scenario. Specifically, when a first thread of the GPU has a need to store a first log, a line number (i.e., a first line number) is assigned to the first log, and a storage space size d1 corresponds to the first line number; the first log is stored starting from a starting address corresponding to the first line number; if the first thread is cut off by a second thread during the process of storing the first log, the first line number and an interruption address corresponding to the first log are recorded, and the line number next to the first line number (i.e., a second line number) is assigned to a second log with a storage need of the second thread, and a storage space size d2 corresponds to the second line number, and the second log is stored starting from the starting address corresponding to the second line number; if the second thread is subsequently cut off by the first thread, the first log is stored again starting from the interruption address corresponding to the first log in the storage space corresponding to the first line number. Therefore, even if the first thread is cut off by the second thread during the log printing process, the printed log of the second thread will not be inserted into a log of the first thread, which solves the problem of log printing confusion. Moreover, in the present invention, multi-threaded writing is a log file, and the problem of log printing confusion is solved by introducing line numbers, corresponding a storage space for each line number, and binding the line number with the log. There is no problem of requiring more storage space and having more log files to be managed and aggregated when solving the log confusion problem in the multi-threaded scenario by using the method of dividing different log storage spaces for different threads in the prior art. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0014] Figure 1 This is a flowchart of a method for processing GPU multi-threaded simultaneous log storage provided by the first embodiment of the present invention. DETAILED DESCRIPTION

[0015] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of the present invention. It should be noted that the first, second, third and fourth in the following text do not represent a sequential relationship, but are for distinguishing different threads or logs or line numbers.

[0016] Example 1:

[0017] According to this embodiment, a method for processing GPU multi-threaded simultaneous log storage is provided, the method comprising the following steps: Figure 1 As shown:

[0018] S100 , in response to a demand of a first thread of a GPU to store a first log, assign a first line number to the first log; when the first line number is assigned to the first log, a storage space size corresponding to the first line number is d1 .

[0019] In this embodiment, the line number is a preset global variable. Each time a line number is assigned to a log, the line number value is increased by 1. When a new log is to be stored, the current line number is assigned to the new log. For example, the initial value of the line number is 1. When any log of any thread of the GPU needs to be stored, the current line number (i.e., 1) is assigned to the first log to be stored. When a second log needs to be stored, regardless of whether the second log and the first log are generated by the same thread of the GPU, the current line number (i.e., 2) is assigned to the second log to be stored. When a third log needs to be stored, regardless of whether the third log and the first and second logs are generated by the same thread of the GPU, the current line number (i.e., 3) is assigned to the third log to be stored. And so on. In this embodiment, if the space size corresponding to the current line number plus the size of the log to be printed is greater than the total size of the log space, the line number is rolled back to the initial value of the line number (if the initial value of the line number is 0, the line number is rolled back to 0).

[0020] As a first specific implementation, the storage space corresponding to each row number has the same size, which is the preset maximum storage space for a single log.

[0021] As a second specific implementation, the storage space corresponding to each line number is the storage space occupied by the log corresponding to the line number. The storage space occupied by the log is a known value. For example, the log corresponding to the first line number is the first log, and the storage space occupied by the first log is 256 bytes. Then the storage space corresponding to the first line number is also 256 bytes. For another example, the log corresponding to the first line number is the first log, and the storage space occupied by the first log is 32 bytes. Then the storage space corresponding to the first line number is also 32 bytes.

[0022] In this embodiment, the starting address corresponding to the next row number is the next address of the last address corresponding to the previous row number. For example, if the second row number is the next row number of the first row number, then the starting address corresponding to the second row number is the next address of the last address corresponding to the first row number.

[0023] S200 , storing the first log in a storage space corresponding to the first row number starting from a starting address corresponding to the first row number.

[0024] As a specific implementation, the starting address corresponding to the first row number is 0, so the first log is stored starting from 0.

[0025] S300: If the first log has not been stored completely, the first thread of the GPU is cut off by the second thread of the GPU, and the second thread of the GPU needs to store the second log, then enter S400.

[0026] For example, the starting address corresponding to the first line number is 0, the storage space occupied by the first log is 256 bytes, and the offset corresponding to the interrupt address corresponding to the first log when the first thread of the GPU is cut off by the second thread of the GPU is 128 bytes, which means that half of the storage of the first log in the storage space corresponding to the first line number is completed.

[0027] In this embodiment, a thread being cut off means that the operating system or the operating environment switches from the currently executing thread to another thread for execution, and the thread includes an interrupt handling task; those skilled in the art know that any thread scheduling strategy in the prior art falls within the scope of protection of the present invention, for example, a thread scheduling strategy based on priority or a thread scheduling strategy based on time slice rotation.

[0028] As an optional specific implementation, if the first log has not been stored yet, the first thread of the GPU is cut off by the second thread of the GPU, but the second thread of the GPU does not have the need to store the second log, it is determined that there will be no problem of log printing confusion, and the log printing method in the prior art can be executed; optionally, if the second thread of the GPU does not have the need to print the log, the log is not stored during the execution of the second thread of the GPU until the second thread of the GPU is cut off by the first thread of the GPU, and the unstored log of the first thread of the GPU continues to be stored.

[0029] In this embodiment, if the first thread of the GPU is not cut off by other threads of the GPU during the process of storing the first log, the first log is stored until the first log is completely stored.

[0030] In this embodiment, if the first thread of the GPU still needs to store a fourth log after the first log is stored, and the first thread of the GPU has not been cut off, then the process proceeds to S310; the fourth log is the next log generated by the first thread and located after the first log.

[0031] S310: Assign a second line number to the fourth log.

[0032] S320 : Store the fourth log in the storage space corresponding to the second row number starting from the starting address corresponding to the second row number.

[0033] S400: Record a first line number and a first interrupt address addr1 corresponding to the first log when the first thread of the GPU is cut off by the second thread of the GPU, and assign a second line number to the second log; the second line number is the line number next to the first line number; the size of the storage space corresponding to the second line number is d2.

[0034] In this embodiment, the interval between adjacent row numbers is 1. If the first row number is 1, then the second row number is 2.

[0035] S500 : Store the second log in a storage space corresponding to the second row number starting from a start address corresponding to the second row number.

[0036] S600: If the second log is not completely stored and the second thread of the GPU is cut off by the first thread of the GPU, record the second line number and the interrupt address addr3 corresponding to the second log when the second thread of the GPU is cut off by the first thread of the GPU, and continue to store the unstored portion of the first log in the storage space corresponding to the first line number starting from addr1.

[0037] In this embodiment, when the second log is not completely stored and the second thread of the GPU is switched off by the first thread of the GPU, the second line number and the interrupt address addr3 corresponding to the second log when the second thread of the GPU is switched off by the first thread of the GPU are recorded. Therefore, when the second thread of the GPU is subsequently switched back, the unstored portion of the second log is stored in the storage space corresponding to the second line number starting from addr3.

[0038] In this embodiment, when the first thread is switched off, the line number corresponding to the first log (i.e., the first line number) and the interrupt address corresponding to the first log when the first thread is switched off by the second thread (i.e., the first interrupt address) are recorded. If the second thread of the GPU is switched back to the first thread of the GPU, the unstored portion of the first log continues to be stored starting from the first interrupt address.

[0039] In this embodiment, if the second log has been stored before the second thread of the GPU is cut off by the first thread of the GPU (that is, the storage process of the second log is not interrupted), then when the second thread of the GPU is cut off by the first thread of the GPU, there is no need to record information related to the second log.

[0040] In this embodiment, if the second log has been stored before the second thread of the GPU is cut off by the first thread of the GPU (i.e., the storage process of the second log has not been interrupted), but the second thread of the GPU generates a new log before being cut off by the first thread, then it is necessary to determine whether the storage process of the newly generated log of the second thread is interrupted when the second thread is cut off by the first thread. As a specific embodiment, S600 also includes: if the second log is stored, and the second thread of the GPU needs to store a fifth log, and the second thread of the GPU has not been cut off, assigning a third line number to the fifth log, and storing the fifth log starting from the starting address corresponding to the third line number in the storage space corresponding to the third line number; the fifth log is the next log generated by the second thread of the GPU and located after the second log. Furthermore, if the fifth log has not been stored yet and the second thread of the GPU is cut off by the first thread of the GPU, the third line number and the interrupt address addr4 corresponding to the fifth log when the second thread of the GPU was cut off by the first thread of the GPU are recorded, and the unstored portion of the first log is continued to be stored starting from addr1 in the storage space corresponding to the first line number. Therefore, when the second thread of the subsequent GPU is switched back, the unstored portion of the fifth log is stored in the storage space corresponding to the third row number starting from addr4.

[0041] In this embodiment, if the second log is not completely stored and the second thread of the GPU is switched off by the first thread of the GPU, the unstored portion of the first log is continued to be stored in the storage space corresponding to the first line number starting from addr1. However, if the first log is not completely stored again and the first thread of the GPU is switched off for the second time by another thread of the GPU, the first line number and the first interrupt address addr6 corresponding to the first log when the first thread of the GPU is switched off for the second time are recorded, so that the unstored portion of the first log can be continued to be stored in the storage space corresponding to the first line number starting from addr6 when the first thread is switched back later.

[0042] The method for processing GPU multi-threaded simultaneous log storage in this embodiment can solve the log confusion problem in multi-threaded scenarios. Specifically, when a first thread of the GPU needs to store a first log, a line number (i.e., the first line number) is assigned to the first log, and the storage space size corresponding to the first line number is d1. The first log is stored starting at the starting address corresponding to the first line number. If the first thread is cut off by a second thread during the storage of the first log, the first line number and the interruption address corresponding to the first log are recorded, and the line number next to the first line number (i.e., the second line number) is assigned to the second log that needs to be stored by the second thread. The storage space size of the second line number is d2, and the second log is stored starting at the starting address corresponding to the second line number. If the storage of the second log is completed and the second thread is cut off by the first thread, the first log is stored again starting from the interruption address corresponding to the first log in the storage space corresponding to the first line number. Therefore, even if the first thread is cut off by the second thread during the log printing process, the printed log of the second thread will not be inserted into a log of the first thread, which solves the problem of log printing confusion. Moreover, in this embodiment, multiple threads write to a log file, and the problem of log printing confusion is solved by introducing line numbers, corresponding a storage space to each line number, and binding the line number to the log. There is no problem of requiring more storage space and having more log files to be managed and aggregated when solving the log confusion problem in the multi-threaded scenario by dividing different log storage spaces for different threads in the prior art.

[0043] As a specific implementation, S600 further includes: if the second log has not been stored completely, the second thread of the GPU is cut off by the third thread of the GPU, and the third thread of the GPU needs to store the third log, then entering S700.

[0044] S700 , record the second line number and the interrupt address addr2 corresponding to the second log when the second thread of the GPU is cut off by the third thread of the GPU, and assign a third line number to the third log; the third line number is the line number next to the second line number.

[0045] S800 , storing the third log in a storage space corresponding to the third row number starting from a starting address corresponding to the third row number.

[0046] S900: If the third thread of the GPU is cut off by the second thread of the GPU, continue to store the unstored portion of the second log in the storage space corresponding to the second row number starting from addr2.

[0047] In this embodiment, if the third log has already been stored when the third thread of the GPU is cut off by the second thread of the GPU, information related to the third log does not need to be recorded. If the third log has not been stored when the third thread of the GPU is cut off by the second thread of the GPU, information related to the third log is also recorded, including the line number corresponding to the third log (i.e., the third line number) and the interrupt address addr5 corresponding to the third log when the third thread of the GPU is cut off by the second thread of the GPU. If the third log has already been stored when the third thread of the GPU is cut off by the second thread of the GPU, but the third thread of the GPU generates a new log before it is cut off, and the process of storing the newly generated log in the storage space corresponding to the corresponding line number is interrupted, information related to the newly generated log is also recorded, including the line number corresponding to the newly generated log and the interrupt address corresponding to the newly generated log when the third thread of the GPU is cut off by the second thread of the GPU.

[0048] As a specific implementation, after S900, the method further includes:

[0049] S1000: If the second thread of the GPU is cut off by the first thread of the GPU, continue to store the unstored portion of the first log in the storage space corresponding to the first row number starting from addr1.

[0050] In this embodiment, S900 further includes: if the third thread of the GPU is cut off by the first thread of the GPU, continuing to store the unstored portion of the first log in the storage space corresponding to the first row number starting from addr1.

[0051] In this embodiment, S900 also includes: if the third thread of the GPU is cut off by the fourth thread of the GPU, and the fourth thread has a need to store the sixth log, then the current row number is assigned to the sixth log, and the sixth log is stored in the storage space corresponding to the corresponding row number starting from the starting address of the corresponding row number.

[0052] Example 2

[0053] In order to solve the problem of GPU firmware log loss caused by using HBM as log storage space between GPU startup and HBM initialization in the prior art, or the problem of log in SRAM being quickly overwritten when using SRAM as log storage space, this embodiment, based on the first embodiment, further includes the following steps before S100:

[0054] P100, after the GPU is powered on, stores the GPU firmware log in the first storage space SRAM, which is the memory space where the GPU firmware runs.

[0055] In this embodiment, after the GPU is powered on, the GPU firmware starts running, and the SRAM also has a storage function. The storage location of the GPU firmware log is set to the SRAM. Specifically, storing the GPU firmware log in the first storage space SRAM includes:

[0056] P110, determine the starting address paaddr1 where the GPU firmware log is stored in SRAM.

[0057] In this embodiment, the sram determines a physical address included therein as paaddr1.

[0058] P120, determine the storage space size len1 in SRAM for GPU firmware log.

[0059] Optionally, len1 is a value set in advance according to actual needs, which is the storage space size that can meet the storage requirements of GPU firmware logs generated between GPU startup and HBM initialization.

[0060] P130, points the log storage pointer to the location of paaddr1 in sram.

[0061] In this embodiment, the log storage pointer is pointed to the position of paaddr1 in SRAM. Then, when a log needs to be stored, the log is stored in SRAM starting from the position of paaddr1. The position of the log storage pointer will change as the log is stored, and the position pointed to by the log storage pointer is the starting address of the subsequent newly generated log storage.

[0062] P200: After the kernel driver kmd is loaded, if the page table of the second storage space HBM is established, kmd sends the information that the HBM page table is established to the GPU firmware.

[0063] In this embodiment, the page table of the HBM includes a mapping relationship between the physical addresses and virtual addresses included in the HBM.

[0064] In this embodiment, after the kernel driver kmd is loaded, if the page table of the second storage space HBM is not established yet, it waits until the page table of HBM is established, and kmd sends the information that the page table of HBM is established to the GPU firmware.

[0065] P300, after the GPU firmware receives the information that the page table of HBM is established sent by kmd, it sends the information for applying for HBM space to kmd, and the information for applying for HBM space includes the virtual address vaaddr2 and the storage space size len2.

[0066] P400, if the GPU firmware cannot access HBM through the virtual address, then kmd obtains the physical address paaddr2 corresponding to vaaddr2 according to the received information for applying for HBM space and the page table of HBM, and sends paaddr2 to the GPU firmware.

[0067] In this embodiment, len1 < len2, that is, the storage space applied by kmd in HBM is larger than the storage space size of the GPU firmware log in the above sram; if the storage space size occupied by the log stored in HBM is equal to len2, then the log is cyclically stored starting from the position of paaddr2 in HBM to realize the reuse of the storage space in HBM, and since the log corresponding to the position closer to the position of paaddr2 in HBM has an earlier generation time and has been read, therefore, even if the newly generated log overwrites the log stored in the position closer to the position of paaddr2 in HBM, it does not affect debugging.

[0068] Those skilled in the art know that any method for obtaining the physical address according to the virtual address and the page table in the prior art falls within the protection scope of the present invention.

[0069] In this embodiment, P400 further includes: if the GPU firmware can access HBM through the virtual address, then there is no need for the process of kmd obtaining the physical address corresponding to vaaddr2, but instead, the log storage pointer is pointed to the position in HBM with the address corresponding to vaaddr2 as the starting address and an offset of len', and the GPU firmware log stored in sram is moved to HBM starting from the address corresponding to vaaddr2 in HBM.

[0070] P500, after the GPU firmware receives paaddr2 sent by kmd, it points the log storage pointer to the position in HBM with paaddr2 as the starting address and an offset of len'; len' is the storage space size occupied by the GPU firmware log stored in sram.

[0071] In this embodiment, the log storage pointer is pointed to a position in the HBM with paaddr2 as the starting address and len' as the offset, so that the subsequently generated logs can be stored in the storage space after the position in the HBM.

[0072] For P600, the GPU firmware uses paaddr2 as the starting address to move the GPU firmware log stored in sram to HBM.

[0073] In this embodiment, when the GPU firmware cannot access the HBM through the virtual address, the log storage pointer is first pointed to the position in the HBM with paaddr2 as the starting address and len' as the offset, and then the operation of storing the GPU firmware log stored in the sram in the HBM is performed. This can avoid the impact of the process of migrating the GPU firmware log stored in the sram from the sram to the HBM on the storage of subsequently generated logs in the HBM. Compared with the method of storing the GPU firmware log stored in the sram in the HBM and then pointing the log storage pointer to the HBM (in the process of executing the log migration, new logs may be generated, and this method enables the new logs to be stored in the sram), this embodiment can reduce the amount of migrated logs and improve the efficiency of log storage.

[0074] In addition to the advantages of the first embodiment, the present embodiment uses the memory space SRAM where the GPU firmware runs as the log storage space after the GPU is powered on, thereby realizing the storage of the GPU firmware log in SRAM and solving the GPU firmware log loss problem caused by using HBM as the log storage space in the prior art; moreover, after the kernel driver kmd is loaded, the present embodiment notifies the GPU firmware of the completion of the page table establishment of the HBM if the page table of the second storage space HBM is established, and after the GPU firmware receives the completion of the page table establishment of the HBM, it sends the information of applying for HBM space including the virtual address and the storage space size to the kernel driver kmd; if the GPU firmware cannot access the HBM through the virtual address, the kernel driver kmd receives the information of applying for HBM space sent by the GPU firmware and determines the corresponding virtual address according to the virtual address and the page table of the HBM included in the information. The physical address is returned to the GPU firmware to point the log storage pointer to the position with paaddr2 as the starting address and len' as the offset in the HBM, and the GPU firmware stores the GPU firmware log stored in the SRAM in the HBM with the physical address as the starting address. Thus, not only the subsequently generated logs can be stored in the HBM starting from the position with paaddr2 as the starting address and len' as the offset, but also the migration of the GPU firmware log stored in the SRAM from the SRAM to the HBM is realized, and the migration process does not affect the storage of the subsequently generated logs in the HBM. In this embodiment, the HBM is used as the log storage space after the HBM page table is established. The storage space of the HBM is larger than that of the SRAM, and the storage space that can be applied for log storage in the HBM is larger, which can solve the problem of the log in the SRAM being quickly overwritten when the SRAM is used as the storage space for the log in the prior art.

[0075] As an optional specific implementation, the method further includes: P700, if a storage space for storing logs in the HBM fails, proceed to S800.

[0076] P800: Reload the kernel driver kmd. If the page table of the second storage space HBM is rebuilt, kmd sends the information that the HBM page table is rebuilt to the GPU firmware.

[0077] P900: After receiving the information from kmd that the HBM page table has been rebuilt, the GPU firmware resends the information requesting HBM space to kmd.

[0078] P1000, if the GPU firmware cannot access the HBM through the virtual address, kmd obtains the new physical address paaddr'2 corresponding to vaaddr2 based on the received information about applying for HBM space and the re-established HBM page table, and sends paaddr'2 to the GPU firmware.

[0079] In this embodiment, P1000 also includes: if the GPU firmware can access the HBM through the virtual address, the process of kmd obtaining the new physical address corresponding to vaaddr2 is no longer required, but the log storage pointer is pointed to the position in the HBM with the address corresponding to vaaddr2 as the starting address and len' as the offset, and the GPU firmware uses the address corresponding to vaaddr2 in the HBM as the starting address to move the GPU firmware log stored in sram to the HBM.

[0080] P1100, after receiving paaddr'2 sent by kmd, the GPU firmware points the log storage pointer to the location in HBM with paaddr'2 as the starting address and len' as the offset, and moves the GPU firmware log stored in sram to HBM with paaddr'2 as the starting address.

[0081] Based on P700-P1100, if the storage space for storing logs in the HBM fails, the newly created HBM page table after kmd is reloaded will no longer contain the above-mentioned failed storage space for storing logs, that is, the newly created HBM page table has changed. Even if the information requesting HBM space sent by the GPU firmware of this embodiment to kmd includes the same virtual address vaaddr2, when the GPU firmware cannot access the HBM through the virtual address, the physical address (i.e. paaddr'2) obtained by kmd based on vaaddr2 and the newly created HBM page table is no longer the previous physical address (i.e. paaddr2), which can avoid the problem of storing logs in the failed storage space.

[0082] As an optional specific implementation, the method further includes: E700, if a storage space for storing logs in the HBM fails, proceeding to E800;

[0083] E800, repowers the GPU and stores the GPU firmware log in the first storage space SRAM.

[0084] E900: Reload the kernel driver kmd. If the page table of the second storage space HBM is rebuilt, kmd sends the information that the HBM page table is rebuilt to the GPU firmware.

[0085] E1000, after the GPU firmware receives the information sent by kmd that the HBM page table reconstruction is completed, it resends the information requesting HBM space to kmd.

[0086] E1100: If the GPU firmware cannot access the HBM through the virtual address, kmd obtains the new physical address paaddr'2 corresponding to vaaddr2 based on the received information about applying for HBM space and the re-established HBM page table, and sends paaddr'2 to the GPU firmware.

[0087] In this embodiment, E1100 also includes: if the GPU firmware can access the HBM through the virtual address, the process of kmd obtaining the new physical address corresponding to vaaddr2 is no longer required, but the log storage pointer is pointed to the position in the HBM with the address corresponding to vaaddr2 as the starting address and len' as the offset, and the GPU firmware uses the address corresponding to vaaddr2 in the HBM as the starting address to move the GPU firmware log stored in sram to the HBM.

[0088] E1200, after receiving paaddr'2 sent by kmd, the GPU firmware points the log storage pointer to the location in HBM with paaddr'2 as the starting address and len' as the offset, and moves the GPU firmware log stored in SRAM to HBM with paaddr'2 as the starting address.

[0089] Based on E700-E1200, if the storage space for storing logs in HBM fails, the newly established HBM page table after the GPU is powered on again will no longer contain the above-mentioned failed storage space for storing logs, that is, the newly established HBM page table has changed. Even if the information requesting HBM space sent by the GPU firmware of this embodiment to kmd includes the same virtual address vaaddr2, when the GPU firmware cannot access HBM through the virtual address, the physical address (i.e. paaddr'2) obtained by kmd based on vaaddr2 and the newly established HBM page table is no longer the previous physical address (i.e. paaddr2), which can avoid the problem of storing logs in the failed storage space.

[0090] Although some specific embodiments of the present invention have been described in detail by way of example, it should be understood by those skilled in the art that the above examples are for illustration only and are not intended to limit the scope of the present invention. It should also be understood by those skilled in the art that various modifications may be made to the embodiments without departing from the scope and spirit of the present invention. The scope of the present invention is defined by the appended claims.

Claims

1. A GPU multi-threaded log storage processing method, characterized in that: The multithreaded write is a log file, and the method comprises the following steps: S100, in response to a demand of a first thread of a GPU to store a first log, assigning a first line number to the first log; when the first line number is assigned to the first log, a storage space size corresponding to the first line number is d1; S200, storing the first log in a storage space corresponding to the first row number starting from a starting address corresponding to the first row number; S300: If the first log has not been stored yet, the first thread of the GPU is cut off by the second thread of the GPU, and the second thread of the GPU needs to store the second log, then enter S400; S400, recording a first line number and a first interrupt address addr1 corresponding to the first log when the first thread of the GPU is cut off by the second thread of the GPU, and assigning a second line number to the second log; the second line number is the line number next to the first line number; when the second line number is assigned to the second log, the size of the storage space corresponding to the second line number is d2; S500: Store the second log in a storage space corresponding to the second row number starting from a starting address corresponding to the second row number; S600: If the second log is not completely stored and the second thread of the GPU is cut off by the first thread of the GPU, record the second line number and the interrupt address addr3 corresponding to the second log when the second thread of the GPU is cut off by the first thread of the GPU, and continue to store the unstored portion of the first log in the storage space corresponding to the first line number starting from addr1; S600 further includes: if the storage of the second log is complete and the second thread of the GPU needs to store a fifth log, and the second thread of the GPU has not been switched away, assigning a third row number to the fifth log, and storing the fifth log in a storage space corresponding to the third row number starting from a starting address corresponding to the third row number; the fifth log is a next log generated by the second thread of the GPU and located after the second log, and the third row number is a row number next to the second row number.

2. The method for processing GPU multi-threaded simultaneous log storage according to claim 1, characterized in that: If the fifth log has not been completely stored and the second thread of the GPU is cut off by the first thread of the GPU, the third line number and the interrupt address addr4 corresponding to the fifth log when the second thread of the GPU is cut off by the first thread of the GPU are recorded, and the unstored portion of the first log is continued in the storage space corresponding to the first line number starting from addr1.

3. The GPU multi-threaded simultaneous log storage processing method according to claim 1, characterized in that: S600 further includes: if the second log has not been stored yet, the second thread of the GPU is cut off by the third thread of the GPU, and the third thread of the GPU needs to store the third log, then entering S700; S700, recording the second line number and the interrupt address addr2 corresponding to the second log when the second thread of the GPU is cut off by the third thread of the GPU, and assigning a third line number to the third log; the third line number is the line number next to the second line number; S800, storing the third log in the storage space corresponding to the third row number starting from the starting address corresponding to the third row number; S900: If the third thread of the GPU is cut off by the second thread of the GPU, continue to store the unstored portion of the second log in the storage space corresponding to the second row number starting from addr2.

4. The method for processing GPU multi-threaded simultaneous log storage according to claim 3, characterized in that: After S900, the method further includes: S1000: If the second thread of the GPU is cut off by the first thread of the GPU, continue to store the unstored portion of the first log in the storage space corresponding to the first row number starting from addr1.

5. The GPU multi-threaded simultaneous log storage processing method according to claim 1, characterized in that: S300 further includes: if the first thread of the GPU is not cut off by other threads of the GPU during the process of storing the first log, storing the first log until the first log is completely stored.

6. The method for processing GPU multi-threaded simultaneous log storage according to claim 5, characterized in that: S300 further includes: if the first thread of the GPU still needs to store a fourth log after the first log is stored, and the first thread of the GPU has not been switched off, then proceeding to S310; the fourth log is the next log generated by the first thread and located after the first log; S310, assigning a second line number to the fourth log; S320 : Store the fourth log in the storage space corresponding to the second row number starting from the starting address corresponding to the second row number.

7. The method for processing GPU multi-threaded simultaneous log storage according to claim 1, characterized in that: Both d1 and d2 are preset maximum storage spaces for a single log.

8. The method for processing GPU multi-threaded simultaneous log storage according to claim 1, characterized in that: d1 is the storage space occupied by the first log, and d2 is the storage space occupied by the second log.

Images