Multi-core log management architecture and method based on power gap operating system and computer program product

Abstract

The invention provides a multi-core log management architecture and method based on a power gap operating system and a computer program product, which are suitable for the technical field of computers, and comprise a master core, a slave core and a shared memory area, the slave core further comprises a log generation module, a buffer module and a log uploading module; the main core is responsible for operating a power gap operating system; the slave core is responsible for running a naked running program or a real-time operating system; the log uploading module writes target log data in the buffer module into a shared memory area when the data cached in the buffer module reaches a preset condition; under the condition that the master core monitors that the slave core uploads the target log data to the shared memory area in the shared memory area, the target log data in the shared memory area is read, and integration, classification and storage operation is conducted on the target log data in sequence. Therefore, the efficiency problem of log collection, storage and management in the multi-core heterogeneous architecture can be solved, the characteristics of the master core and the slave core are fully utilized, and the log processing capacity of the system is improved.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and particularly relates to a multi-core log management architecture, method, and computer program product based on the Power Harmony operating system. Background Art

[0002] With the development of the intelligence of the power system, as a new generation of dedicated operating system for the power industry, the multi-core processing ability of the Power Harmony operating system provides the possibility for the efficient operation of complex applications. However, in a multi-core environment, log management faces problems of synchronization, consistency, and efficiency. Traditional log management methods are prone to cause log chaos or performance bottlenecks in multi-core systems. Therefore, a multi-core log management method specifically applicable to the Power Harmony operating system is needed to overcome the above defects. Summary of the Invention

[0003] To solve the technical problem of "how to achieve efficient synchronization and management of multi-core logs based on the Power Harmony operating system" mentioned in the above background art, the embodiments of this application provide a multi-core log management architecture, method, and computer program product based on the Power Harmony operating system.

[0004] In a first aspect, the embodiments of this application provide a multi-core log management architecture based on the Power Harmony operating system, including a master core, slave cores, and a shared memory area; the slave cores include a log generation module, a buffer module, and a log upload module;

[0005] The master core is configured to run the Power Harmony operating system;

[0006] The slave cores are configured to run bare-metal programs, access hardware resources through the bare-metal programs to enable the log generation module to generate original log data, and cache the original log data in the buffer module in real time;

[0007] The slave cores are further configured to run a real-time operating system to provide real-time task scheduling and resource management, and optimize the processing flow of the log data through the real-time task scheduling and the resource management;

[0008] The log upload module is configured to write target log data at the tail of the cache in the buffer module into the shared memory area when the data cached in the buffer module reaches a preset condition;

[0009] The main core is further configured to monitor the data in the shared memory area, and in the case of monitoring that the slave core uploads the target log data to the shared memory area, read the target log data in the shared memory area, and sequentially perform integration, classification, and storage operations on the target log data to establish a log index, where the log index is used to provide a function for users to query log data.

[0010] In one example, the Power Harmony operating system is further configured with a multi-protocol storage management module and an intelligent storage scheduler; wherein, the main core and multiple slave cores are each configured with multiple types of storage devices;

[0011] The multi-protocol storage management module is configured to determine the response speed, bandwidth information, and input / output performance information of each storage device; and select a target storage device from each storage device according to the response speed, bandwidth information, and input / output performance information of each storage device, and write the target log data into the target storage device;

[0012] The intelligent storage scheduler is configured to monitor the operating states of each storage device in the main core and multiple slave cores; and adjust the load information of each storage device according to the operating states to reallocate the storage strategy of the log data.

[0013] In one example, the main core is further configured with a log priority management module;

[0014] The log priority management module is configured to sort the log data according to priorities in advance, and write the log data corresponding to the priority levels into the storage device in the order of priorities;

[0015] The main core is further configured to reserve storage bandwidth for the log data of hot logs, where the storage bandwidth is used to prevent other tasks from interfering with the writing of the log data of hot logs into the storage device; wherein, the hot logs represent logs with a high priority level.

[0016] The slave core is configured to circularly store cache data in the buffer of the buffer module; wherein, when the cache data in the buffer reaches the cache tail, the buffer module writes new cache data into the cache head of the buffer.

[0017] In one example, the main core is assigned the read and write permissions for all logs; wherein, all logs include local logs generated by each slave core and other logs uploaded by external devices;

[0018] The slave core is assigned the access permission to the local logs generated by it.

[0019] In one example, the main core is further configured to handle the storage and management of thermal logs;

[0020] The slave core is further configured to handle the local caching and task distribution of cold logs; the types of the storage devices further include high-speed storage devices and local storage devices of the slave core; wherein, the thermal logs are stored in the high-speed storage devices controlled by the main core; the cold logs are cached in the local storage devices of the slave core, and the cold logs represent logs with a low priority level;

[0021] The main core is used to monitor the storage condition of the local storage device of the slave core, and when the local storage device of the slave core reaches the full-load condition, control the slave core to clean the cold logs, or transfer the cold logs to the high-speed storage device.

[0022] In a second aspect, the present application further provides a multi-core log management method based on the Power Harmony operating system. The management method is implemented based on the multi-core log management architecture based on the Power Harmony operating system as described in the first aspect. The method includes:

[0023] The main core runs the Power Harmony operating system;

[0024] The slave core runs a bare-metal program, and accesses hardware resources through the bare-metal program to enable the log generation module to generate original log data, and caches the original log data in the buffer module in real time;

[0025] The slave core runs a real-time operating system to provide real-time task scheduling and resource management, and optimizes the processing flow of the log data through the real-time task scheduling and the resource management;

[0026] When the data cached in the buffer module of the slave core reaches a preset condition, the slave core writes the target log data at the cache tail of the buffer module into the shared memory area;

