A lightweight log processing method and multi-core processing system

Abstract

The application discloses a lightweight log processing method and a multi-core processing system, and relates to the technical field of data processing. The method comprises the following steps: a task core constructs a fixed-length binary log record based on a log to be recorded, caches the log record to a corresponding first cache area based on a core ID, and acquires a first index value of the corresponding first cache area; if the first index value is greater than or equal to a first preset value, a hardware queue message is constructed and written into a hardware queue; a management core polls the hardware queue, calls DMA based on the hardware queue message to store all log records in a target first cache area into a corresponding second cache area, and if a second index value is greater than or equal to a second preset value, a report message is constructed and sent to an ARM module; and the ARM module and based on the report message, log records of each target second cache area are subjected to string analysis and storage. Thus, the problem that the prior art takes a long time and occupies a high resource when recording physical layer logs is solved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a lightweight log processing method and a multi-core processing system. Background Technology

[0002] In modern base station systems, physical layer (PHY) processing tasks have high real-time requirements and are typically performed by dedicated digital signal processor (DSP) arrays. For problem localization and performance analysis, log printing statements are usually inserted into the PHY code. Traditional logging methods involve calling formatted output functions such as `snprintf` in the DSP's interrupt service routine or real-time task. The central processing unit (CPU) then performs computationally intensive operations such as string parsing, variable type conversion, and string concatenation to generate a complete, readable string before outputting it.

[0003] However, the aforementioned traditional methods have significant drawbacks: formatting operations consume a large amount of DSP CPU time and their execution duration is unpredictable, easily leading to timeouts or interruption delays in critical PHY layer tasks (such as symbol processing and channel decoding), severely impacting the stability and performance of the communication link. Furthermore, in intensive log scenarios, log operations compete with core communication services for computational and bandwidth resources, creating a resource conflict. To alleviate this problem, some existing solutions employ compromises such as reducing log frequency or recording only binary code, but these lead to new issues such as insufficient log information, poor readability, and difficulty in problem localization. Summary of the Invention

[0004] The main purpose of this application is to provide a lightweight log processing method and a multi-core processing system to solve the problems of long processing time and high resource consumption in the existing technology when recording physical layer logs.

[0005] To achieve the above objectives, this application provides a lightweight log processing method applied to a multi-core processing system. The multi-core processing system includes a DSP module and an ARM module. The DSP module includes multiple task cores, a hardware queue, a management core, a DMA, and multiple first caches and multiple second caches. Each task core corresponds one-to-one with each of the first caches. The method includes: The task core is used to obtain its core ID, and a fixed-length binary log record is constructed based on the log to be recorded. The log record is cached in the corresponding first cache area based on the core ID. The first index value of the corresponding first cache area is obtained. If the first index value is greater than or equal to a first preset value, the corresponding first cache area is used as the target first cache area. A hardware queue message is constructed and written to the hardware queue. The management core polls the hardware queue. When a hardware queue message is read from the hardware queue, the DMA is called based on the hardware queue message to store all log records in the target first buffer to the corresponding second buffer. The second index value of the corresponding second buffer is obtained. If the second index value is greater than or equal to a second preset value, the corresponding second buffer is used as the target second buffer. A reporting message is constructed and sent to the ARM module. The ARM module is used to parse and store the log records of each target's second buffer based on the reported message.

[0006] Optionally, each of the first cache areas is a ping-pong cache area, and the first cache area includes two first sub-areas; the step of caching the log record to the corresponding first cache area based on the core ID, and obtaining the first index value of the corresponding first cache area, and taking the corresponding first cache area as the target first cache area when the first index value is greater than or equal to a first preset value, includes: determining the first cache area corresponding to the task core based on the core ID, and determining the currently active first sub-area based on the active buffer indicator flag of the corresponding first cache area, and obtaining the base address, write index and current first preset value of the currently active first sub-area; caching the log record to the currently active first sub-area using the write index, and obtaining the first index value of the currently active first sub-area; taking the currently active first sub-area as the target first cache area when the first index value is greater than or equal to the current first preset value, inverting the active buffer indicator flag of the corresponding first cache area, and clearing the write index of the other first sub-area in the corresponding first cache area to zero.

[0007] Optionally, each of the second buffer areas is a ping-pong buffer area, and the second buffer area includes two second sub-areas; the step of calling the DMA based on the hardware queue message to store all log records in the target first buffer area to the corresponding second buffer area, and obtaining the second index value of the corresponding second buffer area, and taking the corresponding second buffer area as the target second buffer area when the second index value is greater than or equal to a second preset value, includes: determining the core ID of the target first buffer area based on the hardware queue message, and determining the corresponding second buffer area based on the core ID; determining the currently active second sub-area based on the active buffer indicator flag of the corresponding second buffer area, calling the DMA to store all log records in the target first buffer area to the currently active second sub-area, and accumulating the second index value of the currently active second sub-area; taking the currently active second sub-area as the target second buffer area when the second index value is greater than or equal to the second preset value, inverting the active buffer indicator flag of the corresponding second buffer area, clearing the write index of the other second sub-area in the corresponding second buffer area, and setting the pending reporting flag of the corresponding second buffer area.

[0008] Optionally, constructing a fixed-length binary log record based on the log to be recorded includes: determining the base address of the read-only data segment of the task core based on the core ID of the task core, and determining the offset based on the base address of the task core; constructing a fixed-length binary log record based on the offset and the log level, number of parameters, and values ​​of each parameter of the log to be recorded.

[0009] Optionally, before constructing a fixed-length binary log record based on the offset and the log level, number of parameters, and values ​​of each parameter of the log to be recorded, the method further includes: if the log level of the log to be recorded is lower than the dynamic global level of the multi-core processing system, then the log to be recorded is discarded.

[0010] Optionally, constructing the hardware queue message and writing it into the hardware queue includes: determining the starting address to be moved and the valid length of the log record to be moved in the target first buffer; constructing the hardware queue message based on the core ID, the starting address to be moved and the valid length of the log record to be moved; and calling the sending interface of the hardware queue to write the hardware queue message into the hardware queue.

[0011] Optionally, constructing and sending a reporting message to the ARM module includes: determining the cell identifier of the target second buffer, the starting address to be reported, and the effective data length of the target second buffer; constructing the reporting message based on the cell identifier of the target second buffer, the starting address to be reported, and the effective data length; and sending the reporting message to the ARM module using an inter-core interrupt mechanism.

[0012] Optionally, before using the ARM module to parse and store the log records of each target second buffer based on the reported message, the method further includes: using the management core to determine the time taken for the management core to complete the current iteration, and determining whether the current iteration meets the preset conditions based on the time taken for the current iteration, the preset baseline time, and the load tolerance coefficient; if the preset conditions are not met for a preset number of consecutive iterations, adjusting the first preset value and the second preset value.

[0013] Optionally, the step of using the ARM module and based on the reporting message to parse and store the log records of each target second buffer includes: using the ARM module to traverse the reporting flags of each second buffer based on the reporting message, and determining the target second buffer based on the reporting flags; for any log record in the target second buffer, looking up a preset mapping table based on the core ID corresponding to the log record to obtain the base address of the read-only data segment of the task core corresponding to the core ID, parsing the log record based on the base address and offset of the task core, and storing the parsed log record in the corresponding log file based on the core ID.

[0014] Furthermore, to achieve the above objectives, this application also provides a multi-core processing system, which includes a DSP module and an ARM module. The DSP module includes multiple task cores, a hardware queue, a management core, a DMA, multiple first caches, and multiple second caches. Each task core corresponds one-to-one with each of the first caches. Each task core is used to: obtain its core ID; construct a fixed-length binary log record based on the log to be recorded; cache the log record in the corresponding first cache based on the core ID; and obtain a first index value of the corresponding first cache. If the first index value is greater than or equal to a first preset value, the corresponding first cache is selected as the target first cache. The management core is used to poll the hardware queue, and when a hardware queue message is read from the hardware queue, it calls the DMA based on the hardware queue message to store all log records in the target first buffer into the corresponding second buffer, and obtains the second index value of the corresponding second buffer. If the second index value is greater than or equal to a second preset value, the corresponding second buffer is used as the target second buffer, and a reporting message is sent to the ARM module. The ARM module is used to parse and store the log records of each target second buffer based on the reporting message.

