Log disk landing method and device, DPU, network card, equipment, medium and product

Abstract

The application relates to a log disk writing method and device, a DPU, a network card, equipment, a medium and a product, and is applied to a master control processing unit of a heterogeneous system, wherein the heterogeneous system comprises a master control processing unit and at least one heterogeneous computing node. The method comprises the following steps: when any one of a plurality of preset trigger conditions is met, a log disk writing request is generated; the plurality of preset trigger conditions comprise a period trigger condition based on a time period, a graceful power-off trigger condition based on a system stop or power-off event and a manual trigger condition based on a user input instruction; the log disk writing request is added to a log disk writing request queue; according to a preset scheduling strategy, the log disk writing request is acquired from the log disk writing request queue, log data is read from a target log memory area according to the acquired log disk writing request, and the log data is written into a persistent storage medium.

Description

Technical Field

[0001] This application relates to the field of computer network communication technology, specifically to a log writing method, apparatus, data processing unit (DPU), network interface card, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] With the continuous development of heterogeneous computing technology, computing architectures containing various types of processing units are becoming increasingly common. For example, smart NICs and data processing units (DPUs) typically integrate multi-core processors, onboard storage resources, and can run an operating system independently. Similarly, GPU / NPU heterogeneous acceleration systems also contain various types of processing units. These heterogeneous systems typically include a main control processing unit and multiple heterogeneous computing nodes (such as system control processors, integrated management units, small core processing units, trusted firmware execution environments, etc.). The main control processing unit runs a complete operating system, possessing file system access capabilities and persistent storage management capabilities, while each heterogeneous computing node is usually used only for specific real-time control or data processing tasks. Their operating environment resources are limited, and they often lack independent file systems or persistent storage capabilities.

[0003] In traditional log persistence solutions for heterogeneous systems, although the main control unit has the ability to run an operating system and manage storage resources, log persistence operations often rely on external hosts or dedicated hardware. This results in a lengthy log management chain, complex system coordination, and each heterogeneous computing node lacks its own independent file system and persistence capabilities. A large number of critical logs generated during operation can only be temporarily stored in memory, lacking a unified management and persistence mechanism. Furthermore, when logs are temporarily stored in memory, in the event of abnormal conditions (such as unexpected power outages, abnormal restarts, or system crashes), the log data in memory often has not yet completed the writing process to persistent storage media. This leads to the loss of critical log information along with the system state, failing to provide reliable evidence for subsequent fault location, problem tracing, and system recovery. In addition, the single log persistence triggering method makes it difficult to meet the differentiated requirements for real-time log persistence, reliability, and system overhead under different operating scenarios. For example, periodic triggering can effectively control overhead during normal system operation, but it cannot guarantee timely log saving in emergency scenarios such as system power failure; while persisting logs only when triggered by emergency events cannot meet the continuous log retention requirements under normal operating conditions. Summary of the Invention

[0004] This application provides a log writing method, apparatus, data processing unit (DPU), network interface card, computer equipment, computer-readable storage medium, and computer program product to achieve centralized, reliable, flexible, and stable persistent storage of logs from heterogeneous systems.

[0005] According to a first aspect, embodiments of this application provide a log persistence method, applied to a heterogeneous system containing multiple heterogeneous computing nodes, the method comprising:

[0006] A log write request is generated when any one of a variety of preset trigger conditions is met; wherein, the variety of preset trigger conditions include periodic trigger conditions based on time period, graceful power-down trigger conditions based on system stop or power-down events, and manual trigger conditions based on user input commands. Add the log write-to-disk request to the log write-to-disk request queue; According to a preset scheduling strategy, the log write request is obtained from the log write request queue, the log data is read from the target log memory area according to the obtained log write request, and the log data is written to the persistent storage medium; wherein, the heterogeneous system includes multiple log memory areas, and each log memory area stores the log data generated by the main control processing unit or the corresponding heterogeneous computing node according to a preset log format.

[0007] In one specific implementation, reading log data from the target log memory region according to the obtained log write request includes: When the log write-to-disk request queue is not empty, determine whether the log write-to-disk function is enabled. If the log write-to-disk function is enabled, then determine whether the dump mask is 0; the dump mask is used to indicate the log memory area that needs to be written to disk. If the dump mask is not 0, it is determined whether a log write request is currently being executed; If no log write request is currently in progress, log data is read from at least one log memory region according to the dump mask.

[0008] In one specific implementation, reading log data from the target log memory region according to the obtained log write request includes: During the execution of the log write-to-disk request, the execution time of the log write-to-disk request is monitored. If the execution time exceeds a preset timeout threshold, the execution of the log write-to-disk request is terminated, and the dump mask is updated according to the current execution result of the log write-to-disk request. After the log write request is completed normally, the dump mask is set to 0.

[0009] In one specific implementation, reading log data from the target log memory region according to the obtained log write request includes: When reading log data from the target log memory region, a unified abstract view of the memory log is obtained, and log data is read from the target log memory region according to the unified abstract view of the memory log; wherein, the unified abstract view of the memory log includes descriptive information of each log memory region, and the descriptive information includes at least one of the following: physical address of the log memory region, region size, and log format.

[0010] In one specific embodiment, the method includes: A periodic timer is set up, which repeatedly generates timing signals at preset time intervals; wherein the preset time interval is dynamically configured according to user input instructions. Each time the timing signal is generated, if the periodic log write-to-disk function is enabled, then the periodic triggering condition is determined to be met.

[0011] In one specific embodiment, the method includes: The system status information in the preset memory status address is obtained. If the system status information indicates that the system has stopped or is powered off, it is determined that the graceful power-off trigger condition is met. The system status information is written to the memory status address by the main control processing unit or the heterogeneous computing node.

[0012] In one specific embodiment, the method includes: When the graceful power-down triggering condition is met, after writing the log data to the persistent storage medium, a file system synchronization operation is performed; and after the file system synchronization operation is completed, the system stop or power-down process is triggered.

[0013] In one specific embodiment, the method includes: The system receives user input commands, parses the trigger parameters carried by the user input commands, and determines that the manual triggering conditions are met if the trigger parameters are preset valid trigger values.

[0014] According to a second aspect, embodiments of this application provide a log writing device, which is integrated into the main control processing unit of a heterogeneous system and is used to execute the log writing method as described in the first aspect. The log writing device includes: The event monitoring unit is used to generate a log write request when any one of a variety of preset trigger conditions is met; the variety of preset trigger conditions include periodic trigger conditions based on time periods, graceful power-down trigger conditions based on system stop or power-down events, and manual trigger conditions based on user input commands. The log write-to-disk scheduling unit is used to add the log write-to-disk request to the log write-to-disk request queue; The log write-to-disk execution unit is used to obtain the log write-to-disk request from the log write-to-disk request queue according to a preset scheduling strategy, read log data from the target log memory area according to the obtained log write-to-disk request, and write the log data to the persistent storage medium. The heterogeneous system includes multiple log memory areas, each of which stores log data generated by the main control processing unit or the corresponding heterogeneous computing node according to a preset log format.