[0027] The main core listens to the data in the shared memory area, and when it monitors that the slave core uploads the target log data to the shared memory area, reads the target log data in the shared memory area, and sequentially performs integration, classification, and storage operations on the target log data to establish a log index, and the log index is used to provide a function for users to query log data.

[0028] In one example, the method further includes:

[0029] The main core monitors the load status of the main core local and the slave core to obtain the current load condition;

[0030] The master core dynamically adjusts the allocation strategy of log collection and processing tasks according to the current load condition, including delegating the processing task of cold logs to the slave core when the master core reaches a high load operation condition, and the slave core processes the processing task of the cold logs;

[0031] When the slave core reaches a low-load operating condition, the cold log is uploaded to the master core for centralized management;

[0032] When determining that the load of the master core is reduced, the slave core migrates the processing task of the cold log back to the master core.

[0033] In one example, the master core is configured to collect, store and process tasks related to hot logs in priority to the slave core; the slave core is configured to perform auxiliary tasks, including caching of cold logs and processing of related tasks of the cold logs.

[0034] In a third aspect, the present application further proposes a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the steps of the method described in the first aspect are implemented.

[0035] In a fourth aspect, the present application further proposes a computer program product, wherein the computer program product stores a computer program, and when the computer program is executed by a processor, the steps of the method described in the second aspect are implemented.

[0036] The beneficial effects of the present application are as follows: the multi-core log management architecture of the present application embodiment includes a main core, a slave core and a shared memory area; the slave core further includes a log generation module, a buffer module and a log upload module; the main core runs the power Hongmeng operating system; the slave core runs a naked running program, accesses hardware resources through the naked running program so that the log generation module generates original log data, and caches the original log data in real time in the buffer module; the slave core runs a real-time operating system to provide real-time task scheduling and resource management, and optimizes the processing flow of log data through real-time task scheduling and resource management; the log upload module writes the target log data at the cache tail of the buffer module to the shared memory area when the data cached in the buffer module reaches the preset conditions; the main core monitors the data in the shared memory area, and when the slave core is monitored to upload the target log data to the shared memory area, the target log data in the shared memory area is read, and the target log data is sequentially integrated, classified and stored to establish a log index, which is used to provide users with the function of querying log data. And then it can solve the efficiency problem of log collection, storage and management in the multi-core heterogeneous architecture, and make full use of the characteristics of the main core and the slave core to improve the log processing capability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] To more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the accompanying drawings required for the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can also be obtained based on these drawings.

[0038] Figure 1 Schematic diagram of the first embodiment of a multi-core log management architecture based on the Power Harmony operating system provided by the present application;

[0039] Figure 2 Schematic diagram of the third embodiment of a multi-core log management architecture based on the Power Harmony operating system provided by the present application;

[0040] Figure 3 Schematic diagram of the fifth embodiment of a multi-core log management architecture based on the Power Harmony operating system provided by the present application;

[0041] Figure 4 Schematic diagram of the embodiment process of a multi-core log management method based on the Power Harmony operating system provided by the present application;

[0042] Figure 5 Schematic diagram of the process of another embodiment of a multi-core log management method based on the Power Harmony operating system provided by the present application;

[0043] Figure 6 Schematic diagram of the embodiment structure of a computer device for executing a multi-core log management method provided by the present application. Detailed implementation manners

[0044] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field to which this application belongs; the terms used herein are only for the purpose of describing specific embodiments and are not intended to limit this application; the terms "including" and "having" and any variations thereof in the specification and claims of this application and the above accompanying drawing descriptions are intended to cover non-exclusive inclusion.

[0045] It should be understood that when used in the specification and claims of this application, the term "including" indicates the presence of the described features, wholes, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or their combinations.

[0046] It should also be understood that the term "and / or" as used in the specification of this application and the appended claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes such combinations.

[0047] As used in the specification of this application and the appended claims, the term "if" can be interpreted as "when", "once", "in response to determining", or "in response to detecting" depending on the context. Similarly, the phrase "if determined" or "if [the described condition or event] is detected" can be interpreted as meaning "once determined", "in response to determining", "once [the described condition or event] is detected", or "in response to detecting [the described condition or event]" depending on the context.

[0048] In the description of the embodiments of this application, the term "plurality" means two or more (including two), unless otherwise specifically defined.

[0049] In addition, in the description of the specification of this application and the appended claims, the terms "first", "second", "third", etc. are only used for distinguishing descriptions and cannot be understood as indicating or implying relative importance.

[0050] The reference to "one embodiment" or "some embodiments" etc. described in the specification of this application means that a specific feature, structure, or characteristic described in connection with that embodiment is included in one or more embodiments of this application. Thus, statements such as "in one embodiment", "in some embodiments", "in other some embodiments", "in still other embodiments", etc. that appear in different places in this specification do not necessarily all refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in another way. The terms "comprising", "including", "having", and their variants all mean "including but not limited to", unless otherwise specifically emphasized in another way.

[0051] The applicant of the present invention notes that traditional log management methods are prone to log chaos, data loss, or performance bottlenecks in multi-core systems, especially in terms of real-time performance, dynamic task allocation, and security efficiency, etc., and still have obvious deficiencies, showing many limitations in complex scenarios with high reliability and high real-time requirements in the power industry. Based on the prior art, this application proposes a multi-core log management architecture based on the Power Harmony operating system to meet the higher requirements for log management. The specific technical solutions of this application will be elaborated below through specific embodiments.

[0052] Embodiment 1

[0053] To solve the technical problem of "how to achieve efficient synchronization and management of multi-core logs based on the Power Harmony operating system" mentioned in the above background art, this application provides a multi-core log management architecture based on the Power Harmony operating system, as Figure 1 shown, which includes a main core 10, slave cores 20, and a shared memory area 30; the slave cores 20 include a log generation module 21, a buffer module 22, and a log upload module 23; the main core 10 mainly interacts with the slave cores 20 through a global log management center.