[0015] The lightweight log processing method of this application reduces the time spent on log recording at the physical layer by enabling the task cores in the DSP to directly construct fixed-length binary log records instead of performing any time-consuming string formatting operations and caching them in a first buffer corresponding one-to-one with the task cores. Secondly, when the first index value of the first buffer reaches a first preset value, a message is sent through a hardware queue, which is then polled and processed by the DSP's management core. DMA is then used to batch-transfer the binary log records in the first buffer to the second buffer, ensuring that the first buffer can continuously store the log records transmitted by the task cores. Finally, the string parsing operation is transferred to the ARM module for asynchronous execution, achieving layered decoupling between log recording and real-time services. This significantly reduces the blocking time and resource contention of the DSP task cores, thereby efficiently completing log recording without affecting the real-time performance of the physical layer. Attached Figure Description

[0016] Figure 1 This is one of the flowcharts of a lightweight log processing method according to an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a multi-core processing system according to an embodiment of this application; Figure 3 This is the second flowchart of the lightweight log processing method according to an embodiment of this application; Figure 4This is the third flowchart of the lightweight log processing method according to an embodiment of this application; Figure 5 This is the fourth flowchart of the lightweight log processing method according to an embodiment of this application; In the diagram, 100 is the DSP module; 200 is the ARM module.

[0017] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] In modern base station systems, physical layer (PHY) processing tasks have high real-time requirements and are typically performed by dedicated digital signal processor (DSP) arrays. To facilitate problem localization and performance analysis, developers need to insert log printing statements into the PHY code to record critical states and events during system operation.

[0020] The traditional and widely used logging method is to call formatted output functions such as snprintf. The basic process is as follows: in the interrupt service routine or real-time task of the DSP, the central processing unit (CPU) performs a series of computationally intensive operations such as parsing the formatted string, variable type conversion, and string concatenation to generate a complete readable string, and finally outputs the string to the base station front end or storage medium.

[0021] However, the traditional logging methods described above have the following significant drawbacks in practical applications: First, formatting operations (such as string parsing, type conversion, and concatenation) consume a large amount of DSP CPU time, and their execution time is unpredictable. This can easily lead to timeouts or interruptions in critical tasks of the PHY layer (such as symbol processing and channel decoding), which in turn directly affects the stability and performance of the communication link.

[0022] Secondly, in scenarios with intensive logging, logging operations themselves become a system load, competing with core communication services for computing resources and memory bandwidth. Especially in multi-core DSP environments, log printing may block or interfere with other real-time tasks, creating resource contention and reducing the overall system throughput.

[0023] To alleviate the aforementioned problems, some existing solutions employ compromises such as reducing log frequency or recording only binary code. However, these methods lead to new issues, including insufficient log information, poor readability, and difficulty in problem localization. Specifically, reducing log frequency may result in the loss of critical timing information; while recording only binary code reduces formatting overhead, developers find it difficult to directly understand the log content, requiring additional tools or manual decoding for subsequent analysis, thus increasing maintenance costs.

[0024] Therefore, how to achieve efficient, readable and resource-friendly log recording without affecting the real-time performance of the base station PHY layer has become a technical problem that urgently needs to be solved in this field.

[0025] To address this issue, this application provides a lightweight log processing method and a multi-core processing system to solve the problems of long processing time and high resource consumption in the recording of physical layer logs in the prior art.

[0026] Figure 1 This is one of the flowcharts for a lightweight log processing method according to an embodiment of this application. For example... Figure 1 As shown, this lightweight log processing method may include the following steps: Step 110: Obtain the core ID of the task core, construct a fixed-length binary log record based on the log to be recorded, cache the log record to the corresponding first cache area based on the core ID, and obtain the first index value of the corresponding first cache area. If the first index value is greater than or equal to the first preset value, use the corresponding first cache area as the target first cache area, construct a hardware queue message and write it to the hardware queue.

[0027] Step 120: Use the management core to poll the hardware queue. If a hardware queue message is read from the hardware queue, call DMA based on the hardware queue message to store all log records in the target first buffer to the corresponding second buffer, and obtain the second index value of the corresponding second buffer. If the second index value is greater than or equal to the second preset value, use the corresponding second buffer as the target second buffer, construct it and send a reporting message to the ARM module.

[0028] Step 130: Use the ARM module and based on the reported messages to parse and store the log records of the second buffer of each target as strings.

[0029] First, it should be noted that the lightweight log processing method of this application embodiment can be applied to a multi-core processing system. The multi-core processing system includes a DSP module and an ARM module. The DSP module includes multiple task cores, a hardware queue, a management core, a DMA, multiple first caches, and multiple second caches. Each task core corresponds one-to-one with each first cache.

[0030] For ease of understanding, the multi-core processing system of this application embodiment will be described in detail below.

[0031] Figure 2 This is a schematic diagram of the structure of a multi-core processing system according to an embodiment of this application. Figure 2 As shown, the multi-core processing system of this application adopts a DSP+ARM heterogeneous multi-core architecture, including a DSP module 100 and an ARM module 200.

[0032] The DSP module 100 is further divided into a producer side and a consumer side. The producer side includes multiple task cores and a corresponding first buffer for each task core. Specifically, a task core refers to a PHY service processing core, and each task core is responsible for real-time signal processing at the physical layer. It should be noted that the number of task cores can be set by the operator according to actual needs; for example, the maximum number of task cores can be eight. Each task core is connected one-to-one with a first buffer, which is located in an on-chip shared random access memory accessible by both the DSP and ARM.

[0033] In this embodiment, the first buffer uses a ping-pong buffer. Each first buffer includes two first sub-regions, which can be denoted as first sub-region A and first sub-region B. The size of each first sub-region can be a fixed 64KB, and its internal organization is an array of fixed-length binary log record structures. For example, if each fixed-length binary log record is 28 bytes, then one first sub-region can store 2340 log records. Each first sub-region also maintains a write index, a first preset value, and an active buffer indicator flag. It should be noted that the write index is used to indicate the write position of the next log record; the first preset value can be represented by the number of log records. The first preset value can be set by the staff according to actual needs, or it can be dynamically adjusted by the multi-core processing system. For example, the initial default value of the first preset value is three-quarters of the buffer capacity, that is, about 1755 log records; the active buffer indicator flag is used to identify the first sub-region currently in use by the first buffer, so that log records can be cached to the currently used first sub-region in the future.

[0034] Hardware queues can be used as hardware resources within the DSP for inter-core message passing, connecting the task cores on the producer side and the management core on the consumer side. Each task core sends a "buffer full" notification message to the management core through the hardware queue, and the management core reads these messages from the hardware queue in a polling manner.

[0035] On the consumer side of DSP module 100, the management core runs the main loop. One loop iteration process includes: continuously polling the hardware queue. When a message is read from the hardware queue, the management core parses the message, obtains the starting address and data length of the corresponding target first buffer, and then configures the DMA controller to move all the binary log records continuously stored in the target first buffer to the corresponding cell's second buffer in one go.

[0036] In this embodiment, the second buffer also employs a ping-pong buffer. Each second buffer includes two second sub-regions, which can be denoted as second sub-region A and second sub-region B. The size of each second sub-region can be 1M bytes, and each second sub-region is organized as an array of fixed-length log record structures. For example, if each fixed-length binary log record is 28 bytes, then one second sub-region can store approximately 37,449 log records. The size of the second buffer is much larger than the first buffer on the producer side, thus facilitating the aggregation of log records from multiple task cores.

[0037] Furthermore, each cell corresponds to a second buffer, and each second buffer is also located in shared memory, which the ARM module 200 can directly access. Each second buffer also maintains a write index, a second preset value, a cell identifier, and a pending report flag. It should be noted that the maximum number of cells on the consumer side can be 4, therefore the maximum number of second buffers is also 4. In addition, the cell identifier is used to identify the cell; the second preset value can be represented by the number of log entries, and the second preset value can be set by the staff according to actual needs, or it can be dynamically adjusted by the multi-core processing system. For example, the initial default value of the second preset value is half of the buffer capacity; the active buffer indicator flag is used to identify the second sub-area currently in use by the second buffer, so that subsequent log records can be cached to the currently used second sub-area; the pending report flag is used to indicate that at least one second sub-area of ​​the current second buffer is full.

[0038] Upon receiving an inter-core interrupt, the ARM module 200 is awakened and executes the main task of writing logs to disk. Specifically, the ARM module 200 runs an independent user-mode process dedicated to parsing log records and writing them to disk. This user-mode process communicates with the consumer-side management core via shared memory and inter-core interrupts.