[0015] According to a third aspect, embodiments of this application provide a data processing unit, including the log writing device as described in the second aspect.

[0016] According to a fourth aspect, embodiments of this application provide a network interface card (NIC) including the data processing unit as described in the third aspect.

[0017] According to a fifth aspect, embodiments of this application provide a computer device, including a host CPU and a network interface card (NIC) as described in the first aspect, wherein the host CPU is used to process data scheduled by the NIC.

[0018] According to a fifth aspect, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the log writing method as described in the first aspect.

[0019] According to a sixth aspect, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, causes the processor to perform the log writing method as described in the first aspect.

[0020] The log writing method, apparatus, data processing unit, network interface card, computer equipment, computer-readable storage medium, and computer program product according to embodiments of this application have the following beneficial effects: This embodiment of the application centrally manages multiple log memory regions through the main control processing unit of the heterogeneous system. Each heterogeneous computing node only needs to write logs to the corresponding memory region, without needing an independent file system or persistence capability, thus reducing node capability dependency and simplifying system design. This embodiment of the application enables continuous log storage during normal operation, emergency protection of critical logs before system shutdown, and on-demand log write-to-disk during operation and maintenance debugging by setting periodic triggering conditions based on time periods, graceful power-down triggering conditions based on system stop or power-down events, and manual triggering conditions based on user input commands. This balances the differentiated requirements for real-time log write-to-disk performance, reliability, and resource overhead in different operating scenarios. This embodiment of the application unifies log write-to-disk requests into a log write-to-disk request queue and schedules execution according to a preset scheduling strategy, enabling orderly processing of multiple concurrent requests, avoiding competition for system resources from multiple write-to-disk operations, and reducing the impact on normal system operation. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings required in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart illustrating a log writing method in one embodiment of this application.

[0023] Figure 2 This is a flowchart illustrating a log write-to-disk operation in one embodiment of this application.

[0024] Figure 3 This is a schematic diagram of a process in one embodiment of the present application that triggers log write-to-disk operation based on periodic triggering conditions.

[0025] Figure 4 This is a schematic diagram of the process of triggering log write-to-disk operation based on graceful power-down trigger condition in one embodiment of this application.

[0026] Figure 5 This is a flowchart illustrating the process of triggering log write-to-disk operation based on manually triggered conditions in one embodiment of this application.

[0027] Figure 6 This is a schematic diagram of a log disk writing device according to one embodiment of this application. Detailed Implementation

[0028] The detailed description of the accompanying drawings is intended to illustrate embodiments of this application and is not intended to represent only the forms in which this application can be implemented. It should be understood that the same or equivalent functionality can be achieved by different embodiments intended to be included within the spirit and scope of this application.

[0029] One embodiment of this application provides a log writing method, which is applied to the main control processing unit of a heterogeneous system, the heterogeneous system including the main control processing unit and at least one heterogeneous computing node.

[0030] For example, the method of this embodiment can be applied to the following heterogeneous system: The heterogeneous system includes a DPU and a host CPU communicatively connected to the DPU. The DPU integrates a large-core processor (i.e., the main control processing unit), runs a complete Linux operating system, and has file system access capabilities. An application program runs on the host CPU side, and the log data it generates is temporarily stored in the shared DDR storage area of ​​the DPU via the PCIe bus. DDR is Double Data Rate Synchronous Dynamic Random Access Memory. The DPU also integrates heterogeneous computing nodes such as an Integrated Management Unit (IMU) and a System Control Processor (SCP). The running status logs generated by these heterogeneous computing nodes are also written to their respective memory areas in the shared DDR. In this heterogeneous system, the large-core processor of the DPU acts as the main control processing unit, executing the log writing method of this embodiment.

[0031] Please see Figure 1 One embodiment of the method of this application includes the following steps: Step S100: When any one of a variety of preset triggering conditions is met, a log write request is generated; wherein, the variety of preset triggering conditions includes periodic triggering conditions based on time periods, graceful power-down triggering conditions based on system stop or power-down events, and manual triggering conditions based on user input commands.

[0032] Specifically, the operating system kernel of the main control processing unit maintains a trigger event management structure. This structure records the enable status and judgment parameters of three trigger conditions, and the data in this structure is dynamically configured by the user. System shutdown includes, but is not limited to, abnormal crashes and abnormal restarts; power-down refers to system power failure. The monitoring mechanisms for these three trigger conditions operate independently. When any mechanism determines that its corresponding trigger condition is met, the main control processing unit generates a log write request. This log write request can exist in the form of a data structure, which may include a request type field (to identify which trigger condition generated the request) and a timestamp field, etc., to distinguish different trigger sources during subsequent scheduling and processing.

[0033] Step S200: Add the log write-to-disk request to the log write-to-disk request queue.

[0034] Specifically, a log write-to-disk request queue is pre-allocated in the kernel space of the main control processing unit. This queue is implemented using a ring buffer data structure; for example, the queue depth is preset to 8, which can hold a maximum of 8 pending log write-to-disk requests. When a log write-to-disk request is generated in step S100, the main control processing unit calls the queue write interface. If the queue is not full, the log write-to-disk request is enqueued and the queue information is updated. If the queue is full, a queue full error code is returned, and the main control processing unit can decide to retry after waiting for a preset time based on the error code.

[0035] Step S300: Obtain the log write request from the log write request queue according to the preset scheduling strategy, read log data from the target log memory area according to the obtained log write request, and write the log data to the persistent storage medium; wherein, the heterogeneous system includes multiple log memory areas, and each log memory area stores the log data generated by the corresponding heterogeneous computing node according to the preset log format.

[0036] Specifically, a dedicated kernel thread runs within the operating system kernel of the main control processing unit as the log write-to-disk execution unit. This dedicated kernel thread is specifically used to retrieve requests from the log write-to-disk request queue and execute the specific log write operation. This dedicated kernel thread is created by the kernel module initialization function during system startup and persists throughout system operation. The execution body of this dedicated kernel thread is an infinite loop. Within the loop, it first calls the queue reading interface to retrieve log write-to-disk requests from the log write-to-disk request queue. If the queue is empty, the thread enters an interruptible waiting state, waiting to be awakened when the queue is not empty; if the queue is not empty, the dedicated kernel thread retrieves a log write-to-disk request from the log write-to-disk request queue according to a preset scheduling strategy.

[0037] The scheduling strategy for log write requests in the queue can be adjusted based on log type, priority, trigger source, or system status, and can adopt first-come-first-served, priority scheduling, time-slice round-robin, or hybrid scheduling strategies.

[0038] For example, the scheduling strategy can be first-come, first-served, meaning the log write request at the head of the queue is always retrieved. After retrieving the log write request, the thread determines the source of the log data to be read, i.e., the target log memory region, based on the information carried in the log write request. This target log memory region can be one or more of the log memory regions corresponding to the SCP, the IMU, or the host CPU. Subsequently, the thread maps the physical address of the target log memory region to the kernel virtual address space through the kernel interface, reads the log data from this region, and finally writes the log data to persistent storage media through the corresponding interface, such as writing it to a log file on the DPU's onboard eMMC storage device.