[0054] The main core 10 is configured to run the Power Harmony operating system;

[0055] The slave cores 20 are configured to run a bare-metal program, access hardware resources through the bare-metal program to enable the log generation module 21 to generate original log data, and cache the original log data in the buffer module 22 in real time;

[0056] The slave cores 20 are also configured to run a Real-Time Operating System (RTOS) to provide real-time task scheduling and resource management, and optimize the processing flow of the log data through the real-time task scheduling and the resource management;

[0057] The log upload module 23 is configured to write the target log data at the cache tail of the buffer module 22 into the shared memory area 30 when the data cached in the buffer module 22 reaches a preset condition;

[0058] The main core 10 is further configured to monitor the data in the shared memory area 30, and when it monitors that the slave cores 20 upload the target log data to the shared memory area 30, read the target log data in the shared memory area 30, and perform integration, classification, and storage operations on the target log data in sequence to establish a log index, and the log index is used to provide a function for users to query log data.

[0059] It can be understood that the cooperation of the log management functions of the main core 10 and the slave cores 20 in the embodiments of this application is mainly divided into:

[0060] The main core runs the Power Harmony operating system and serves as a global log management center, responsible for receiving the log data uploaded by the slave cores, and integrating, classifying, and storing the logs. Provide a unified log index function, organize and sort the logs through keyword fields such as timestamps and source cores, so that subsequent users can quickly query the log data based on the log index function. In addition, the main core 10 in this embodiment may further include a log analysis module, and the log analysis module is used to perform preliminary analysis on the log data and extract key information for upper-layer applications to use.

[0061] Run a bare-metal program or a Real-Time Operating System (RTOS) from core 10, focusing on the generation and preliminary processing of local logs.

[0062] It can be understood that the bare-metal program in the embodiments of the present application is a program that runs directly on hardware without the support of the HarmonyOS. It is usually used in application scenarios that require high efficiency and low latency because it avoids the overhead of the operating system. In the multi-core heterogeneous environment of the embodiments of the present application, running the bare-metal program from the core can focus on specific tasks, such as the preliminary generation and processing of log data. Due to the reduction of the intermediate layer of the operating system, the bare-metal program in the embodiments of the present application can respond more quickly to the log generation requirements and improve the real-time performance of log data. The bare-metal program in the embodiments of the present application is closely related to the generation of log data because it can directly access hardware resources, quickly capture and record system events, and generate raw log data.

[0063] The Real-Time Operating System (RTOS) in the embodiments of the present application is an operating system specifically designed for real-time applications. It provides functions such as task scheduling, time management, and interrupt handling, while maintaining a low system overhead to meet real-time requirements. In the multi-core architecture of the embodiments of the present application, running the RTOS from the core can more effectively manage the generation, caching, and transmission of log data. The RTOS in the embodiments of the present application ensures that log data can be processed and stored according to the predetermined time requirements by providing real-time task scheduling and resource management. The RTOS in the embodiments of the present application also supports concurrent execution of multiple tasks, enabling the core to process multiple log generation tasks simultaneously, improving the overall efficiency and reliability of the log system. The relationship between the RTOS in the embodiments of the present application and the generation of log data lies in that the RTOS can optimize the processing flow of log data and ensure the timeliness and accuracy of log data.

[0064] In addition, it should be noted that the log management module of core 20 in the embodiments of the present application is mainly designed in a lightweight manner, with the ability of low-overhead log generation, caching, and transmission. It supports the rapid generation of high-frequency logs, realizes real-time caching through a circular buffer, and ensures the integrity of log data. Core 20 uploads the locally cached logs to the main core at an appropriate time, reducing the cross-core communication overhead.

[0065] In some embodiments, for the main core 10, the multi-core optimization strategy for log collection and storage is as follows: The main core adopts a centralized storage mechanism: responsible for the storage management of global log data, classifying and storing logs according to the importance and time sequence of the logs. The concept of log priority is introduced to ensure that critical task logs can be stored and processed preferentially. For the slave core 20, the buffer module adopted by the slave core 20 in this embodiment can circularly store data in the buffer. When the buffer of the buffer module reaches the end, it will continue to write from the beginning of the buffer, forming a circular structure. This can ensure the integrity of log data and avoid interference with task execution during the log writing process. The log is segmented and stored using statically allocated cache space, and the circular overwrite method is adopted to avoid buffer overflow, reduce the interference of log generation on real-time tasks, and ensure the stable performance of the system.

[0066] In addition, in this embodiment, the log transmission mechanism between the main core 10 and the slave core 20 is as follows:

[0067] Efficient transmission based on shared memory: Allocate a shared memory area 30, and the slave core 20 directly writes the generated logs into the shared memory area 30, and the main core 10 reads the logs from it for processing. This embodiment preferably uses a flag bit mechanism to avoid read-write conflicts of multiple cores on the shared memory and improve the data transmission efficiency at the same time. Adopt event-triggered data transmission: The slave core triggers log transmission when the local cache reaches a certain threshold or the task is completed. The main core listens to the transmission events of the slave core and pulls or waits for log data as needed.

[0068] It can be understood that in the multi-core log management framework, both the shared memory and the buffer module are key components for log data transmission and processing. The shared memory in this embodiment represents a mechanism for efficiently transmitting log data between the main core and the slave core. It allows the slave core to directly write the generated logs into the shared memory area, and the main core can read the logs from the shared memory area for processing.

[0069] The buffer area of the buffer module 22 used by the slave core 20 is the space for the slave core 20 to temporarily store log data. After the slave core 20 generates logs, the log data will be cached in the buffer module 22 first, and then the log data will be transmitted to the shared memory area 30 when the data cached in the buffer module 22 meets the preset conditions (such as when the cache reaches a certain threshold or the task is completed).