[0039] Referring to the specific structure of the multi-core processing system in the aforementioned example, the lightweight log processing method of this application embodiment will be described in detail below.

[0040] Before executing step 110, the multi-core processing system needs to be initialized upon startup. Specifically, during system startup, ARM first reserves a contiguous address space in shared memory. This space is allocated to arrays of the first cache regions on the producer side according to the maximum number of task cores (8), and to arrays of arrays of the second cache regions on the consumer side according to the maximum number of cells (4). ARM records the base address of each cache region in a global variable so that subsequent modules can quickly locate it using an index.

[0041] After each task core starts, it sends the base address of its own read-only data segment to the management core via a hardware queue. The management core collects the base addresses of all task cores and forwards this information to the ARM. The ARM maintains a mapping table indexed by the core ID, recording the base address of the read-only data segment for each task core. For example, if core 0 reports a base address of 0x80000000 and core 1 reports a base address of 0x80001000, the ARM stores these two addresses in the 0th and 1st entries of the mapping table, respectively. This way, when the ARM parses the logs, it can quickly find the base address of the corresponding core's read-only data segment based on the core ID recorded in the log, and then use the offset to locate the specific format string.

[0042] After the multi-core processing system starts, the management core can determine the preset baseline duration based on the execution time of the main loop under system idle or typical business load conditions. The specific process is as follows: the management core continuously executes 1000 iterations of the main loop. Each iteration includes complete operations such as polling the hardware queue, processing received messages, performing DMA transfers, and checking reporting conditions. The management core measures the time of each iteration and calculates the arithmetic mean of all iteration times as the preset baseline duration, which can be denoted as T_base, typically in microseconds. Simultaneously, a load tolerance factor of 1.2 is set. This preset baseline duration is used for subsequent dynamic adjustments to the first and second preset values.

[0043] The management core initializes and configures the hardware queue, designating itself as the receiver. This means that all messages sent by task cores through the hardware queue will be transmitted to the management core. Simultaneously, the management core clears any old messages or residual data from the hardware queue, ensuring it is clean upon startup and preventing the processing of invalid messages. The hardware queue employs the DSP's internal hardware message passing mechanism, characterized by low latency and determinism, and is used to transmit brief reporting notifications between the task cores and the management core.

[0044] During startup, the ARM uses a memory mapping interface to map shared memory regions into its own address space. Since shared memory is physical memory accessible to both the DSP and ARM, the ARM needs to map it into its virtual address space before it can directly read and write to it. After mapping, the ARM obtains the base address of each secondary buffer, which is the starting position of the secondary buffer corresponding to each cell in the ARM's virtual address space. Afterward, the ARM can access the log records in these buffers like ordinary memory.

[0045] The ARM receives the base address mapping table of the read-only data segment from each task core, forwarded by the management core, and stores it in its own memory. Simultaneously, the ARM loads the program image file of each task core and extracts the contents of the read-only data segment. Since each task core's read-only data segment stores the format string text that might be used for all log calls of that core, the ARM needs to establish a mapping relationship from the base address to the format string storage area. Specifically, the ARM finds the base address of the read-only data segment of that core based on the core ID, and then, combined with the offset in the log record, calculates the absolute address of the format string in the ARM address space, thus directly reading the string text. For example, if the base address of the read-only data segment of core 0 is 0x80000000, and the offset of a certain log record is 0x100, then the ARM calculates 0x80000000 + 0x100 to obtain the storage address of the string, and reads the null-terminated format string, such as "received data packet length = %d".

[0046] ARM creates a separate log file for each task core, named " / var / log / dspX.log", where X is the core number, ranging from 0 to 7. Each log file is opened in append mode, ensuring that subsequent log entries are appended to the end of the file without overwriting existing records. Additionally, ARM sets up a file buffer for each file to reduce the number of direct disk writes and improve log writing performance.

[0047] ARM registers an inter-core interrupt handler to respond to interrupt notifications sent by the management core. This interrupt handler performs only the lightest operations within the interrupt context: setting an event flag and waking up the waiting log writing master task. All time-consuming operations, such as traversing the small buffer, parsing binary log records, calling formatting functions, and writing to files, are performed within the awakened master task. This ensures real-time interrupt response while avoiding potentially blocking or time-consuming operations within the interrupt context.

[0048] Therefore, the multi-core processing system is initialized through the above process, thereby ensuring the normal operation of the subsequent log recording process.

[0049] In step 110, after the multi-core processing system completes initialization, the task core first obtains its own core identifier, i.e., core ID, by reading the DSP processor's dedicated registers. For example, in an eight-core DSP system, core 0 has a core ID of 0, core 1 has a core ID of 1, and so on. After obtaining the core ID, the task core constructs a fixed-length binary log record based on the log information to be recorded. For example, when recording a log message "Received data packet, length 1024 bytes," the traditional method would call snprintf to generate a string; however, in this application, the task core only fills the log offset, number of parameters, parameter values, etc., into a fixed-size structure in a compact binary format, generating a 28-byte binary record that does not contain any readable strings.

[0050] Furthermore, the task core locates the uniquely corresponding first buffer based on its own core ID and caches the binary log record in the first buffer. Simultaneously, the task core obtains the first index value of the first buffer, which can be understood as a counter for the number of cached log records. For example, if 100 records have been written to the first buffer, the first index value is 100. The task core then determines whether the first index value is greater than or equal to a preset first threshold, which is a dynamic reporting threshold, such as three-quarters of the buffer capacity. For a 64KB buffer that can store 2340 records, the first threshold is approximately 1755 records.

[0051] When the first index value reaches or exceeds the first preset value, the task core determines the currently used first buffer as the target first buffer and constructs a hardware queue message. Finally, the task core writes the hardware queue message into the hardware queue, thereby triggering subsequent consumer-side processing. Through the above process, the task core performs only minimal operations such as register reading, binary log construction, counter comparison, and message enqueueing in the real-time task, completely avoiding the uncertain time consumption caused by string formatting and ensuring the real-time performance of physical layer processing.

[0052] Figure 3 This is the second flowchart of a lightweight log processing method according to an embodiment of this application. Figure 3 As shown, in some implementations, constructing a fixed-length binary log record based on the log to be recorded may include the following steps: Step 310: Based on the core ID of the task core, determine the base address of the read-only data segment of the task core, and determine the offset based on the base address of the task core; Step 320: Based on the offset and the log level, number of parameters, and values ​​of each parameter of the log to be recorded, construct a fixed-length binary log record.

[0053] In this embodiment, the task core first needs to obtain the base address of its read-only data segment based on its own core ID. It's important to note that the read-only data segment is a fixed area loaded into shared memory by each task core during system startup. It stores read-only data specific to that core, such as log formatting strings. Since each task core has an independent read-only data segment, its base address is determined after compilation and linking and remains unchanged during system runtime. For example, core 0's read-only data segment might start at address 0x80000000, core 1 at 0x80001000, and so on. During runtime, the task core can directly read the processor's dedicated registers to obtain its core ID, and then quickly find the starting address of its read-only data segment using a globally maintained mapping table from core ID to base address.

[0054] Furthermore, the task core determines the offset of the format string relative to the aforementioned base address based on the log to be logged. It should be noted that the offset refers to the difference between the position of a specific format string within its respective read-only data segment and the base address of that segment. As an example, suppose the base address of the read-only data segment of core 0 is 0x80000000, which stores multiple null-terminated format strings, such as "Received packet length=%d" and "Sending status=%d". If the log entry "Received packet length=1024" needs to be logged, the corresponding format string "Received packet length=%d" might be stored at byte 0x100 of the read-only data segment, and the offset of this string would be 0x100.

[0055] Offset calculation can be done at compile time: the compiler allocates the format string used for each log call point to a read-only data segment and records its offset relative to the beginning of the segment. The task core does not need to recalculate it at runtime; it simply loads the offset from the code's immediate values ​​or constant table. For example, when the log macro expands, the compiler automatically passes the offset 0x100 of the format string "Received packet length = %d" as a parameter to the underlying function, and the task core directly uses this value, avoiding the overhead of dynamically looking up the string.

[0056] After obtaining the format string offset, the task core begins constructing a fixed-length binary log record. In this embodiment, the log record uses a fixed-size 28-byte structure, independent of the actual length of the format string. Each log record is of fixed length, thus avoiding the repeated storage of lengthy format strings in shared memory. The construction process requires filling in four parts: the format string offset, the log level, the number of parameters, and an array of parameter values.