[0039] This embodiment of the method sets up a unified log write-to-disk control logic on the main control processing unit side of the heterogeneous system. The main control processing unit centrally manages multiple log memory areas. Each heterogeneous computing node only needs to write the log to the corresponding memory area according to the preset format. Each node does not need to have an independent file system or persistence capability, which reduces the dependence of each heterogeneous computing node on storage management capabilities, reduces the complexity of system design, and makes the log management link simpler and more controllable.

[0040] This embodiment sets up multiple preset trigger conditions, including periodic trigger conditions based on time periods, graceful power-down trigger conditions based on system stop or power-down events, and manual trigger conditions based on user input commands. These three trigger methods are independent and complementary. Specifically: the periodic trigger condition is suitable for continuous log storage during normal system operation; the graceful power-down trigger condition is suitable for emergency protection scenarios before system shutdown, avoiding the loss of log data in memory due to sudden power outages or system crashes, ensuring the availability of log data during fault location and problem backtracking; and the manual trigger condition is suitable for on-demand disk persistence during debugging, maintenance, or anomaly analysis. Through the coordinated configuration of these multiple trigger conditions, the system can balance the real-time performance, reliability, and resource overhead of log persistence under different operating states, avoiding the problem that a single trigger method cannot adapt to multiple operating scenarios.

[0041] This embodiment adds all generated log write requests to a request queue, and the main control processing unit retrieves requests from the queue and executes them sequentially according to a preset scheduling strategy. Through this queued scheduling method, even when different triggering conditions are met simultaneously and multiple log write requests are generated within a short period, each request can be executed in an orderly manner. This avoids competition for system I / O and processor resources caused by concurrent execution of multiple write operations, reducing the impact of log write operations on the normal operation of heterogeneous systems and improving the overall stability of the system.

[0042] In some embodiments, step S300 includes: When the log write-to-disk request queue is not empty, determine whether the log write-to-disk function is enabled. If the log write-to-disk function is enabled, then determine whether the dump mask is 0; the dump mask is used to indicate the log memory area that needs to be written to disk. If the dump mask is not 0, it is determined whether a log write request is currently being executed; If no log write request is currently in progress, log data is read from at least one log memory region according to the dump mask.

[0043] Specifically, after the log writing execution unit of the main control processing unit is awakened, it first checks whether the log writing request queue is empty. If the queue is empty, the log writing execution unit directly returns to the sleep state. If the queue is not empty, the log writing execution unit further checks an enable variable, `dump_enable`, which indicates whether the log writing function is enabled. `dump_enable` can be set by the user through the sysfs interface; for example, writing 1 indicates enabled, and writing 0 indicates disabled. If `dump_enable` is 0, it means the log writing function is currently disabled, and the log writing execution unit clears all pending requests in the queue and returns to the sleep state. If `dump_enable` is 1, the log writing execution unit further reads a mask variable, `dump_mask`, which includes multiple bits. Each bit can correspond to one or more log memory areas or a log type. For example, bit 0 corresponds to the SCP log area, bit 1 corresponds to the IMU log area, and so on. It should be noted that each time the main control processing unit or heterogeneous computing node writes log data to the corresponding log memory region, it sets the bit corresponding to that log memory region in the mask variable to 1. The log write-to-disk execution unit checks if dump_mask is equal to 0. If it is equal to 0, it means there is no log memory region to write to disk, and the log write-to-disk execution unit returns to the queue to retrieve the next request. If dump_mask is not 0, the log write-to-disk execution unit further checks a variable dump_in_progress. If dump_in_progress is 1, it means there is a log write-to-disk request currently being executed; if it is 0, it means there is no request. If dump_in_progress is 1, the log write-to-disk execution unit puts the current request back into the queue to wait for the next processing, or directly discards the current request (the specific strategy can be selected according to the configuration). If dump_in_progress is 0, the log write-to-disk execution unit sets dump_in_progress to 1, and then reads log data from the corresponding log memory area and writes it to the persistent storage medium according to the bits set in dump_mask. The above variables such as dump_enable, dump_mask, and dump_in_progress can be stored in storage units such as registers.

[0044] In some embodiments, step S300 includes: During the execution of the log write-to-disk request, the execution time of the log write-to-disk request is monitored. If the execution time exceeds a preset timeout threshold, the execution of the log write-to-disk request is terminated, and the dump mask is updated according to the current execution result of the log write-to-disk request. After the log write request is completed normally, the dump mask is set to 0.

[0045] Specifically, when the log write-to-disk execution unit of the main control processing unit begins executing a log write-to-disk request, it simultaneously records the current system timestamp as the start time and sets a timeout threshold, such as 3 seconds. This timeout threshold can be adjusted according to the performance of the actual storage medium; for example, it can be appropriately relaxed for storage media with slower write speeds. In the main loop of the log write-to-disk operation, after each data read and write operation of a log memory region is completed, the log write-to-disk execution unit obtains the current system time and compares it with the start time. If the time difference is less than 3 seconds, it continues to process the next log memory region. If the time difference reaches or exceeds 3 seconds, the log write-to-disk execution unit immediately terminates the current write-to-disk operation and no longer processes the remaining log memory regions. After termination, the log write-to-disk execution unit updates the dump_mask according to the log memory regions that have been written to disk, that is, clearing the bits corresponding to the regions that have been written to disk and retaining the bits corresponding to the regions that have not yet been written to disk. Then, the log write-to-disk execution unit sets dump_in_progress to 0, indicating that there are currently no log write-to-disk requests being executed. In another scenario, if the current log write-to-disk request completes all log memory area write operations normally within the timeout threshold, the log write-to-disk execution unit will set dump_mask to 0 and dump_in_progress to 0 immediately after completion.

[0046] In one embodiment, such as Figure 2 As shown, the specific execution process of the log writing to disk execution unit is as follows: The log write execution unit (dedicated thread) runs in a resident mode in the operating system kernel of the main control processing unit. This log write execution unit is created and started by the log write device when the system starts up and continues to exist throughout the entire system operation. It is used to uniformly queue and schedule log write requests triggered by different triggering conditions.

[0047] After the log write-to-disk execution unit starts, it first enters a waiting state. In this waiting state, the log write-to-disk execution unit listens for a wake-up signal from the trigger event monitoring unit. The trigger event monitoring unit monitors whether the system status meets preset trigger conditions based on user-defined conditions. If the preset trigger conditions are met, it determines to generate the wake-up signal to wake up the log write-to-disk execution unit, generates a corresponding log write-to-disk request, and submits it to the log write-to-disk scheduling unit. The log write-to-disk execution unit is then awakened and responds to the log write-to-disk request, entering the log write-to-disk processing flow. If no log write-to-disk event is detected for an extended period, the log write-to-disk execution unit remains in a waiting state and does not occupy processor resources.