[0070] In some embodiments, in a specific implementation, this embodiment can optimize the task division and load of multi-core log processing: Main core tasks: Integrate and classify the logs uploaded by multiple cores to ensure the orderliness of global logs. Responsible for the log analysis and storage of low-real-time tasks, such as the historical records of system operation. Slave core tasks: Mainly responsible for the generation and preliminary processing of high-real-time logs, such as the acquisition logs of sensor data. When the load of the slave core is low, it undertakes part of the local storage task of logs to further relieve the pressure on the main core.

[0071] In some embodiments, in a specific implementation, log format adaptation and conversion under the heterogeneous architecture of this embodiment: On the slave core side, a unified log generation format is adopted: Use a standardized structured format, such as metadata like fixed timestamp, source core identifier, task ID, etc., to facilitate the quick parsing by the main core. On the main core side, a log format conversion module is designed: According to actual needs, convert the slave core logs into a more advanced format (such as JSON or binary format) to adapt to different upper-layer application requirements.

[0072] The beneficial effects of this embodiment are as follows. In the prior art, since the main core often undertakes most of the log collection, storage, and processing tasks, it is easy to cause performance bottlenecks, while the hardware resources of the slave core are not fully utilized. The multi-core log management architecture of this application embodiment includes a main core, a slave core, and a shared memory area; the slave core further includes a log generation module, a buffer module, and a log upload module; the main core is responsible for running the Power Harmony operating system; the slave core is responsible for running a bare-metal program, accessing hardware resources through the bare-metal program to enable the log generation module to generate raw log data, and caching the raw log data in the buffer module in real time; the slave core runs a real-time operating system to provide real-time task scheduling and resource management, and optimizes the processing flow of log data through real-time task scheduling and resource management; the log upload module writes the target log data at the tail of the cache in the buffer module into the shared memory area when the data cached in the buffer module reaches a preset condition; the main core monitors the data in the shared memory area, and when it monitors that the slave core uploads the target log data to the shared memory area, reads the target log data in the shared memory area, and sequentially performs integration, classification, and storage operations on the target log data to establish a log index for providing the function of querying log data for users. Furthermore, it can solve the efficiency problem of log collection, storage, and management in a multi-core heterogeneous architecture, and make full use of the characteristics of the main core and the slave core to improve the log processing ability of the system.

[0073] Embodiment 2

[0074] Furthermore, the allocation of log processing tasks in the prior art lacks real-time monitoring and dynamic adjustment of multi-core loads, cannot adapt to task load changes, and affects system performance. Based on the content of the first embodiment above, the second embodiment further optimizes the solution of the first embodiment, can monitor the load status of multiple slave cores in real time through the master core, dynamically allocate log processing tasks, and the slave cores assist in executing low-priority log tasks when the load is low to achieve load balancing and avoid performance bottlenecks.

[0075] Among them, the Power Harmony operating system of this embodiment further includes a multi-protocol storage management module and an intelligent storage scheduler; among them, the master core and multiple slave cores are all configured with various types of storage devices;

[0076] The multi-protocol storage management module is used to determine the response speed, bandwidth information, and input / output performance information of each storage device; and select a target storage device from each storage device according to the response speed, bandwidth information, and input / output performance information of each storage device, and write the target log data into the target storage device;

[0077] The intelligent storage scheduler is configured to monitor the operating status of each storage device in the master core and multiple slave cores; and adjust the load information of each storage device according to the operating status to reallocate the storage strategy of the log data.

[0078] It can be understood that, on the one hand, this solution introduces a multi-protocol storage management module at the operating system kernel layer. This module can automatically select the most suitable interface for data access according to the hardware characteristics and communication protocols of different storage devices. Through transparent support for protocols such as SATA protocol, PCIe protocol, NVMe protocol, iSCSI protocol, and NFS protocol, the system can simplify the access process of multi-type storage devices and eliminate compatibility problems between different storage devices. At the same time, the multi-protocol storage management module of this embodiment can dynamically select the most suitable target storage device for log writing according to the response speed, bandwidth information, and input / output I / O performance information of the storage media of each storage device by automatically detecting and optimizing device performance, ensuring the real-time storage of high-priority logs.

[0079] Cross-device Collaboration and Efficient Data Scheduling: To address the problem of low collaboration efficiency among storage devices, this solution introduces an intelligent data scheduling algorithm. By intelligently analyzing the real-time load, performance status, and data access patterns of each storage device, it dynamically adjusts the storage strategy for log data. Specifically, the system distributes log data to different types of storage devices according to the different performance characteristics of the storage devices (such as the fast response of SSDs), and automatically adjusts the data flow based on the actual load situation to ensure the timely writing of high-frequency logs and avoid the occurrence of storage device overload or bottleneck problems. The system also optimizes the writing and reading paths of log data through a distributed storage strategy, improving the efficiency of cross-device data transmission and reducing storage latency.

[0080] Data Consistency and Redundancy Management Mechanism: This embodiment adopts a distributed consistency protocol to ensure that data inconsistency does not occur when data redundancy and synchronization are carried out among multiple storage devices. Especially during the cross-device storage process, the system can guarantee the consistency and reliability of data, avoiding the loss of log data caused by network latency or device failures. In addition, the system optimizes the redundancy management of storage devices, intelligently determines which log data needs to be redundantly stored and which data can be safely stored on a single device, avoiding the waste of space caused by redundant storage while enhancing the data recovery ability.

[0081] On the other hand, this embodiment realizes the intelligent scheduling and load balancing of storage resources: This embodiment introduces an intelligent storage scheduler that can real-time monitor the operating status of each storage device in a multi-core system (main core and multiple slave cores), including storage space, I / O load, bandwidth utilization, etc., and dynamically adjusts the allocation of storage resources according to the system load and performance requirements. In this way, the system can achieve load balancing among multiple storage devices, avoid the generation of storage bottlenecks, and improve the overall storage efficiency of the system. In addition, when a device fails or the load is too high, the scheduler can quickly migrate log data to other healthy devices to ensure the continuity of log writing and the high availability of the system.