[0057] Log levels are used to identify the severity of log entries and typically include different levels such as debug, information, warning, and error. To save storage space, log levels occupy only 3 bits in the record. For example, level 0 is defined as debug, level 1 as information, level 2 as warning, and level 3 as error. When an error log entry needs to be recorded, the task core fills the corresponding field with the level value 3.

[0058] The parameter count indicates the number of variable parameters included in this log entry, with a maximum of 6 parameters supported. This field also occupies 3 bits, and the actual number of parameters written can be an integer from 0 to 6. For example, if the log needs to output two parameters, such as "received packet length=%d, port=%u", then the parameter count is 2.

[0059] The parameter value array always contains six 32-bit unsigned integer elements, storing the actual values ​​of each parameter passed during the call in sequence. Even if there are fewer than six actual parameters, the remaining positions need to be padded with zeros to ensure that the size of each log record is completely consistent. For example, if a log entry only carries two parameters: length 1024 and port 8080, then the first two elements of the parameter value array are 1024 and 8080, and the last four elements are all 0.

[0060] The following example further illustrates the process of constructing a binary log record. Assume task core 2 needs to record a warning log with the format string "Temperature too high, current temperature = %d degrees Celsius", and this string has an offset of 0x200 in its read-only data segment. A parameter value of 85 is passed in during the call. The task core performs the following operations: First, it fills the first 26 bits of the record with the format string offset 0x200; second, it sets the log level to 2 (warning); then, it counts the number of parameters as 1 and fills it into the parameter count field; finally, it puts the parameter value 85 into the first element of the parameter value array, and fills the remaining five elements with 0. This 28 bytes of data constitute a complete binary log record. Subsequently, the task core writes this record to its first buffer. The entire process requires no string formatting operations, is extremely fast, and is highly deterministic.

[0061] In some implementations, before constructing a fixed-length binary log record based on the offset and the log level, number of parameters, and values ​​of each parameter of the log to be recorded, the lightweight log processing method may further include: if the log level of the log to be recorded is lower than the dynamic global level of the multi-core processing system, then the log to be recorded is discarded.

[0062] It's important to note that the dynamic global level refers to a dynamically adjustable threshold variable maintained by the system during operation, used to control the minimum log level currently allowed to be recorded. Users can modify this global level value in real time on the ARM or DSP management core based on system load or business scenarios. As an example, log level values ​​can be defined as follows: 0 for errors (highest severity), 1 for warnings, 2 for information, and 3 for debug (lowest severity). If the current dynamic global level is set to 2 (i.e., information level and above), only logs at levels 0, 1, and 2 will be recorded; debug logs at level 3 will be discarded. If the system is under high load, the global level can be dynamically adjusted to 1 (warning and above), at which point information and debug logs will be filtered out, significantly reducing log generation and lowering the burden on real-time tasks and transmission resources. Conversely, during troubleshooting, the global level can be adjusted to 3 to record logs at all levels for detailed analysis.

[0063] Specifically, the task core can obtain the log level of the current log to be logged and compare it with the current dynamic global level. If the value of the current log level is greater than or equal to (or, by definition, "less than" means lower severity) the value of the dynamic global level, it indicates that the severity of the log is lower than the threshold currently required by the system and should be discarded; otherwise, if the severity of the current log level is higher than or equal to the threshold, the subsequent binary record construction process continues. Through this dynamic filtering mechanism, the system can flexibly control the granularity of log output without modifying the code, achieving a balance between ensuring real-time performance and obtaining sufficient debugging information.

[0064] In some implementations, caching log records to the corresponding first cache area based on the kernel ID, and obtaining the first index value of the corresponding first cache area, and using the corresponding first cache area as the target first cache area if the first index value is greater than or equal to a first preset value, may include: The first cache corresponding to the task core is determined based on the core ID, and the currently active first sub-area is determined based on the active buffer indicator flag of the corresponding first cache. The base address, write index and current first preset value of the currently active first sub-area are obtained. Log records are cached to the currently active first sub-area using the write index, and the first index value of the currently active first sub-area is obtained. If the first index value is greater than or equal to the current first preset value, the currently active first sub-area is taken as the target first cache, the active buffer indicator flag of the corresponding first cache is inverted, and the write index of another first sub-area in the corresponding first cache is cleared to zero.

[0065] In this embodiment, after the task core constructs the binary log record of the log to be cached, the task core can quickly locate its own first cache area by looking up its own core ID in a table. Each first cache area is divided into two first sub-areas of the same size, denoted as first sub-area A and first sub-area B, respectively. The first cache area maintains an active buffer indicator flag, which indicates which first sub-area should be written to at present. For example, when the active buffer indicator flag is 0, it means that the currently active first sub-area is A, and when the flag value is 1, it means that the currently active first sub-area is B.

[0066] Before writing to the log record, the task core first reads the value of the active buffer indicator flag to determine the first sub-region to be written. Simultaneously, the task core also needs to obtain the base address, write index, and current first preset value of this first sub-region.

[0067] After obtaining the base address and write index of the currently active first sub-region, the task core writes the previously constructed 28-byte fixed-length binary log record to the memory location indicated by the write index through a memory copy operation. After writing is complete, the task core increments the write index by one. The value of the write index at this point is the number of log records currently occupied by that sub-region; this value is the first index value described in this embodiment. In other words, the first index value is the latest value of the write index, indicating the total number of log records successfully written to that sub-region.

[0068] After each write operation, the task core compares the updated first index value with the current first preset value. If the first index value is less than the first preset value, the write process ends, and the task core can return to continue executing the main task. If the first index value is greater than or equal to the first preset value, it indicates that the currently active first sub-region has stored enough log records, and a reporting mechanism needs to be triggered. It should be noted that the first preset value is a dynamically adjustable threshold. For example, under normal load, the first preset value can be set to three-quarters of the first sub-region's capacity (approximately 1755 records), while under high load, the first preset value can be set to half of the capacity (approximately 1170 records).

[0069] Specifically, when the first index value reaches or exceeds the first preset value, the task core marks the currently used first sub-area as the target first buffer. The target first buffer refers to the data source area that is about to be moved. Further, the task core constructs a hardware queue message and writes the hardware queue message to the hardware queue, so that the management core stores all log records in the currently full first sub-area to the corresponding second buffer.

[0070] Figure 4 This is the third flowchart of a lightweight log processing method according to an embodiment of this application. Figure 4As shown, in some implementations, constructing a hardware queue message and writing it to the hardware queue may include the following steps: Step 410: Determine the starting address to be moved and the valid length of the log record to be moved in the first buffer of the target; Step 420: Construct a hardware queue message based on the core ID, the starting address to be moved, and the effective length of the log record to be moved; Step 430: Call the hardware queue's send interface to write the hardware queue message into the hardware queue.

[0071] Specifically, when the task core determines that the first index value of the currently active first sub-region reaches or exceeds a first preset value, that first sub-region is identified as the target first cache region. At this point, the task core needs to determine the starting address to be moved and the effective length of the log records to be moved. It should be noted that the starting address to be moved refers to the base address of the target first cache region (i.e., the first sub-region to be moved) in shared memory; for example, if the base address of the first sub-region A is 0x80020000, then this address is the starting address to be moved. Furthermore, the effective length of the log records to be moved refers to the total number of bytes occupied by the log records actually stored in the first sub-region, calculated by multiplying the first index value (i.e., the number of records already written) by the fixed length of each log record (e.g., 28 bytes). For example, if the first index value is 1755 and the length of a single record is 28 bytes, then the effective length is 1755 × 28 = 49140 bytes. These two parameters will be used to notify the management core where and how much data to move.

[0072] Furthermore, the task core encapsulates the core ID, the starting address to be transferred, and the effective length of the log record to be transferred into a hardware queue message. After constructing the hardware queue message, the task core calls the send interface provided by the hardware queue to write the message to the hardware queue. This send interface is typically a non-blocking function call; the task core only needs to write the starting address of the message or directly to a dedicated queue register to trigger the hardware to push the message to the end of the queue. Since the hardware queue itself is a first-in, first-out hardware resource, the write operation only requires a few processor cycles to complete and will not occupy the task core for a long time. After sending is completed, the task core can immediately return to continue executing subsequent operations without waiting for the management core's response. This non-blocking sending method ensures that the task core will not be blocked by queue operations even in dense log scenarios, thereby maintaining the real-time performance of physical layer processing.