[0048] Before proceeding with the actual log write operation, the log write execution unit first checks the current log write status. Specifically, it determines whether the status information (i.e., the dump mask) indicating the type or range of logs to be executed is 0. If the dump mask is 0, it means there are no log write tasks to be executed, and the log write execution unit ends its current processing and returns to a waiting state. Simultaneously, the log write execution unit also checks whether the log write function is enabled. If the log write function is not enabled, the log write execution unit also ends its current processing and returns to a waiting state, without performing any log write operation.

[0049] When the dump mask is determined to be non-zero (i.e., a valid log write task exists) and the log write function is enabled, the log write execution unit attempts to acquire the log write execution right. This log write execution right ensures that only one log write process is running at any given time, thus avoiding conflicts with system resources caused by concurrent log write operations in multi-trigger scenarios. If another log write process is already running, the log write execution unit fails to acquire the execution right. In this case, the log write execution unit can continue to wait, or try to acquire the execution right again after the preset conditions are met according to a preset strategy. The execution right can be determined by a dump completion signal. For example, a flag can be set to indicate this. For example, a flag of 1 indicates that the dump is complete and the execution right can be acquired, while a flag of 0 indicates that the dump is not complete and the execution right cannot be acquired.

[0050] After successfully acquiring the right to execute log write operations, the log write execution unit determines the scope of the log write operation to be performed based on the current dump mask. For example, each bit in the dump mask corresponds to a log memory region. The log write execution unit reads log data sequentially from the corresponding log memory regions according to the set bits in the dump mask, and writes the log data to the persistent storage medium through the log write control unit. During execution, the log write execution unit initiates a timeout detection mechanism to continuously monitor the execution time of the current log write operation. If the execution time exceeds a preset timeout threshold, the log write execution unit immediately terminates the current log write operation to avoid prolonged occupation of system resources due to abnormal conditions (such as slow storage medium response, data read errors, etc.). After termination, the log write execution unit updates the dump mask based on the completed log memory regions, clearing the bits corresponding to the already written regions and retaining the bits corresponding to the regions not yet written, for subsequent rescheduling and execution.

[0051] After the log write operation is completed (including both normal completion and timeout termination), the log write execution unit sets the dump mask to 0 to clear all pending write flags. Subsequently, the log write execution unit updates the signals indicating the log write completion status to output a dump completion signal, notifying that the log write operation has ended. The dump completion signal can be indicated by setting a flag bit; for example, a flag bit of 1 indicates dump completion, and a flag bit of 0 indicates dump completion. The log write execution unit also performs a reset operation, clearing status information such as completed log flags. Finally, the log write execution unit releases the log write execution right, allowing subsequent log write requests to be processed normally. After releasing the execution right, the log write execution unit returns to a waiting state and continues to listen for the next log write event.

[0052] In some embodiments, step S300 includes: When reading log data from the target log memory region, a unified abstract view of the memory log is obtained, and log data is read from the target log memory region according to the unified abstract view of the memory log; wherein, the unified abstract view of the memory log includes descriptive information of each log memory region, and the descriptive information includes at least one of the following: physical address of the log memory region, region size, log format, and current write status.

[0053] Specifically, in one implementation of the unified abstract view of memory logs, the kernel of the main control processing unit maintains an array of log memory region descriptors. Each element in the array corresponds to the log memory region of a heterogeneous computing node. For example, each element includes, but is not limited to, the following fields: phys_addr field (stores the physical starting address of the memory region), size field (stores the capacity of the memory region, such as 1MB), log_format field (stores the log format identifier of the memory region, such as 0 for plain text format and 1 for binary format), and write_offset field (stores the current valid log write offset of the memory region).

[0054] For example, when performing a disk write operation, the log write execution unit first reads the dump_mask to determine the log memory region number to be written to disk. Then, using this log memory region number as an index, it directly accesses the corresponding element in the descriptor array, extracts the field information, constructs a kernel virtual address mapping based on the phys_addr and size fields, and reads the log data. Simultaneously, the log write execution unit determines the log data organization method based on the log_format field; for plain text logs, it reads them directly as a text stream, and for binary logs, it reads them as binary data blocks. Furthermore, the log write execution unit determines the cutoff position of valid log data in the current region based on the write_offset field. During reading, it only reads valid data from the region's start address to the position specified by write_offset, avoiding reading invalid regions where no log data has yet been written. Through a unified abstract view of the memory log, the execution thread does not need to concern itself with the underlying physical layout differences of each log memory region, nor with whether the log formats of each region are the same; access can be completed uniformly through the description information in the abstract view.

[0055] In some embodiments, step S100 includes: A periodic timer is set up, which repeatedly generates timing signals at preset time intervals; wherein the preset time interval is dynamically configured according to user input instructions. Each time the timing signal is generated, if the periodic log write-to-disk function is enabled, then the periodic triggering condition is determined to be met.

[0056] Specifically, in this embodiment, the main control processing unit sets a periodic timer in its operating system kernel. This timer repeatedly generates timing signals at preset time intervals. The preset time interval can be dynamically configured by the user according to actual application needs, for example, by writing new time interval parameters through the configuration interface provided by the system. Each time a timing signal is generated, the main control processing unit determines whether the periodic log write-to-disk function is enabled. If the periodic log write-to-disk function is enabled, the main control processing unit determines that the periodic triggering condition is met and generates the corresponding log write-to-disk request. If the periodic log write-to-disk function is not enabled, the main control processing unit will not generate a log write-to-disk request even if a timing signal is generated.

[0057] In one specific embodiment, such as Figure 3As shown, this embodiment provides a periodic log write-to-disk mechanism, which is initialized and configured during system startup. Specifically, during the startup process of the DPU's large-core processor, the kernel-mode log write-to-disk device first initializes the periodic log write-to-disk mechanism, including creating a control interface for configuring periodic parameters and setting the default periodic parameters for log write-to-disk (i.e., the condition parameters for periodic triggering conditions), such as a default period of 60 seconds. This periodic parameter indicates the frequency of generating periodic log write-to-disk requests, i.e., how often to determine whether a log write-to-disk request needs to be generated.

[0058] During system operation, users or upper-level management systems can write new period configuration parameters to the control interface through user space, such as adjusting the period from 60 seconds to 30 seconds. Upon receiving the configuration update, the kernel-mode log writing device synchronously updates the current period scheduling state and makes the new period parameters take effect immediately, without requiring a system restart or module reloading. Through this dynamic configuration method, the periodic log writing mechanism can flexibly adjust the writing frequency without interrupting system operation, avoiding performance waste or log omissions caused by fixed period settings.

[0059] During the operation of the periodic log write-to-disk mechanism, the mechanism continuously checks whether it is currently enabled. The enabled or disabled status of the periodic log write-to-disk function can be recorded through a global enable flag in the system, and users can also modify this status through the configuration interface. When it is detected that the periodic log write-to-disk mechanism is not enabled, no log write-to-disk request is generated, and the current scheduling waiting state is maintained.