[0082] In addition, this embodiment also considers the future expansion requirements of storage devices and can support the flexible access of storage devices with different models and different interface protocols. When facing large-scale storage requirements, the system can smoothly expand the storage capacity by adding new devices and maintain the efficiency and real-time nature of log management. When a storage device fails, the system can quickly adjust the data storage path to ensure data security and avoid system interruption or data loss.

[0083] The beneficial effects of the second embodiment are as follows: By means of multi - protocol compatibility, intelligent data scheduling, cross - device collaboration, storage redundancy management, and resource load balancing, etc., the log management efficiency and storage performance of the Power Harmony operating system under the multi - core architecture are comprehensively improved, providing an efficient, stable, and highly scalable log management solution for the power industry.

[0084] Embodiment Three

[0085] Furthermore, aiming at the latency and efficiency problems of log writing in the multi - core heterogeneous architecture, the third embodiment further optimizes the solution of the second embodiment based on the content of the second embodiment.

[0086] Reference Figure 2 In this embodiment, on the one hand, for the main core 10, it is also configured with a log priority management module 11: which is used to sort the log data in advance according to the priority, and write the log data corresponding to the priority level into the storage device in the order of priority.

[0087] Specifically, the log priority management module 11 is configured with a priority - based log writing mechanism: Utilizing the scheduling ability of the Power Harmony operating system (real - time patches are applied to the Power Harmony), a priority - based log writing mechanism is designed in the main core: priorities (such as high, medium, and low) are assigned to the logs, and critical logs (such as fault records and real - time monitoring data) are set as high - priority to ensure that they can be written into the storage device preferentially.

[0088] In addition, the main core also reserves storage bandwidth for the log data of the hot logs, and the storage bandwidth is used to prevent other tasks from interfering with the writing of high - level log data into the storage device, where the hot logs are high - priority logs. In specific implementation, the main core classifies the received log data, and reserves storage bandwidth for high - priority logs through the scheduling module to avoid write latency caused by interference from other tasks. When the storage device is close to full load, the main core can also dynamically adjust the storage strategy of low - priority logs (such as temporary caching or delayed writing) through a timely monitoring mechanism to ensure the writing speed of high - priority logs.

[0089] In this embodiment, on the one hand, for the slave core 20, it is configured to circularly store cache data in the buffer of the buffer module; among them, when the cache data in the buffer reaches the cache tail, the buffer module writes the new cache data into the cache head of the buffer, forming a circular structure. This can ensure the integrity of the log data and avoid interference with task execution during the log writing process.

[0090] In specific implementation, a lightweight log cache module is designed in the slave core (running a bare-metal program or RTOS) to meet the requirements of high-frequency log generation and fast transmission: the slave core caches the generated logs in real time through the buffer of the buffer module, avoiding the interference of the log writing process on task execution. This embodiment can use a non-blocking log writing mechanism to ensure the generation and caching efficiency of high-frequency task logs and reduce the risk of data loss caused by resource contention. In coordination with the timeliness feature of the Power Harmony operating system, the slave core can dynamically adjust the log upload rhythm according to the status of the master core, further optimizing the storage efficiency of the master core.

[0091] Finally, this embodiment designs an efficient log transmission mechanism between the master core and the slave core: the master core listens to the log upload requests of the slave core through the scheduling ability of the Power Harmony operating system and preferentially processes high-frequency logs when necessary. The slave core dynamically adjusts the cache release and transmission frequencies according to the feedback from the master core, avoiding performance degradation of the master core caused by data transmission overload. This embodiment specifically uses shared memory or direct memory access (DMA) technology during the log transmission process to reduce the number of data copies and improve the transmission efficiency.

[0092] Through the above technical solutions, this third embodiment realizes the efficient cooperation between the master core and the slave core under the Power Harmony operating system, and solves the problems of log writing delay and low efficiency in the existing multi-core architecture. The new mechanism provided by this third embodiment not only ensures the fast writing of high-priority logs, but also improves the processing ability of the slave core in high-frequency log generation scenarios, significantly enhancing the timeliness and reliability of the system.

[0093] Embodiment Four

[0094] Furthermore, this fourth embodiment further optimizes the solution of the first embodiment. Regarding the permission management problem in the multi-core heterogeneous environment, this fourth embodiment proposes a hierarchical log access mechanism based on the permission control of the Power Harmony operating system. Through a flexible permission allocation strategy and an efficient permission synchronization mechanism, it realizes the log access control of the master core, the slave core, and external devices. The specific contents are as follows:

[0095] This fourth embodiment proposes a hierarchical log access mechanism based on the permission control of the Power Harmony operating system. Regarding the permission management problem in the multi-core heterogeneous environment, through a flexible permission allocation strategy and an efficient permission synchronization mechanism, it realizes the log access control of the master core, the slave core, and external devices. The specific contents are as follows:

[0096] Log grading permission model: Introduce a grading permission control mechanism in the log management framework, and allocate different log access permissions according to task roles and device properties: Master core permission: As the global log management center, the master core has the read and write permissions for all logs, including the local logs generated by slave cores and the logs uploaded by external devices. Slave core permission: The slave core can only access the local logs it generates and cannot modify the log data of other cores, ensuring a clear log access scope. External device permission: External devices can only access some key logs after authorization, and the authorization scope can be dynamically adjusted according to specific application requirements.

[0097] Inter-core permission synchronization mechanism: To ensure permission consistency in a multi-core environment, this implementation designes an inter-core permission synchronization mechanism: Master core permission distribution: As the center of permission control, the master core is responsible for uniformly allocating and maintaining the log access permissions of each core, and sending the permission information to the slave cores through a specific synchronization protocol. Permission dynamic adjustment: When the log permission configuration changes, the master core immediately notifies the slave cores to update the permission configuration to ensure that all cores always maintain a consistent permission state.