[0073] After sending the hardware queue message, the task core needs to immediately switch the active buffer so that subsequent log writing can continue. Specifically, first, the active buffer indicator flag in the first buffer is inverted. For example, if the original flag was 0 (indicating that first sub-area A is active), it becomes 1 after inversion (indicating that first sub-area B is active). In this way, subsequent log records will be automatically written to the other first sub-area. Second, the task core clears the write index of the newly switched first sub-area to zero. It is understandable that the other first sub-area may have already had data moved by the management core via DMA, or it may not have been used yet, but its write index may retain the old value from the last use. Clearing it directly ensures that writing can start from the beginning of that first sub-area.

[0074] As an example, assume that the first buffer of task core 2 contains first sub-region A (address range 0x80020000-0x80030000) and first sub-region B (address range 0x80030000-0x80040000), with the current activity flag set to 0 (first sub-region A is active), and the first preset value being 1755. Task core 2 has already written 1750 log records to first sub-region A, with a write index of 1750. When the 1751st log record arrives, the task core writes it to the 1751st position in first sub-region A and then updates the write index to 1751. At this point, the first index value 1751 is less than 1755, so no reporting is triggered. Writing continues until the 1755th log record is written, at which point the first index value becomes 1755, equal to the first preset value. At this point, task core 2 identifies first sub-region A as the target first buffer, constructs a message and sends it to the hardware queue, then inverts the activity flag to 1 and clears the write index of first sub-region B to zero. Subsequent new log entries will be written to the first sub-region B, starting at address 0x80030000, while the data in the first sub-region A awaits transfer by the management core via DMA.

[0075] In some implementations, DMA is invoked based on hardware queue messages to store all log records in the target first buffer to the corresponding second buffer, and the second index value of the corresponding second buffer is obtained. If the second index value is greater than or equal to a second preset value, the corresponding second buffer is used as the target second buffer. This may include: The kernel ID of the target first buffer is determined based on the hardware queue message, and the corresponding second buffer is determined based on the kernel ID. The currently active second sub-region is determined based on the active buffer indicator flag of the corresponding second buffer. DMA is called to store all log records in the target first buffer to the currently active second sub-region, and the second index value of the currently active second sub-region is incremented. If the second index value is greater than or equal to the second preset value, the currently active second sub-region is taken as the target second buffer, the active buffer indicator flag of the corresponding second buffer is inverted, the write index of another second sub-region in the corresponding second buffer is cleared, and the pending reporting flag of the corresponding second buffer is set.

[0076] Specifically, the management core calls the hardware queue's receive interface to attempt to read a message from the hardware queue. If the management core reads a message from the hardware queue, it calls the message processing function; otherwise, it continues to wait. It should be noted that, to process multiple hardware queue messages promptly, the management core will continuously read in a single main loop until the hardware queue is empty, thus avoiding message backlog.

[0077] The message processing function executes the following steps: First, it parses the core ID from the hardware queue message and determines the cell identifier to which the task core belongs based on the core ID. It's understandable that since each task core in the system belongs to a specific cell (e.g., cores 0 and 1 belong to cell 0, and cores 2 and 3 belong to cell 1), the management core maintains a mapping table between core IDs and cell IDs. The management core queries this table using the core ID as an index to obtain the cell identifier to which the task core belongs.

[0078] Furthermore, the management core locates the corresponding second buffer for a given cell based on the cell identifier. For example, if task core 2 belongs to cell 1, and its hardware queue message arrives, the management core finds the cell ID to be 1 and thus locates the second buffer for cell 1. In this way, log records from different task cores within the same cell are aggregated into the same second buffer, facilitating subsequent batch processing by the ARM architecture.

[0079] Each second buffer is also divided into two equal-sized sub-regions, denoted as Sub-region A and Sub-region B, each 1MB in size. The second buffer also maintains an active buffer indicator flag to identify which sub-region should be written to. For example, an active buffer indicator flag of 0 indicates that sub-region A is currently active, and a flag of 1 indicates that sub-region B is currently active. Before starting the transfer, the management core reads the value of this flag to determine the target sub-region for this DMA write. Simultaneously, the management core also needs to obtain the base address of the sub-region, the current write index (i.e., the number of records already stored), and the current second preset value.