[0060] When the periodic log write-to-disk mechanism is enabled, it generates a corresponding log write-to-disk request at the end of each period based on the currently active period parameter. The periodic log write-to-disk mechanism does not directly execute the log write operation; instead, it generates a periodic log write-to-disk request, which is submitted to the log write-to-disk scheduling unit. The scheduling unit then writes this request into the log write-to-disk thread queue, managing and coordinating it with log write-to-disk requests from other sources. By abstracting the periodic log write-to-disk action into a request generation process, the decoupling between the periodic scheduling logic and the specific log write-to-disk execution logic is achieved. This allows the periodic log write-to-disk mechanism to naturally integrate into a multi-trigger collaborative log write-to-disk system, avoiding resource contention or execution conflicts between periodic triggering and other triggering methods.

[0061] After the log write-to-disk request is scheduled and processed, the periodic log write-to-disk mechanism does not terminate. Instead, it returns to the periodic detection process, continuing to determine the conditions for generating the next log write-to-disk request based on the current periodic parameters and scheduling status. Through this cyclical execution method, the periodic log write-to-disk mechanism remains effective throughout system operation, enabling log data to be persistently stored in batches and in a controllable manner according to a preset periodic strategy. This effectively reduces the risk of log loss and improves data traceability in abnormal system scenarios.

[0062] In some embodiments, step S100 includes: The system status information in the preset memory status address is obtained. If the system status information indicates that the system has stopped or is powered off, it is determined that the graceful power-off trigger condition is met. The system status information is written to the memory status address by the main control processing unit or the heterogeneous computing node.

[0063] Specifically, in this embodiment, a pre-defined memory state address is used to store system running status or power-down related status information. This memory state address is mapped to the kernel-accessible space of the main control processing unit during the system startup phase. The system status information can be written by the main control processing unit itself or by heterogeneous computing nodes (such as IMU, small core processing units, etc.) under specific conditions. The main control processing unit continuously monitors the system status information in this memory state address. When it detects that the system status information indicates that the system has stopped or powered down, the main control processing unit determines that the graceful power-down trigger condition is met and generates a corresponding log write request to disk.

[0064] In some embodiments, step S300 includes: When the graceful power-down triggering condition is met, after writing the log data to the persistent storage medium, a file system synchronization operation is performed; and after the file system synchronization operation is completed, the system stop or power-down process is triggered.

[0065] Specifically, in this embodiment, after the main control processing unit determines that the graceful power-down trigger condition is met and generates a log write-to-disk request, the log write-to-disk request is submitted to the log write-to-disk request queue and executed according to a preset scheduling strategy. During the execution of the log write-to-disk request, the main control processing unit determines the target log memory region based on the dump_mask, reads log data from the target log memory region, and writes the log data to the persistent storage medium. After the log data writing operation is completed, the main control processing unit performs a file system synchronization operation. This file system synchronization operation is used to ensure that the written log data is reliably flushed from the file system cache to the physical storage medium, avoiding data loss due to subsequent system power failure. Only after the file system synchronization operation is completed does the main control processing unit trigger the system stop or power-down process.

[0066] In one specific embodiment, such as Figure 4 As shown in this embodiment, to address the issue of log loss during system power-down or restart phases, an elegant power-down log writing mechanism based on memory address monitoring is provided. This mechanism is particularly suitable for DPU scenarios, where computing nodes such as IMU, small cores, and SCP do not have independent file systems and persistence capabilities. Their critical operation logs are mainly temporarily stored in memory space. Once power-down or system shutdown occurs, important log information is easily lost.

[0067] During system startup, the large-core processor inside the DPU initializes the log write device in its operating system kernel and maps a pre-defined memory state address to the kernel-accessible space. This memory state address reflects the system's running status or power-down related status information, which can be updated by the IMU, small cores, or other functional units under specific conditions. For example, when a user triggers a system power-down operation, the IMU can write a power-down status value to this memory state address; when the system encounters an anomaly and needs to restart, the relevant control unit can also write the corresponding status value to this memory state address.

[0068] After completing the memory state address mapping, the system can initialize and create a memory state monitoring execution unit in kernel mode to continuously or according to a preset strategy monitor the memory state address. Subsequently, the memory state monitoring execution unit is enabled, enabling it to continuously acquire the state information corresponding to the memory state address during system operation. During monitoring, the memory state monitoring execution unit judges the memory state information according to a preset detection strategy, such as periodically reading the state value in the memory state address and comparing it with preset trigger conditions.

[0069] When the system detects that the status information meets the predefined graceful power-down trigger conditions, it determines that it is entering the graceful power-down log processing scenario. The graceful power-down trigger conditions may include, but are not limited to: the power-down flag being set, system state switching indication, changes in the state of a specific control register or shared memory region, etc. For example, when the power-down flag in the memory status address changes from 0 to 1, the memory status monitoring execution unit determines that the graceful power-down trigger conditions are met, and the system then enters the graceful power-down log processing scenario.

[0070] In the graceful power-down log processing scenario, the system first determines whether the global log write-to-disk function is enabled. The enabling status of the global log write-to-disk function is recorded through a global enable flag in the system. When the log write-to-disk function is not enabled, the system can directly enter the system stop or power-down process without performing the log write-to-disk operation. When the log write-to-disk function is enabled, the system further determines whether there is a log write-to-disk process currently being executed.

[0071] If no log write-to-disk process is currently in progress, the system configures the corresponding log write-to-disk parameters based on the characteristics of the graceful power-off scenario and submits a log write-to-disk execution request to the log write-to-disk scheduling unit to trigger the log write-to-disk execution process. After the log write-to-disk execution request is submitted to the log write-to-disk request queue, the log write-to-disk execution unit schedules and executes it according to a predetermined scheduling strategy, thereby writing the log data in each log memory area to persistent storage media. If a log write-to-disk process is detected to be currently in progress, the system enters a waiting state, waiting for the currently executing log write-to-disk process to complete, to avoid resource contention and data inconsistency issues caused by concurrent execution.

[0072] During the waiting process, the system continuously listens for the log write-to-disk completion signal. When the log write-to-disk completion signal is received within the preset timeout period, it indicates that the current log write-to-disk process has been completed within the specified time, and the system ends the waiting process. If the log write-to-disk completion signal is not received after the preset timeout period, it indicates that the log write-to-disk process may have failed to complete in time due to abnormal circumstances. In this case, the system also ends the waiting process to avoid the system failing to power down due to indefinite waiting.

[0073] After the waiting process is completed, the system performs a file system synchronization operation to ensure that the completed log data is reliably flushed from the file system cache to the physical storage medium, avoiding data loss due to subsequent system power outages. Once the file system synchronization operation is complete, the system finally triggers a system stop or power-down process, thereby achieving centralized disk persistence and reliable preservation of log data in power-down scenarios.

[0074] In some embodiments, step S100 includes: The system receives user input commands, parses the trigger parameters carried by the user input commands, and determines that the manual triggering conditions are met if the trigger parameters are preset valid trigger values.