[0098] External device access control: This implementation designes a log authorization mechanism for external devices: When an external device accesses the log, it needs to send an authorization request to the master core, and the master core determines whether to allow access according to the permission rules. Authorized access uses time or task scope restrictions. For example, an external device can only access specified types of logs within a specific time period, improving security.

[0099] Through the above technical solutions, this application realizes graded log access control and efficient permission synchronization in a multi-core heterogeneous environment, effectively avoiding problems such as permission loss of control and data leakage, and meeting the high security requirements of the power system for log management.

[0100] Embodiment Five

[0101] Furthermore, this Embodiment Five further optimizes the solution of the above Embodiment Three, and proposes a log storage optimization mechanism in a multi-core environment. Through the collaborative work of the master core and the slave cores, combined with the hot and cold hierarchical storage strategy, efficient management of log storage is realized. Refer to Figure 3 , specifically including the following content:

[0102] The master core 10 is further configured to handle the storage and management of hot logs; the slave core 20 is further configured to handle the local cache and task distribution of cold logs; the types of the storage devices further include high-speed storage devices and local storage devices of the slave cores; wherein, the hot logs are stored in the high-speed storage devices controlled by the master core; the cold logs are cached in the local storage devices of the slave cores;

[0103] The main core 10 is used to monitor the storage status of the local storage device of the slave core. When the local storage device of the slave core reaches the full-load condition, it controls the slave core to clean the cold log or transfer the cold log to the high-speed storage device.

[0104] It can be understood that the division of labor for the storage tasks of the main core and the slave core in this embodiment mainly includes: the main core serves as the global log management center, focusing on the storage and management of high-priority logs (hot logs): hot logs include system key event logs, real-time monitoring data, etc., which need to be preferentially stored on high-performance storage devices to ensure real-time performance and reliability. In addition, the main core in this embodiment can perform a global index on the log storage location, facilitating users to quickly locate and access.

[0105] The slave core is responsible for the local caching and distribution of low-priority logs (cold logs): the cold logs in this embodiment can include historical records or low-real-time task logs, which are temporarily cached by the slave core and regularly uploaded to the main core. Under the instruction of the main core, the slave core can also undertake part of the cold log distribution task to relieve the storage pressure of the main core.

[0106] In addition, this embodiment can also adopt a hot and cold hierarchical storage mechanism: specifically introduce a hot and cold hierarchical storage strategy, and perform hierarchical management according to the timeliness and importance of the logs. Among them, the hot logs are stored in the high-speed storage device controlled by the main core, such as SSD or memory, to ensure fast writing and access. The cold logs are preferentially cached in the local storage of the slave core, and a segmented storage and rotation strategy is adopted to save storage resources. When necessary, the cold logs can be transferred to the secondary storage device to further reduce the storage cost. Among them, the determination basis for the log hierarchy in this embodiment can include: the task priority of log generation, the importance label of the log (such as system failure logs), and the generation time of the log (recent logs are used as hot logs, and older logs are classified as cold logs), etc.

[0107] Storage efficiency optimization strategy: The main core monitors the storage load of the slave core. When the storage of the slave core is close to full load, it actively instructs the slave core to clean the low-priority logs or transfer the logs to the main core for storage. The slave core uploads the cold logs in batches during idle periods to avoid affecting the timely tasks of the system. The main core maintains the storage location and status of all logs through a global index, reducing the cross-core retrieval overhead.

[0108] The beneficial effect of this fifth embodiment is that it realizes a reasonable division of labor between the main core and the slave core in the log storage task, and combines the hot and cold hierarchical storage mechanism, improving the timeliness, efficiency and resource utilization rate of log storage, and meeting the requirements for efficient log management in a multi-core environment.

[0109] Embodiment Six

[0110] Further, corresponding to the multi-core log management architecture based on the power Hongmeng operating system in the above-mentioned embodiment 1, this embodiment proposes a multi-core log management method based on the power Hongmeng operating system, referring to Figure 4 The management method is implemented based on the multi-core log management architecture based on the power Hongmeng operating system as described in any one of the above embodiments 1 to 5. The method is executed by a computer device carrying the management architecture, and mainly includes the following steps S10 to S30:

[0111] Step S10, the master core runs the power Hongmeng operating system; the slave core runs a naked running program, accesses hardware resources through the naked running program so that the log generation module generates original log data, and caches the original log data in real time in the buffer module; the slave core runs a real-time operating system RTOS to provide real-time task scheduling and resource management, and optimizes the processing flow of the log data through the real-time task scheduling and the resource management;

[0112] Step S20, when the data cached in the buffer module reaches a preset condition, the slave core writes the target log data located at the tail of the cache of the buffer module into the shared memory area;

[0113] Step S30, the master core monitors the data in the shared memory area, and when it monitors that the slave core uploads the target log data to the shared memory area, reads the target log data in the shared memory area, and integrates, classifies and stores the target log data in sequence to establish a log index, and the log index is used to provide users with the function of querying log data.

[0114] The implementation scheme and technical effects of the above steps S10 to S30 are basically consistent with the technical scheme and technical effects of the first embodiment, and will not be described in detail in this sixth embodiment.

[0115] Further, in this embodiment, reference Figure 5 , and proposed a log scheduling and load balancing mechanism based on the multi-core heterogeneous collaboration of the Hongmeng operating system. It uses the task scheduling capabilities of the master core and the slave core to dynamically adjust the allocation of log processing tasks to optimize the log processing efficiency in a multi-core environment. The specific steps include:

[0116] Step A1, the master core monitors the load status of the master core and the slave core to obtain the current load status;