[0080] Further, the management core configures the DMA controller and initiates a one-dimensional DMA transfer. The three key parameters for DMA transfer are: source address (the starting address of the target first buffer carried in the hardware queue message); destination address (the write pointer position of the currently active second sub-region, calculated as the second sub-region's starting address plus the current write index multiplied by the length of a single log record); and transfer length (the length of the valid data carried in the message). After configuration, the management core initiates the DMA transfer. The DMA controller independently completes the data copy in the background, without consuming the management core's processor time. The management core can choose to poll the DMA status register or wait for a DMA completion interrupt to determine when the transfer is finished. Because DMA is dedicated data transfer hardware, it can transfer continuous data from the target first buffer to the corresponding second buffer at a very high speed, ensuring data order and integrity.

[0081] After the DMA transfer is complete, the management core needs to update the write index of the currently active second sub-region. The increase in the write index is equal to the number of log records transferred, which is the transfer length divided by the fixed length of each record (28 bytes). For example, if the transfer length is 49140 bytes, then the number of records is 49140 ÷ 28 = 1755. The management core adds this value to the original write index of the currently active second sub-region to obtain a new write index value, which is called the second index value. For example, if the original write index was 1000, adding 1755 results in a second index value of 2755. The second index value is actually the total number of log records currently stored in the second sub-region. The management core writes this new value back to the control variable of the second sub-region for subsequent determination of whether to report.

[0082] After completing the transfer of all pending messages, the management core traverses all cells and performs the following check on the second buffer corresponding to each cell: comparing the second index value of the currently active second sub-area in the second buffer with the second preset value. It should be noted that the second preset value is a threshold dynamically adjusted based on system load. For example, under normal load, it is half the capacity of the second sub-area (1MB can store approximately 37,449 records, half is approximately 18,724 records), while under high load, it may be adjusted to three-quarters (approximately 28,087 records).

[0083] If the second index value is less than the second preset value, no reporting is triggered, and the management core continues processing the next hardware queue message. If the second index value is greater than or equal to the second preset value, it indicates that the current second sub-area has accumulated enough log records, and the ARM needs to be notified to retrieve them. At this time, the management core performs the following second sub-area switching operation: First, the currently active second sub-area is determined as the target second buffer. Further, the active buffer indicator flag of this second buffer is inverted. For example, if the original flag was 0 (second sub-area A is active), it becomes 1 after inversion (second sub-area B is active), so subsequent log records will be written to another second sub-area. Next, the management core clears the write index of the newly switched second sub-area to zero, ensuring that the new second sub-area is used starting from the starting address.

[0084] When switching to the second sub-cell, the management core needs to set the reporting flag for that second buffer. The reporting flag is used to notify the ARM module 200 that a certain second sub-cell of a certain cell has data waiting to be processed. In some implementations, the second buffer can correspond to two reporting flag bits, respectively indicating whether there is data to be reported in second sub-cell A and second sub-cell B. For example, when second sub-cell A reaches a threshold, the management core sets the reporting flag for second sub-cell A to 1.

[0085] As an example, assume that the current write index of the second sub-area A in the second buffer of cell 1 is 18700, and the second preset value is 18724. The management core continuously processes multiple messages from task cores 2 and 3, accumulating the write index after each DMA transfer. When the accumulated value reaches 18730, the second index value 18730 is greater than or equal to 18724, triggering a report. The management core identifies the second sub-area A as the target second buffer, inverts the active flag from 0 to 1 (switching to the second sub-area B), and clears the write index of the second sub-area B to zero. Simultaneously, it sets the pending report flag for the second sub-area A corresponding to cell 1 to 1.

[0086] Figure 5 This is the fourth flowchart of a lightweight log processing method according to an embodiment of this application. Figure 5 As shown, in some implementations, constructing and sending a reporting message to the ARM module 200 may include the following steps: Step 510: Determine the cell identifier, the starting address to be reported, and the effective data length of the target second buffer; Step 520: Construct a reporting message based on the cell identifier of the target second buffer, the starting address to be reported, and the effective data length; Step 530: Send a reporting message to ARM module 200 using the inter-core interrupt mechanism.

[0087] Specifically, when the management core determines that the second index value of the currently active second sub-region has reached or exceeded the second preset value, the second sub-region is identified as the target second buffer. At this time, the management core needs to determine three key parameters: cell identifier, reporting start address, and effective data length. The cell identifier refers to the cell identifier to which the second buffer belongs, such as cell 0, cell 1, cell 2, or cell 3, used to inform the ARM module 200 which cell's second buffer is full. The reporting start address refers to the base address of the target second buffer in shared memory. For example, if the base address of second sub-region A of cell 1 is 0x80300000, then this address is the reporting start address. The effective data length refers to the total number of bytes occupied by the log records actually stored in the second sub-region, which is calculated by multiplying the second index value by the fixed length of each log record. For example, if the second index value is 18730 records, and the length of a single record is 28 bytes, then the effective length is 18730 × 28 = 524440 bytes, approximately 512KB. These three parameters will be used to inform the ARM module 200 where to read how much data, and which cell this data belongs to.

[0088] The management core encapsulates the above three key pieces of information into a single reporting message. Specifically, the management core fills the cell identifier of the target second buffer, the starting address to be reported, and the effective data length into a predefined structure variable in a fixed order, or directly writes them into a set of dedicated registers to form a complete reporting message.

[0089] After constructing the reporting message, the management core sends it to the ARM module 200 via the inter-core interrupt mechanism. Inter-core interrupts are a hardware-supported inter-processor communication method that allows one processor core to directly trigger an interrupt from another core. The specific steps are as follows: the management core writes the content of the reporting message to a pre-agreed set of shared registers, or directly to the ARM's interrupt message buffer, and then sends a specific inter-core interrupt signal to the ARM module 200. The ARM module 200 has pre-registered an interrupt handler function for this interrupt. When the interrupt signal arrives, the ARM hardware automatically saves the current context and jumps to the interrupt handler function for execution. In the interrupt handler function, the ARM module 200 can read the reporting message from the shared registers and obtain the cell identifier, starting address, and valid data length. To keep the interrupt context lightweight, the interrupt handler function typically only sets an event flag and wakes up the background log writing main task, without immediately performing time-consuming log parsing and writing operations. In this way, the transmission of the reporting message ensures real-time performance while avoiding processing large amounts of data in the interrupt context.

[0090] In some implementations, before using the ARM module 200 to parse and store the log records of each target second buffer based on the reported message, the lightweight log processing method may further include: using the management core to determine the time taken for the management core to complete the current iteration, and determining whether the current iteration meets the preset conditions based on the time taken for the current iteration, the preset baseline time, and the load tolerance coefficient; if the preset conditions are not met for a preset number of consecutive iterations, adjusting the first preset value and the second preset value.

[0091] First, it should be noted that the management core runs a main loop, and each iteration of the loop includes a series of fixed operations: polling the hardware queue and processing all messages to be received, configuring DMA transfer for each message, waiting for DMA to complete, accumulating the write index of each second sub-region, checking whether each second sub-region has reached the reporting threshold, and triggering reporting and switching sub-regions if necessary. The iteration described in this embodiment is one main loop.

[0092] At the start of each iteration, the management core records a start timestamp, and at the end of the iteration, it records an end timestamp. The difference between the two is the actual elapsed time of this iteration. The unit of this duration is usually microseconds or nanoseconds, depending on the timing accuracy of the system. The elapsed time of the current iteration reflects the true load situation of the management core when handling the log transfer task: if there are many messages in the hardware queue, a large amount of DMA transferred data, or frequent reporting operations, the iteration time will be longer; conversely, if the log generation frequency is low, the iteration time will be shorter. For example, when the system is idle, an iteration may only take dozens of microseconds; while during the peak business period, an iteration may last for hundreds of microseconds or even milliseconds because a large number of messages need to be processed and multiple DMA transfers need to be performed.

[0093] The load tolerance factor is used to set the allowable range of elapsed time fluctuations to avoid unnecessary threshold adjustments triggered by accidental instantaneous load increases. This factor can be obtained through experiments or system calibration. Further, during system initialization, the management core runs 1000 iterations under no-load or typical business loads, measures the elapsed time of each iteration, and takes the average to obtain the preset reference duration (denoted as T_base). Then, the load tolerance factor is set to 1.2, indicating that the allowable actual elapsed time can be at most 20% higher than the reference duration. As an example, if the reference duration is 100 microseconds, the tolerance upper limit is 120 microseconds; when the elapsed time of multiple consecutive iterations exceeds 120 microseconds, the system is considered to be in a continuous high-load state; if it exceeds occasionally but quickly recovers, no adjustment will be triggered. The load tolerance factor can also be adjusted according to the system's sensitivity to latency. For scenarios with higher real-time requirements, the tolerance factor can be set smaller to make the system more sensitive to load changes.

[0094] The preset condition is used to determine whether the current iteration is within the normal load range. In this embodiment, the preset condition is specifically defined as: whether the elapsed time T_actual of the current iteration is less than the product of the preset reference duration and the load tolerance factor. That is, the comparison condition is T_actual < T_base × load tolerance factor. When this condition is met, it indicates that the iteration time of this iteration is within the acceptable range and the system load is normal; when this condition is not met, that is, T_actual ≥ T_base × tolerance factor, it indicates that the iteration time of this iteration is on the high side and the system may have an instantaneous or continuous high load.

[0095] To avoid frequent threshold adjustments due to occasional single load spikes, the management core will count the number of iterations that continuously do not meet the preset condition. When the iterations of a continuous preset number (such as 5 consecutive times) do not meet the condition, the management core determines that the system is in a continuous high-load state. At this time, the first preset value and the second preset value need to be adjusted to reduce the impact of the log system on real-time services. The adjustment strategy is as follows: The process of adjusting the first preset value can be as follows: By default, the first preset value is usually set to three-quarters of the capacity of the first sub-area. When a sustained high load is detected, the management core reduces the first preset value to half the capacity of the first sub-area. Reducing the first preset value allows the task core to trigger data transfer earlier, before the first sub-area is full, thereby reducing the amount of data transferred in a single DMA transfer and reducing the instantaneous load on the management core when processing messages. For example, previously, transferring 1755 records at a time took a long time; after adjustment, transferring only 1170 records at a time allows the management core to complete a DMA transfer faster, avoiding prolonged occupation of the internal bus or impacting other real-time tasks.

[0096] The process of adjusting the second preset value can be as follows: By default, under normal load, the second preset value is set to half the capacity of the second sub-area. Under high load, the management core increases the second preset value to three-quarters of the sub-area capacity. Simultaneously, the management core can enable log level filtering, reporting only high-level logs. The purpose of this is to reduce the number of core interrupts and the amount of reported data with the ARM core. Increasing the second preset value means that more logs need to be accumulated before triggering a report, thus reducing the ARM's wake-up frequency. Combined with log level filtering, this further reduces the transmission of invalid logs, allowing the ARM to focus on processing critical logs under high load.

[0097] As an example, under sustained high load, the management core adjusts the first preset value from 1755 to 1170 and the second preset value from 18724 to 28087. This allows the producer core to move data more frequently in small batches, reducing the burden on the management core's single processing; while the management core reports large batches of data to the ARM at a lower frequency, reducing inter-core interrupt overhead. Once the system load returns to normal, the management core can gradually restore the thresholds to their default values.

[0098] In some implementations, using the ARM module 200 and based on the reported messages to parse and store the log records of each target's second buffer into strings may include: The ARM module 200 is used to traverse the reporting flags of each second buffer based on the reporting messages, and the target second buffer is determined based on the reporting flags. For any log record in the target second buffer, the preset mapping table is looked up based on the core ID corresponding to the log record to obtain the base address of the read-only data segment of the task core corresponding to the core ID. The log record is then parsed based on the base address and offset of the task core, and the parsed log record is stored in the corresponding log file based on the core ID.

[0099] In this embodiment, the ARM module 200 has registered an inter-core interrupt handling function during the system startup phase. When the management core sends a reporting message through the inter-core interrupt, the interrupt handling function of the ARM module 200 only sets an event flag and wakes up the log writing master task. After the master task is woken up, it begins to traverse all cells and checks the second buffer of each cell. Specifically, it can read the pending reporting flag of each second buffer. If the flag is 1, it indicates that there is data waiting to be processed in the buffer. If the pending reporting flag is not set due to an abnormal reason, it can also be determined whether there is data by reading whether the current write index (i.e., the second index value) of the buffer is non-zero. For each cell, the master task will check its two second sub-areas in turn. When the pending reporting flag of a certain second sub-area is 1 or the write index is greater than 0, the second sub-area is determined as the target second buffer. For example, when the ARM module 200 traverses cell 0, it finds that the pending reporting flag of second sub-area A is 1, while the write index of sub-area B is 0 and the flag is 0. Therefore, it only takes sub-area A as the target.

[0100] After determining the target second buffer, the ARM module 200 obtains the starting address and the number of valid records (i.e., the second index value) of the target second buffer. Since each second sub-region contains log records from different task cores, each record already includes the source core ID field. Starting from the buffer's starting address, the ARM module 200 traverses each binary log record sequentially at a fixed length (e.g., 28 bytes). For each record, the ARM module 200 extracts the source core ID, format string offset, log level, number of parameters, and parameter value array.

[0101] Furthermore, during the startup phase, the ARM module 200 has already received the base address mapping table of read-only data segments for all task cores from the management core. Based on this, the ARM module 200 queries the mapping table using the core ID extracted from the log records, indexed by that ID, to obtain the base address of the read-only data segment for each task core. For example, the read-only data segment of task core 2 is mapped to address 0x80020000 in the ARM virtual address space. This base address remains unchanged during system operation.

[0102] After obtaining the base address of the read-only data segment, the ARM module 200 adds it to the offset of the format string in the log record to obtain the absolute memory address of the format string in the ARM address space. For example, if the base address of the read-only data segment of task core 2 is 0x80020000, and the offset of a certain log record is 0x100, then the absolute address of the format string is 0x80020100. Since the ARM module 200 has already mapped the shared memory and the read-only data segment contents of each DSP core to its own address space through memory mapping, the ARM module 200 can directly read the null-terminated format string text from this address, such as reading "Received data packet length=%d, port=%u". The entire process does not require additional data copying or cross-core communication.

[0103] After obtaining the format string text and parameter value array, the ARM module 200 calls the standard string formatting function to convert them into a readable plaintext log string. Each element in the parameter value array is a 32-bit integer value, and the formatting function interprets these integers correctly according to the format specifiers (such as %d, %u, %x, etc.) in the format string. For example, if the format string is "received data packet length=%d, port=%u", and the first two elements of the parameter value array are 1024 and 8080 respectively, then the formatted string will be "received data packet length=1024, port=8080".

[0104] It should be noted that if the format string contains %s (string pointer), since the ARM module 200 cannot directly reference pointers in the DSP address space, this system stipulates that all parameters are integers or values ​​that can be converted to integers, and the pointer address is recorded in numerical form. Only the address value is printed during parsing.

[0105] The ARM module 200 selects the corresponding log file based on the core ID extracted from the log records. At system startup, an independent log file is created for each core (0 to 7), named / var / log / dspX.log, where X is the core number. After generating the plaintext log string, the ARM module 200 writes the string to the corresponding file in append mode. To reduce disk I / O operations, this embodiment calls the file write interface after processing each record, or writes all records at once after accumulating a certain batch. Simultaneously, the file buffer is periodically flushed to ensure that log data is truly written to disk, preventing the loss of the last batch of logs in the event of a system crash.

[0106] In practical implementation, to prevent individual log files from becoming too large, the system supports a log rotation mechanism. Specifically, the ARM module 200 monitors the current size of each log file. When a log file exceeds a preset threshold (e.g., 100MB), it automatically renames the current log file to a timestamped backup file and creates a new blank log file to continue writing. At the same time, it can choose to compress or delete the oldest backup file to control disk usage.

[0107] Furthermore, if the ARM module 200's parsing and writing speed cannot keep up with the management core's reporting speed, manifesting as multiple secondary caches in shared memory simultaneously being in a pending reporting state and an increasing backlog, the ARM module 200 can indirectly affect the management core's reporting frequency through an implicit backpressure mechanism. Specifically, when the ARM module 200 detects severe backlog during parsing, it can modify certain control variables in shared memory (e.g., increasing the management core's second preset value or enabling stricter log level filtering); the management core periodically reads these control variables in its main loop, thereby adaptively adjusting its behavior.