[0075] Specifically, in this embodiment, the main control processing unit creates a control interface for receiving user input commands during the system startup phase. User-space programs can send commands to the main control processing unit through this control interface. After receiving the user input command, the main control processing unit parses the trigger parameters carried in the command and determines whether the trigger parameters are preset valid trigger values. If the trigger parameters are preset valid trigger values, the main control processing unit determines that the manual triggering conditions are met and generates a corresponding log write-to-disk request. If the trigger parameters are not preset valid trigger values, the main control processing unit does not perform the log write-to-disk operation.

[0076] In one specific embodiment, this addresses the need for operations and maintenance personnel or upper-level management systems to proactively request log write-to-disk at specific times (such as system debugging, fault reproduction, problem localization, or operational status verification). Figure 5 As shown, this embodiment provides a mechanism for manually triggering log writing to disk.

[0077] During system startup, the large-core processor inside the DPU initializes the log write-to-disk device within its operating system kernel and creates a configuration directory and corresponding control attributes for manually triggering log write-to-disk operations. This configuration directory and control attributes provide a controlled triggering interface to user space, allowing maintenance personnel or management programs to initiate log write-to-disk requests in a standard manner. For example, a dedicated control node can be created in the sysfs virtual file system, and user-space programs can write trigger parameters to this control node through standard file operation interfaces.

[0078] After the configuration directory is created, the system initializes a manual triggering execution unit in kernel mode to receive, parse and process manual triggering requests from user space. As an independent execution unit in the log disk write-to-disk triggering system, this manual triggering execution unit is decoupled from the periodic triggering mechanism and the graceful power-down triggering mechanism at the trigger source level. That is, it runs independently of each other in terms of trigger source and judgment logic, without interfering with each other. However, at the scheduling level, it is uniformly connected to the log disk write-to-disk scheduling mechanism. That is, all requests generated by all triggering methods are eventually submitted to the same log disk write-to-disk scheduling unit for unified management.

[0079] When user space writes trigger parameters to the manual trigger control node, the manual trigger processing execution unit receives and parses the trigger parameters, and performs a validity check. These trigger parameters can be used to indicate whether to perform a manual log write operation, or to carry control information related to this manual trigger. For example, it can be agreed that writing a value of 1 indicates triggering log write to disk, and writing a value of 0 indicates not performing any operation.

[0080] When the trigger parameter is determined to be a valid trigger value (e.g., the written value is 1), the manual trigger processing execution unit generates a corresponding manual trigger log write-to-disk identifier and submits this identifier as a trigger request to the log write-to-disk scheduling mechanism. Upon receiving the manual trigger log write-to-disk request, the log write-to-disk scheduling mechanism, following the execution flow of the aforementioned log write-to-disk execution unit, includes the manually triggered log write-to-disk request in the log write-to-disk request queue. The log write-to-disk execution unit then performs unified scheduling and processing according to a predetermined scheduling strategy (e.g., first-come, first-served), ensuring that it operates collaboratively with other triggering methods such as periodic triggering and graceful power-down triggering within the same scheduling system, thus avoiding concurrent conflicts or duplicate execution.

[0081] When the trigger parameter is determined to be an invalid trigger value (e.g., the written value is not a valid trigger value as agreed upon), the system does not perform the log write operation and returns to the state of waiting for user space reconfiguration, thereby avoiding the impact of invalid operations on system operation. For example, if a user writes an undefined value to the control node, the manual triggering execution unit ignores the write operation, does not generate any log write request, and the system continues to maintain normal operation.

[0082] By using the manual log write-to-disk mechanism described above, this embodiment provides a secure, controllable, and highly coordinated log write-to-disk triggering method for user space without disrupting the original system operation rhythm. This further enhances the flexibility, maintainability, and engineering practical value of log management in DPU heterogeneous systems.

[0083] It should be noted that in the process described in the above-described method embodiments and accompanying drawings of this application, the step numbers S100, S200, S300, etc., are only for ease of description and differentiation of different steps, and do not constitute a limitation on the execution order of the steps. Unless this application explicitly states that a certain step must be performed before or after another step, or a person skilled in the art can determine, based on the inherent logic of the technical solution, that a specific execution order is necessary, the execution order of the above steps can be adjusted, combined, or performed in parallel according to actual needs, and the resulting solution still falls within the protection scope of this application. Similarly, Figures 1 to 5 The sequence of process steps shown is merely an example and does not constitute the sole order limitation for the technical solution of this application.

[0084] Please see Figure 6 Another embodiment of this application provides a log writing device, which is integrated into the main control processing unit of a heterogeneous system and is used to execute the log writing method as described in the above embodiments. Specifically, the log writing device includes: The trigger event monitoring unit 1 is used to generate a log write request when any one of a variety of preset trigger conditions is met; the variety of preset trigger conditions include periodic trigger conditions based on time period, graceful power-down trigger conditions based on system stop or power-down events, and manual trigger conditions based on user input commands. Log write-to-disk scheduling unit 2 is used to add the log write-to-disk request to the log write-to-disk request queue; and Log write-to-disk execution unit 3 is used to obtain the log write-to-disk request from the log write-to-disk request queue according to a preset scheduling strategy, read log data from the target log memory area according to the obtained log write-to-disk request, and write the log data to the persistent storage medium. The heterogeneous system includes multiple log memory areas, each of which stores log data generated by the main control processing unit or the corresponding heterogeneous computing node according to a preset log format.

[0085] In some embodiments, the log write-to-disk execution unit 3 is specifically used for: When the log write-to-disk request queue is not empty, determine whether the log write-to-disk function is enabled. If the log write-to-disk function is enabled, then determine whether the dump mask is 0; the dump mask is used to indicate the log memory area that needs to be written to disk. If the dump mask is not 0, it is determined whether a log write request is currently being executed; If no log write request is currently in progress, log data is read from at least one log memory region according to the dump mask.

[0086] In some embodiments, the log write-to-disk execution unit 3 is specifically used for: During the execution of the log write-to-disk request, the execution time of the log write-to-disk request is monitored. If the execution time exceeds a preset timeout threshold, the execution of the log write-to-disk request is terminated, and the dump mask is updated according to the current execution result of the log write-to-disk request. After the log write request is completed normally, the dump mask is set to 0.

[0087] In some embodiments, the log write-to-disk execution unit 3 is specifically used for: When reading log data from the target log memory region, a unified abstract view of the memory log is obtained, and log data is read from the target log memory region according to the unified abstract view of the memory log; wherein, the unified abstract view of the memory log includes descriptive information of each log memory region, and the descriptive information includes at least one of the following: physical address of the log memory region, region size, log format, and current write status.

[0088] In some embodiments, the trigger event monitoring unit 1 is specifically used for: A periodic timer is set up, which repeatedly generates timing signals at preset time intervals; wherein the preset time interval is dynamically configured according to user input instructions. Each time the timing signal is generated, if the periodic log write-to-disk function is enabled, then the periodic triggering condition is determined to be met.