[0117] Step A2, the master core dynamically adjusts the allocation strategy of log collection and processing tasks according to the current load condition: when the master core reaches a high load operation condition, the processing task of the cold log is delegated to the slave core, and the slave core processes the processing task of the cold log;

[0118] Step A3, when the slave core reaches the low-load operation condition, the slave core uploads the cold log to the master core for centralized management;

[0119] Step A4: When determining that the load of the master core is reduced, the slave core dynamically migrates the processing task of the cold log back to the master core;

[0120] The master core is configured to collect, store and process hot log related tasks in priority to the slave core; the slave core performs auxiliary tasks, including caching of cold logs and processing of related tasks of the cold logs.

[0121] It is understandable that this embodiment introduces a dynamic load balancing mechanism: the task allocation function of the master core: the master core promptly monitors the task load status of itself and the slave core, and dynamically adjusts the allocation strategy of log collection and processing tasks according to the load conditions. When the main core is highly loaded, some log processing tasks (such as the storage of low-priority logs) are delegated to the slave core for execution, reducing the pressure on the main core. Auxiliary storage tasks of the slave core: when the slave core load is low, the slave core can assume the local storage tasks of some logs, and regularly upload low-priority logs to the main core for centralized management. The slave core executes the assigned tasks through a lightweight log processing module to improve system resource utilization.

[0122] This embodiment introduces a core dynamic scheduling mechanism: According to the scheduling strategy of the Hongmeng operating system, a "core dynamic scheduling" mechanism is introduced, which combines the operating status of the master core and the slave core to flexibly adjust the execution core of log writing and processing tasks: The master core is responsible for key tasks: The collection, storage and processing tasks of high-priority logs are always executed by the master core first to ensure the timeliness and reliability of key data. The slave core performs auxiliary tasks: The slave core mainly performs caching and processing tasks of low real-time logs, and dynamically migrates tasks back to the master core when the load of the master core is reduced. Task scheduling process

[0123] In the specific implementation, this embodiment realizes load monitoring in the following way: the main core monitors the load status of each core in real time through the task scheduling module of the Hongmeng operating system, including CPU usage, memory occupancy and task queue length.

[0124] In a specific implementation, this embodiment implements task allocation in the following manner: the master core dynamically allocates log tasks according to the load monitoring result: high-priority log processing is allocated to the master core resources with lower load, and low-priority tasks are allocated to idle slave core resources.

[0125] In a specific implementation, this embodiment implements task migration in the following manner: when the load of the master core or the slave core changes, the task scheduling module automatically adjusts the execution core of the log processing task to avoid system performance degradation.

[0126] Through the above technical solution, Embodiment 6 realizes the load balancing and dynamic scheduling of log processing in a multi-core environment, makes full use of the hardware resources of the main core and slave cores, improves the real-time performance and overall performance of the log system, and meets the requirements of the power industry for efficient log management.

[0127] Please refer to Figure 6 , Figure 6 , which is a schematic structural diagram of an embodiment of a computer device for executing the multi-core log management method of Embodiment 6 provided by this application. As Figure 6 shown, the computer device 1 of this embodiment includes: at least one processor 10 ( Figure 6 only one is shown in the figure), a processor 10, a memory 11, and a computer program 12 stored in the memory 11 and executable on the at least one processor 10. When the processor 10 executes the computer program 12, the steps in the embodiment of the multi-core log management method of this application are implemented.

[0128] The computer device may be a computing device such as a desktop computer, a notebook, a smart phone, a personal digital assistant, etc. loaded with the Power Harmony operating system.

[0129] Figure 6 The computer device shown in the figure may include, but is not limited to, a processor 10 and a memory 11. Those skilled in the art can understand that Figure 6 this is only an example of the computer device 1, and does not constitute a limitation on the computer device 1. It may include more or fewer components than shown in the figure, or combine some components, or different components. For example, it may also include input / output devices, network access devices, etc.

[0130] The so-called processor 10 may be a central processing unit (CPU), and this processor 10 may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or this processor may also be any conventional processor, etc.

[0131] In some embodiments, the memory 11 may be an internal storage unit of the computer device 1, such as the hard disk or memory of the computer device 1. In some other embodiments, the memory 11 may also be an external storage device of the computer device 1, such as the hard disk or memory of the computer device. In some other embodiments, the memory 11 may also be an external storage device of the computer device 1, such as the Dynamic Random Access Memory (DRAM), Solid State Drive (SSD), and Hard Disk Drive (HDD) equipped on the computer device, etc. The memory 11 is used to store an operating system, application programs, a BootLoader, data, and other programs, such as the program code of the computer program, etc. The memory 11 can also be used to temporarily store data that has been output or will be output.

[0132] For the content such as information interaction and execution process between the above-mentioned device / units, since it is based on the same concept as the method embodiments of the present application, for its specific functions and the technical effects brought, reference can be specifically made to the method embodiment part.

[0133] Those skilled in the art can clearly understand that for the convenience and conciseness of description, only the above division of each functional unit and module is used as an example. In actual applications, the above functions can be allocated to different functional units and modules according to needs, that is, the internal structure is divided into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiments can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above integrated unit can be implemented in the form of hardware or in the form of a software functional unit. In addition, the specific names of each functional unit and module are only for the convenience of mutual distinction and do not limit the protection scope of the present application. The specific working process of the units and modules in the above system can refer to the corresponding process in the foregoing method embodiments and will not be elaborated herein.

[0134] The embodiments of the present application also provide a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements the steps in the above-mentioned method embodiments of various multi-core log management methods.

[0135] The embodiments of the present application also provide a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it can implement the steps in the above-mentioned method embodiments of various multi-core log management methods.