[0108] Finally, for pointer type parameters that may appear in the format string, the ARM module 200 cannot directly reference pointers in the DSP address space. In this embodiment, all log parameters are assumed to be integers or values ​​that can be converted to integers. Only the address value is printed during parsing, thereby ensuring the stability and security of log processing.

[0109] Through the above steps, the ARM module 200 completes the entire process from determining the target second buffer, traversing binary records, parsing format strings, generating plaintext logs, to file-based storage. The entire process is completely decoupled from the producer and consumer cores and requires no feedback confirmation.

[0110] Therefore, by constructing fixed-length binary log records in the DSP task core, storing only offsets and parameter values, the storage and processing of redundant format strings in traditional methods are avoided, significantly reducing shared memory overhead. Secondly, hardware queues combined with DMA are used for batch data transfer, and a ping-pong buffer mechanism is used to achieve non-blocking writing and efficient transmission of logs, reducing the intervention time of the DSP core and thus reducing resource contention for real-time physical layer services. At the same time, the management core can dynamically adjust the reporting threshold and log filtering strategy according to the system load, adaptively reducing the interaction frequency during peak service periods, enhancing the stability of the system under high load. Finally, the time-consuming string parsing and log writing tasks are handled asynchronously by the ARM module 200, allowing for rapid on-site parsing and problem localization without relying on external PC tools. Furthermore, the independent process design of the ARM module 200 reduces the coupling between the log module and the service module, facilitating subsequent independent upgrades and debugging. Thus, while ensuring the real-time performance of the base station physical layer, a low-overhead, high-efficiency, adaptive, and easy-to-maintain logging solution is achieved.

[0111] Based on the above embodiments, this application also provides a multi-core processing system, which includes a DSP module and an ARM module. The DSP module includes multiple task cores, a hardware queue, a management core, a DMA, multiple first caches, and multiple second caches, with each task core corresponding to one of the first caches.

[0112] The task core is used to obtain its core ID, construct a fixed-length binary log record based on the log to be recorded, cache the log record to the corresponding first buffer based on the core ID, and obtain the first index value of the corresponding first buffer. If the first index value is greater than or equal to a first preset value, the corresponding first buffer is used as the target first buffer, a hardware queue message is constructed and written to the hardware queue. The management core is used to poll the hardware queue. If a hardware queue message is read from the hardware queue, it calls DMA based on the hardware queue message to store all log records in the target first buffer to the corresponding second buffer, and obtains the second index value of the corresponding second buffer. If the second index value is greater than or equal to a second preset value, the corresponding second buffer is used as the target second buffer, a reporting message is constructed and sent to the ARM module. The ARM module is used to parse and store the log records of each target second buffer based on the reporting message.

[0113] In some implementations, each first cache area is a ping-pong cache area, and each first cache area includes two first sub-areas. Specifically, the task core is used to: determine the first cache area corresponding to the task core based on the core ID, determine the currently active first sub-area based on the active buffer indicator flag of the corresponding first cache area, and obtain the base address, write index, and current first preset value of the currently active first sub-area; cache log records to the currently active first sub-area using the write index, and obtain the first index value of the currently active first sub-area; if the first index value is greater than or equal to the current first preset value, use the currently active first sub-area as the target first cache area, invert the active buffer indicator flag of the corresponding first cache area, and clear the write index of the other first sub-area in the corresponding first cache area.

[0114] In some implementations, each second buffer is a ping-pong buffer, and each second buffer includes two second sub-areas. Specifically, the management core is used to: determine the core ID of the target first buffer based on hardware queue messages, and determine the corresponding second buffer based on the core ID; determine the currently active second sub-area based on the active buffer indicator flag of the corresponding second buffer; call DMA to store all log records in the target first buffer into the currently active second sub-area, and increment the second index value of the currently active second sub-area; if the second index value is greater than or equal to a second preset value, use the currently active second sub-area as the target second buffer, invert the active buffer indicator flag of the corresponding second buffer, clear the write index of the other second sub-area in the corresponding second buffer, and set the pending reporting flag of the corresponding second buffer.

[0115] In some implementations, the task core is also specifically used to: determine the base address of the read-only data segment of the task core based on the core ID of the task core, and determine the offset based on the base address of the task core; and construct a fixed-length binary log record based on the offset, the log level, the number of parameters, and the values ​​of each parameter of the log to be recorded.