[0089] In some embodiments, the trigger event monitoring unit 1 is specifically used for: The system status information in the preset memory status address is obtained. If the system status information indicates that the system has stopped or is powered off, it is determined that the graceful power-off trigger condition is met. The system status information is written to the memory status address by the main control processing unit or the heterogeneous computing node.

[0090] In some embodiments, the log write-to-disk execution unit 3 is specifically used for: When the graceful power-down triggering condition is met, after writing the log data to the persistent storage medium, a file system synchronization operation is performed; and after the file system synchronization operation is completed, the system stop or power-down process is triggered.

[0091] In some embodiments, the trigger event monitoring unit 1 is specifically used for: The system receives user input commands, parses the trigger parameters carried by the user input commands, and determines that the manual triggering conditions are met if the trigger parameters are preset valid trigger values.

[0092] It should be noted that the log writing device in this embodiment corresponds to the log writing method in the above embodiment. Therefore, any content not described in detail in the log writing device in this embodiment can be obtained by referring to the log writing method in the above embodiment.

[0093] Another embodiment of this application provides a data processing unit (DPU) including the log write device as described in the above embodiments.

[0094] Specifically, in this embodiment, the DPU can be integrated into the network interface card (NIC) and operate as the main control processing unit within the NIC. The NIC can be plugged into the host computer via a PCIe slot on the motherboard and communicates with the host CPU via the PCIe bus. The DPU runs an operating system and has file system access capabilities and persistent storage management capabilities. The DPU uses its internal log write-to-disk device to centrally manage and persistently store log data generated by itself, the NIC, and / or other heterogeneous computing nodes connected to the NIC. The heterogeneous computing nodes may include, but are not limited to, an Integrated Management Unit (IMU), a System Controller Processor (SCP), and small core processing units. As the main control processing unit of the heterogeneous system, the DPU can execute the log write-to-disk method described in the foregoing embodiment, writing log data from each log memory area to the persistent storage medium.

[0095] During the collaborative operation between the network interface card (NIC) and the host, the NIC can receive network data, storage requests, or computing tasks, and schedule data requiring host CPU processing to the host side via the PCIe bus. The host CPU then processes the data scheduled from the NIC. Optionally, in scenarios where logs generated by applications on the host CPU side need to be written to disk by the DPU, the host CPU can write the application-generated log data to the log memory area allocated to the host CPU in the shared DDR of the DPU via the PCIe bus. The log writing device in the DPU then writes the log data to persistent storage media according to the method described in the aforementioned embodiments. Through the aforementioned DPU, the log writing operation is centrally completed by the DPU within the NIC. The host CPU does not need to undertake the log writing management tasks within the NIC and heterogeneous computing nodes, which helps reduce the host CPU burden and improves the reliability of log data in scenarios of abnormal power failure or system shutdown.

[0096] It should be noted that the DPU in this embodiment corresponds to the log writing method and log writing device embodiments described above. For details not described in detail, please refer to the foregoing embodiments.

[0097] Another embodiment of this application provides a network interface card (NIC) including a data processing unit (DPU) as described in the above embodiments.

[0098] Specifically, in this embodiment, the network interface card (NIC) can be plugged into the host computer via a PCIe slot on the motherboard and communicates with the host CPU via the PCIe bus. The Data Processing Unit (DPU) operates as the main control and processing unit within the NIC, running an operating system and possessing file system access and persistent storage management capabilities. The NIC can use its internal DPU to centrally manage and persistently store log data generated internally and / or from other heterogeneous computing nodes connected to the NIC.

[0099] During the collaborative operation between the network interface card (NIC) and the host, the NIC can receive network data, storage requests, or computing tasks. Based on the task type or system load, it schedules data requiring host CPU processing to the host side via the PCIe bus, where the host CPU processes the data. Optionally, in scenarios where application logs generated by the host CPU need to be written to disk by the Data Processing Unit (DPU), the host CPU can write the application-generated log data to the log memory area allocated to the host CPU in the shared DDR memory of the DPU via the PCIe bus. The log writing device in the DPU then writes the log data to persistent storage media according to the method described in the aforementioned embodiments. Through this NIC, the log writing operation is centrally completed by the DPU within the NIC. The host CPU does not need to undertake log writing management tasks within the NIC and on heterogeneous computing nodes, which helps reduce the host CPU load and improves the reliability of log data in scenarios of abnormal power failure or system shutdown.

[0100] It should be noted that the network card in this embodiment corresponds to the above-described log writing method, log writing device and data processing unit embodiments. For any content not described in detail, please refer to the foregoing embodiments.

[0101] Another embodiment of this application provides a computer device including a host CPU and a network interface card (NIC) as described in the above embodiments, wherein the host CPU is used to process data scheduled by the NIC.

[0102] Specifically, in this embodiment, the computer device can be a server, data center node, workstation, etc. The host CPU and network interface card (NIC) are connected via a PCIe bus. The host CPU processes data scheduled to the host side by the NIC, such as network packets received by the NIC, storage requests, and computing tasks. The NIC includes the data processing unit (DPU) described in the preceding embodiments, and the DPU includes the log write-to-disk device described in the preceding embodiments. The DPU operates as the main control processing unit of the heterogeneous system, running an operating system internally and possessing file system access capabilities and persistent storage management capabilities. The DPU can also integrate heterogeneous computing nodes such as IMU and SCP, and the log data generated by these heterogeneous computing nodes is also written to their respective corresponding log memory areas in the shared DDR. The DPU, through its internal log write-to-disk device, centrally manages and persistently stores the log data of the host CPU and multiple heterogeneous computing nodes.

[0103] During computer equipment operation, when any of the periodic triggering conditions, graceful power-down triggering conditions, or manual triggering conditions are met, the DPU generates a log write-to-disk request, adds the log write-to-disk request to the log write-to-disk request queue, retrieves the log write-to-disk request from the queue according to a preset scheduling strategy, reads log data from the target log memory area, and writes the log data to persistent storage media. Through this computer equipment, the log write-to-disk operation is centrally completed by the DPU within the network interface card. The host CPU does not need to undertake the log write-to-disk management task for heterogeneous computing nodes, reducing the host CPU load, improving the reliability of log data in scenarios of abnormal power-down or system shutdown, and enhancing the overall stability of the computer equipment.

[0104] It should be noted that the computer device in this embodiment corresponds to the log writing method, log writing device, data processing unit, and network card embodiment described above. Details not described in detail can be found in the foregoing embodiments; therefore, the computer device in this embodiment will not be described again. Another embodiment of this application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the processor performs the log writing method as described in the above embodiments.

[0105] Specifically, the computer-readable storage medium can be any tangible medium capable of storing computer programs, including but not limited to random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical disc read-only memory (CD-ROM), hard disk drive (HDD), solid-state drive (SSD), USB flash drive, portable hard drive, or any suitable combination thereof. The computer-readable storage medium can exist independently of the processor or can be integrated into an electronic device as a component thereof, such as a data processing unit (DPU), a network interface card (NIC), or a computer device containing such a NIC.