[0136] When the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, to implement all or part of the processes in the above-mentioned embodiment methods of this application, a computer program can be used to instruct the relevant hardware to complete. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, the steps of the above-mentioned various method embodiments can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in the form of source code, object code, executable file or some intermediate form, etc. The computer-readable medium can at least include: any entity or device that can carry the computer program code to the photographing device / terminal device, recording medium, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electrical carrier signal, telecommunication signal, and software distribution medium. For example, a USB flash drive, a mobile hard disk, a magnetic disk or an optical disc, etc. In some jurisdictions, according to legislation and patent practice, the computer-readable medium cannot be an electrical carrier signal and a telecommunication signal.

[0137] In the above embodiments, the descriptions of the various embodiments have their own emphases. For the parts not detailed or recorded in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0138] The above-mentioned embodiments are only used to illustrate the technical solutions of this application, rather than to limit it; although this application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the various embodiments of this application, and should all be included in the protection scope of this application.

Claims

1. A multi-core log management architecture based on the power Hongmeng operating system, characterized in that: It includes a master core, a slave core and a shared memory area; the slave core includes a log generation module, a buffer module and a log upload module; The main core is configured to run the power Hongmeng operating system; The slave core is configured to run a naked running program, access hardware resources through the naked running program so that the log generation module generates original log data, and caches the original log data in the buffer module in real time; The slave core is further configured to run a real-time operating system to provide real-time task scheduling and resource management, and optimize the processing flow of the log data through the real-time task scheduling and the resource management; The log uploading module is configured to write the target log data at the tail of the cache of the buffer module into the shared memory area when the data cached in the buffer module reaches a preset condition; The master core is also used to monitor the data in the shared memory area, and when it monitors that the slave core uploads the target log data to the shared memory area, it reads the target log data in the shared memory area, and integrates, classifies and stores the target log data in sequence to establish a log index, and the log index is used to provide users with the function of querying log data.

2. The multi-core log management architecture according to claim 1, characterized in that: The power Hongmeng operating system is also configured with a multi-protocol storage management module and an intelligent storage scheduler; wherein the master core and the plurality of slave cores are configured with multiple types of storage devices; A multi-protocol storage management module, used to determine the response speed, bandwidth information and input / output performance information of each storage device; and select a target storage device from the storage devices according to the response speed, bandwidth information and input / output performance information of each storage device, and write the target log data into the target storage device; The intelligent storage scheduler is configured to monitor the operating status of each storage device in the master core and multiple slave cores; and adjust the load information of each storage device according to the operating status to reallocate the storage strategy of the log data.

3. The multi-core log management architecture as claimed in claim 2, characterized in that: The main core is also configured with a log priority management module; The log priority management module is used to sort the log data according to the priority in advance, and write the log data of the corresponding priority level into the storage device in sequence according to the priority order; The main core is further configured to reserve storage bandwidth for log data of the hot log, and the storage bandwidth is used to prevent other tasks from interfering with the writing of log data of the hot log into the storage device; wherein the hot log represents a log with a high priority level; The slave core is configured to cyclically store cache data in the buffer of the buffer module; wherein, when the cache data in the buffer reaches the cache tail, the buffer module writes new cache data into the cache head of the buffer.

4. The multi-core log management architecture according to claim 1, characterized in that: The master core is assigned with read and write permissions for all logs, wherein all logs include local logs generated by each slave core and other logs uploaded by external devices; The slave core is assigned access rights to the local logs generated by it.

5. The multi-core log management architecture as claimed in claim 3, characterized in that: The main core is also configured to handle the storage and management of hot logs; The slave core is further configured to process local caching and task distribution of cold logs; the types of the storage devices also include high-speed storage devices and slave core local storage devices; wherein the hot logs are stored in the high-speed storage devices controlled by the master core; the cold logs are cached in the local storage devices of the slave cores, and the cold logs represent logs with low priority levels; The master core is used to monitor the storage status of the local storage device of the slave core, and when the local storage device of the slave core reaches a full load condition, control the slave core to clean up the cold log, or transfer the cold log to the high-speed storage device.

6. A multi-core log management method based on the power Hongmeng operating system, characterized in that: The management method is implemented based on the multi-core log management architecture based on the power Hongmeng operating system as described in any one of claims 1 to 5, and the method includes: The main core runs the power Hongmeng operating system; The slave core runs the naked running program, accesses hardware resources through the naked running program so that the log generation module generates original log data, and caches the original log data in the buffer module in real time; The slave core runs a real-time operating system to provide real-time task scheduling and resource management, and optimizes the processing flow of the log data through the real-time task scheduling and the resource management; When the data cached in the buffer module by the slave core reaches a preset condition, the target log data located at the cache tail of the buffer module is written into the shared memory area; The master core monitors the data in the shared memory area, and when it monitors that the slave core uploads the target log data to the shared memory area, it reads the target log data in the shared memory area, and integrates, classifies and stores the target log data in sequence to establish a log index, and the log index is used to provide users with a function of querying log data.

7. The multi-core log management method according to claim 6, characterized in that: The method further comprises: The master core monitors the load status of the master core and the slave core to obtain the current load status; The master core dynamically adjusts the allocation strategy of log collection and processing tasks according to the current load condition, including delegating the processing task of cold logs to the slave core when the master core reaches a high load operation condition, and the slave core processes the processing task of the cold logs; When the slave core reaches a low-load operating condition, the cold log is uploaded to the master core for centralized management; When determining that the load of the master core is reduced, the slave core migrates the processing task of the cold log back to the master core.

8. The multi-core log management method according to claim 7, characterized in that: The master core is configured to collect, store and process tasks related to hot logs in priority to the slave core; the slave core is configured to perform auxiliary tasks, including caching of cold logs and processing of tasks related to the cold logs.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 6 to 8 are implemented.

10. A computer program product, characterized in that The computer program product stores a computer program, and when the computer program is executed by a processor, the steps of the method according to any one of claims 6 to 8 are implemented.

Images