[0116] In some implementations, the task core is also specifically used to discard logs to be logged if the log level of the log to be logged is lower than the dynamic global level of the multi-core processing system.

[0117] In some implementations, the task core is also specifically used to: determine the starting address to be moved and the valid length of the log record to be moved in the first buffer of the target; construct a hardware queue message based on the core ID, the starting address to be moved and the valid length of the log record to be moved; and call the sending interface of the hardware queue to write the hardware queue message into the hardware queue.

[0118] In some implementations, the management core is also specifically used to: determine the cell identifier of the target second buffer, the starting address to be reported, and the effective data length of the target second buffer; construct a reporting message based on the cell identifier of the target second buffer, the starting address to be reported, and the effective data length; and send the reporting message to the ARM module using an inter-core interrupt mechanism.

[0119] In some implementations, the management core is also specifically used to determine the time taken for the management core to complete the current iteration, and to determine whether the current iteration meets the preset conditions based on the time taken for the current iteration, the preset baseline time, and the load tolerance coefficient; and to adjust the first preset value and the second preset value if the preset conditions are not met for a preset number of consecutive iterations.

[0120] In some implementations, the ARM module is specifically used to: traverse the reporting flags of each second buffer based on the reporting message, and determine the target second buffer based on the reporting flags; for any log record in the target second buffer, look up a preset mapping table based on the core ID corresponding to the log record to obtain the base address of the read-only data segment of the task core corresponding to the core ID, and parse the log record as a string based on the base address and offset of the task core, and store the parsed log record in the corresponding log file based on the core ID.

[0121] It should be noted that for details not disclosed in the multi-core processing system of this embodiment, please refer to the details disclosed in the embodiment of the lightweight log processing method in this specification, which will not be repeated here.

[0122] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A lightweight log processing method, characterized in that, The method is applied to a multi-core processing system, which includes a DSP module and an ARM module. The DSP module includes multiple task cores, a hardware queue, a management core, a DMA, multiple first caches, and multiple second caches. Each task core corresponds one-to-one with each of the first caches. The task core is used to obtain its core ID, and a fixed-length binary log record is constructed based on the log to be recorded. The log record is cached in the corresponding first cache area based on the core ID. The first index value of the corresponding first cache area is obtained. If the first index value is greater than or equal to a first preset value, the corresponding first cache area is used as the target first cache area. A hardware queue message is constructed and written to the hardware queue. The management core polls the hardware queue. When a hardware queue message is read from the hardware queue, the DMA is called based on the hardware queue message to store all log records in the target first buffer to the corresponding second buffer. The second index value of the corresponding second buffer is obtained. If the second index value is greater than or equal to a second preset value, the corresponding second buffer is used as the target second buffer. A reporting message is constructed and sent to the ARM module. The ARM module is used to parse and store the log records of each target's second buffer based on the reported message.

2. The lightweight log processing method according to claim 1, characterized in that, Each of the first cache areas is a ping-pong cache area, and each first cache area includes two first sub-areas; The step of caching the log record to the corresponding first cache area based on the kernel ID, and obtaining the first index value of the corresponding first cache area, and using the corresponding first cache area as the target first cache area if the first index value is greater than or equal to a first preset value, includes: Based on the core ID, determine the first cache area corresponding to the task core, and based on the active buffer indicator flag of the corresponding first cache area, determine the currently active first sub-area, and obtain the base address, write index and current first preset value of the currently active first sub-area; The log records are cached in the currently active first sub-region using the write index, and the first index value of the currently active first sub-region is obtained; If the first index value is greater than or equal to the current first preset value, the currently active first sub-region is taken as the target first cache region, the active buffer indicator flag of the corresponding first cache region is inverted, and the write index of another first sub-region in the corresponding first cache region is cleared to zero.

3. The lightweight log processing method according to claim 2, characterized in that, Each of the second cache areas is a ping-pong cache area, and each second cache area includes two second sub-areas; The step of calling the DMA based on the hardware queue message to store all log records in the target first buffer to the corresponding second buffer, and obtaining the second index value of the corresponding second buffer, and using the corresponding second buffer as the target second buffer if the second index value is greater than or equal to a second preset value, includes: The core ID of the target first cache is determined based on the hardware queue message, and the corresponding second cache is determined based on the core ID; Based on the active buffer indicator flag of the corresponding second buffer, the currently active second sub-region is determined, and the DMA is invoked to store all log records in the target first buffer into the currently active second sub-region, and the second index value of the currently active second sub-region is incremented; If the second index value is greater than or equal to the second preset value, the currently active second sub-region is taken as the target second cache region, the active buffer indicator flag of the corresponding second cache region is inverted, the write index of another second sub-region in the corresponding second cache region is cleared, and the pending reporting flag of the corresponding second cache region is set.

4. The lightweight log processing method according to claim 3, characterized in that, The construction of fixed-length binary log records based on the log to be recorded includes: Based on the core ID of the task core, determine the base address of the read-only data segment of the task core, and determine the offset based on the base address of the task core; Based on the offset and the log level, number of parameters, and values ​​of each parameter of the log to be recorded, a fixed-length binary log record is constructed.

5. The lightweight log processing method according to claim 4, characterized in that, Before constructing a fixed-length binary log record based on the offset, the log level, the number of parameters, and the values ​​of each parameter of the log to be recorded, the method further includes: If the log level of the log to be logged is lower than the dynamic global level of the multi-core processing system, the log to be logged will be discarded.

6. The lightweight log processing method according to claim 5, characterized in that, The process of constructing a hardware queue message and writing it to the hardware queue includes: Determine the starting address to be moved and the valid length of the log record to be moved in the first buffer of the target; The hardware queue message is constructed based on the core ID, the starting address to be moved, and the effective length of the log record to be moved. Call the send interface of the hardware queue to write the hardware queue message into the hardware queue.

7. The lightweight log processing method according to claim 3, characterized in that, The construction and sending of a reporting message to the ARM module includes: Determine the cell identifier, the starting address to be reported, and the effective data length of the target second buffer; The reporting message is constructed based on the cell identifier of the target second buffer, the starting address to be reported, and the effective data length. The reporting message is sent to the ARM module using an inter-core interrupt mechanism.

8. The lightweight log processing method according to any one of claims 1 to 7, characterized in that, Before using the ARM module and performing string parsing and storage of the log records of each target second buffer based on the reported message, the method further includes: The time taken for the management core to complete the current iteration is determined using the management core, and whether the current iteration meets the preset conditions is determined based on the time taken for the current iteration, the preset baseline time, and the load tolerance coefficient. If the preset conditions are not met after a preset number of iterations, the first preset value and the second preset value are adjusted.

9. The lightweight log processing method according to claim 4, characterized in that, The step of using the ARM module and based on the reported message to parse and store the log records of each target second buffer includes: The ARM module is used to traverse the reporting flags of each second buffer based on the reporting message, and the target second buffer is determined based on the reporting flags. For any log record in the target second buffer, a preset mapping table is looked up based on the kernel ID corresponding to the log record to obtain the base address of the read-only data segment of the task kernel corresponding to the kernel ID. The log record is then parsed as a string based on the base address and offset of the task kernel, and the parsed log record is stored in the corresponding log file based on the kernel ID.

10. A multi-core processing system, characterized in that, The multi-core processing system includes a DSP module and an ARM module. The DSP module includes multiple task cores, a hardware queue, a management core, a DMA, multiple first caches, and multiple second caches. Each task core corresponds one-to-one with each of the first caches. The task core is used to: obtain its core ID, construct a fixed-length binary log record based on the log to be recorded, cache the log record to the corresponding first cache area based on the core ID, obtain the first index value of the corresponding first cache area, and, if the first index value is greater than or equal to a first preset value, use the corresponding first cache area as the target first cache area, construct a hardware queue message and write it to the hardware queue. The management core is used to poll the hardware queue, and when a hardware queue message is read from the hardware queue, call the DMA based on the hardware queue message to store all log records in the target first buffer to the corresponding second buffer, and obtain the second index value of the corresponding second buffer. If the second index value is greater than or equal to a second preset value, the corresponding second buffer is used as the target second buffer, and a reporting message is constructed and sent to the ARM module. The ARM module is used to parse and store the log records of each target's second buffer based on the reported message.

Images