[0106] The processor can be a main control processing unit, such as the main control processing unit in a data processing unit. When the processor executes the computer program, it can implement the log writing method described in the foregoing embodiments, centrally write log data from multiple log memory regions in a heterogeneous system to disk, and write the log data to a persistent storage medium.

[0107] For example, the computer program is embedded in the computer-readable storage medium in the form of a binary instruction set, forming a program product that can be independently distributed without specific hardware devices. When the main control processing unit of devices such as smart network cards and data processing units reads and executes these instructions through the bus, it can drive the file system module of the operating system kernel to execute the log writing method described in the above embodiments.

[0108] It should be noted that the computer-readable storage medium in this embodiment corresponds to the log writing method, log writing device, data processing unit, network card and computer equipment embodiments described above. For any content not described in detail, please refer to the foregoing embodiments.

[0109] Another embodiment of this application provides a computer program product, including a computer program that, when executed by a processor, causes the processor to perform the log writing method as described in the above embodiments.

[0110] Specifically, the computer program product can take the form of an independent software installation package, application, plugin, patch file, or dynamic link library. The computer program product can be hosted on a computer-readable storage medium as described in any of the foregoing embodiments, or it can be transmitted and distributed in the form of signals via a network (including but not limited to the Internet, local area network, mobile communication network, etc.). The computer program product includes a computer program or computer program instructions, which comprises a series of program modules or instruction sequences, the functions of which and their inter-module relationships correspond to the steps in the foregoing method embodiments.

[0111] When the computer program product is loaded into the memory of the electronic device and executed by the processor of the electronic device, the electronic device is configured to execute the log write-to-disk method described in the above embodiments. The electronic device can be a data processing unit (DPU), a network interface card (NIC) including the data processing unit, or a computer device including a host CPU and the NIC. The processor can be a master control processing unit, such as the master control processing unit in the DPU. When the processor executes the computer program, it can generate a log write-to-disk request when any of the periodic triggering condition, graceful power-down triggering condition, or manual triggering condition is met. The processor adds the log write-to-disk request to a log write-to-disk request queue, retrieves the log write-to-disk request from the queue according to a preset scheduling strategy, reads log data from the target log memory area, and writes the log data to a persistent storage medium.

[0112] It should be noted that the computer program product of this embodiment corresponds to the above-described log writing method, log writing device, data processing unit, network card, computer equipment and computer-readable storage medium embodiments. For any content not described in detail, please refer to the foregoing embodiments.

[0113] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical applications, or technological improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A log writing method, the method being applied to the main control processing unit of a heterogeneous system, the heterogeneous system comprising the main control processing unit and at least one heterogeneous computing node, characterized in that, The method includes: A log write request is generated when any one of a variety of preset trigger conditions is met; the variety of preset trigger conditions include periodic trigger conditions based on time periods, graceful power-down trigger conditions based on system stop or power-down events, and manual trigger conditions based on user input commands. Add the log write-to-disk request to the log write-to-disk request queue; According to the preset scheduling strategy, the log write request is obtained from the log write request queue, the log data is read from the target log memory area according to the obtained log write request, and the log data is written to the persistent storage medium. The heterogeneous system includes multiple log memory areas, each of which stores log data generated by the main control processing unit or the corresponding heterogeneous computing node according to a preset log format.

2. The log writing method according to claim 1, characterized in that, The step of reading log data from the target log memory area according to the obtained log write request includes: When the log write-to-disk request queue is not empty, determine whether the log write-to-disk function is enabled. If the log write-to-disk function is enabled, then determine whether the dump mask is 0; the dump mask is used to indicate the log memory area that needs to be written to disk. If the dump mask is not 0, it is determined whether a log write request is currently being executed; If no log write request is currently in progress, log data is read from at least one log memory region according to the dump mask.

3. The log writing method according to claim 2, characterized in that, The step of reading log data from the target log memory area according to the obtained log write request includes: During the execution of the log write-to-disk request, the execution time of the log write-to-disk request is monitored. If the execution time exceeds a preset timeout threshold, the execution of the log write-to-disk request is terminated, and the dump mask is updated according to the current execution result of the log write-to-disk request. After the log write request is completed normally, the dump mask is set to 0.

4. The log writing method according to claim 1, characterized in that, The step of reading log data from the target log memory area according to the obtained log write request includes: When reading log data from the target log memory region, a unified abstract view of the memory log is obtained, and log data is read from the target log memory region according to the unified abstract view of the memory log; wherein, the unified abstract view of the memory log includes descriptive information of each log memory region, and the descriptive information includes at least one of the following: physical address of the log memory region, region size, and log format.

5. The log writing method according to claim 1, characterized in that, The method includes: A periodic timer is set up, which repeatedly generates timing signals at preset time intervals; wherein the preset time interval is dynamically configured according to user input instructions. Each time the timing signal is generated, if the periodic log write-to-disk function is enabled, then the periodic triggering condition is determined to be met.

6. The log writing method according to claim 1, characterized in that, The method includes: The system status information in the preset memory status address is obtained. If the system status information indicates that the system has stopped or is powered off, it is determined that the graceful power-off trigger condition is met. The system status information is written to the memory status address by the main control processing unit or the heterogeneous computing node.

7. The log writing method according to claim 6, characterized in that, The method includes: When the graceful power-down triggering condition is met, after writing the log data to the persistent storage medium, a file system synchronization operation is performed; and after the file system synchronization operation is completed, the system stop or power-down process is triggered.

8. The log writing method according to claim 1, characterized in that, The method includes: The system receives user input commands, parses the trigger parameters carried by the user input commands, and determines that the manual triggering conditions are met if the trigger parameters are preset valid trigger values.

9. A log writing device, wherein the log writing device is integrated into the main control processing unit of a heterogeneous system, characterized in that, For performing the log write-to-disk method as described in any one of claims 1 to 8, the log write-to-disk device comprises: The event monitoring unit is used to generate a log write request when any one of a variety of preset trigger conditions is met; the variety of preset trigger conditions include periodic trigger conditions based on time periods, graceful power-down trigger conditions based on system stop or power-down events, and manual trigger conditions based on user input commands. The log write-to-disk scheduling unit is used to add the log write-to-disk request to the log write-to-disk request queue; The log write-to-disk execution unit is used to obtain the log write-to-disk request from the log write-to-disk request queue according to a preset scheduling strategy, read log data from the target log memory area according to the obtained log write-to-disk request, and write the log data to the persistent storage medium. The heterogeneous system includes multiple log memory areas, each of which stores log data generated by the main control processing unit or the corresponding heterogeneous computing node according to a preset log format.

10. A data processing unit, characterized in that, Includes the log writing device as described in claim 9.

11. A network interface card (NIC), characterized in that, Includes the data processing unit as described in claim 10.

12. A computer device, characterized in that, It includes a host CPU and a network interface card (NIC) as described in claim 11, wherein the host CPU is used to process data scheduled by the NIC.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 8.

14. A computer program product, characterized in that, The computer program product includes computer program instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 8.

Images