Processor lag monitoring method and device

Abstract

The invention discloses a processor lag monitoring method and device, and relates to the technical field of processor monitoring. The method comprises the following steps: judging a relationship between a storage space required by to-be-reported asset information and a preset capacity of an asset information partition in a shared memory; when the capacity exceeds the preset capacity, the free space of other function partitions in the shared memory is adjusted to the asset information partition to expand the capacity to generate the target asset information partition, so that the traditional fixed shared memory layout limitation is broken, the storage area is adjusted according to the actual asset information scale, and the problem that excessive asset information cannot be stored is avoided; the integrity of asset information storage is ensured; after adjustment, whether the capacity of the target asset information partition meets the requirement or not is judged again, if yes, direct reporting is carried out, and if not, the asset information to be reported is filtered and then reported, so that it is ensured to the maximum extent that the asset information can be reliably reported to the target asset information partition in different storage capacity scenes; and the asset management efficiency and accuracy of the server management system are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of processor monitoring, and in particular to a processor lag monitoring method and device. BACKGROUND

[0002] In a server and storage system, a processor is a core computing unit, and its performance and stability directly affect user experience and system reliability. With the increasing complexity of applications and the growing demand for multi-task parallelism, processor resource contention intensifies, and lag phenomena occur frequently.

[0003] The prior art adjusts process priority to alleviate lag through static and single dynamic threshold, which cannot adapt to dynamic needs in different scenarios and can only handle software load type lag, and cannot detect and solve processor lag problems (such as lag caused by hardware failure and firmware processing limitations). The lag causes difficulty in identifying the cause and slow response, which seriously affects system reliability and business continuity.

[0004] Therefore, how to accurately detect and efficiently handle processor lag has become a problem to be solved. SUMMARY

[0005] The present application provides a processor lag monitoring method and device to at least solve the problem of detection and processing efficiency of processor lag in related technologies.

[0006] The present application provides a processor lag monitoring method applied to a controller in a processor lag monitoring system, comprising: receiving a lag message of a processor; the lag message is generated when a basic input and output system reads a status register of the processor or receives a hardware interrupt; or is generated by an operating system by comparing the time difference between a global timer and a local timer of each task processing thread; in response to the lag message, obtaining a target source of the lag message; when the source of the lag message is the basic input and output system, analyzing a first lag cause contained in the lag message, and synchronizing the first lag cause to the operating system to instruct the operating system to perform business migration and / or generate a lag alarm according to the first lag cause; the first lag cause indicates that the processor has a hardware exception; when the source of the lag message is the operating system, analyzing a second lag cause contained in the lag message, and performing business migration and / or generating a second lag alarm according to the second lag cause; the second lag cause indicates that the processor has a software exception.

[0007] The present application also provides a processor lag monitoring device, comprising: A receiving unit is used to receive stuttering messages from the processor; the stuttering messages are generated when the basic input / output system reads the processor's status register or receives a hardware interrupt; or they are generated by the operating system by comparing the time difference between the global timer and the local timers of each task processing thread. The first processing unit is configured to, when the source of the lag message is the basic input / output system, parse the first lag reason contained in the lag message and synchronize the first lag reason to the operating system, so as to instruct the operating system to perform service migration and / or generate a lag alarm according to the first lag reason; the first lag reason indicates that the processor has a hardware abnormality; The second processing unit is configured to, when the source of the lag message is the operating system, parse the second lag reason contained in the lag message, and perform service migration and / or generate a second lag alarm based on the second lag reason; the second lag reason indicates that the processor has a software abnormality.

[0008] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the processor stuttering monitoring methods described above when executing the computer program.

[0009] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the processor stuttering monitoring methods described above.

[0010] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the processor stuttering monitoring methods described above.

[0011] This application distinguishes the source of lag messages, namely the Basic Input / Output System (PIS) or the Operating System (OS), and analyzes hardware and software lag causes separately, executing differentiated responses. By classifying and analyzing the first lag cause (hardware lag) and the second lag cause (software lag), it accurately locates the root cause of lag, avoiding the difficulty in identifying lag causes in the background technology. Furthermore, leveraging the collaborative mechanism between the PIS and the OS, it can quickly trigger business migration or generate tiered alarms for hardware or software lag causes, significantly improving the response speed of lag handling, ensuring system reliability and business continuity, and proactively monitoring processor lag, thus solving the pain point of the background technology's inability to detect processor lag itself. Attached Figure Description

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

[0013] Figure 1 This is one of the flowcharts illustrating a processor stuttering monitoring method provided in an embodiment of this application; Figure 2 A second schematic flowchart illustrating a processor stuttering monitoring method provided in this application embodiment; Figure 3 A third flowchart illustrating a processor stuttering monitoring method provided in this application embodiment; Figure 4 This is a schematic diagram of a processor stuttering monitoring device provided in an embodiment of this application. Detailed Implementation

[0014] The technical solutions of the embodiments 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, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0015] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0016] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0017] This application provides a processor stuttering monitoring method, applied to the controller in a processor stuttering monitoring system. The method is described in detail below, along with its execution flow. (Refer to...) Figure 1 As shown, the specific steps provided for this application include the following: S11, Receive processor lag message.

[0018] The stuttering message is obtained by the basic input / output system by reading the processor's status register or receiving a hardware interrupt; or by the operating system by comparing the time difference between the global timer and the local timers of each task processing thread.

[0019] It should be noted that the processor can be a central processing unit (CPU), a graphics processing unit (GPU), etc., and this application does not make any specific limitation in this regard.

[0020] In this embodiment of the application, this step is used to obtain stuttering-related information generated by the processor during operation. The stuttering messages are generated from two sources: one is stuttering messages from the Basic Input / Output System (BIOS); the other is stuttering messages from the Operating System (OS). The BIOS is a firmware program embedded on the computer motherboard, responsible for initializing hardware devices and booting the operating system at startup, and providing an interface for interaction between the underlying hardware and software. The OS is system software that manages computer hardware and software resources, responsible for core functions such as process scheduling, memory management, device drivers, and user interaction, and is the basic environment for running computer applications (such as Windows, Linux, Unix, etc.).

[0021] Specifically, the BIOS, as the underlying firmware that directly interacts with the hardware, uses a preset hardware monitoring mechanism to capture abnormal hardware states of the processor (CPU) in real time. This can be achieved through the following two methods: Actively querying the status register means that the BIOS can periodically query the target status registers inside the CPU (such as the error status register, fault log register, etc.). When the register value shows that there is a hardware fault (such as link interruption, data verification error, core frequency reduction, etc.), a stuttering message containing hardware abnormality information is generated.

[0022] When receiving hardware interrupts, in Firmware First Mode (FFM), if the CPU firmware detects its own hardware failure (such as cache error or bus abnormality), it will actively send an error alarm to the BIOS through a hardware interrupt signal. The BIOS will then generate a stutter message based on the alarm.

[0023] The operating system (OS) monitors software-level task scheduling anomalies through a timing comparison mechanism. Specifically, the operating system kernel maintains a global timer (recording the system's unified time) and configures an independent local timer for each CPU core's task processing thread (recording the cumulative time of the thread's task processing). When a task processing thread is scheduled, the operating system compares the time difference between the global timer and the local timer (e.g., the global time elapsed far exceeds the local task processing cumulative time, or the time difference between task enqueueing and dequeueing exceeds the limit) to determine if there is a software scheduling anomaly (such as thread blocking or task backlog), and generates a stuttering message containing software anomaly information.

[0024] Furthermore, upon receiving a lag message, the system first identifies the entity that generated the message (i.e., the target source) to distinguish whether the lag is caused by hardware or software factors.

[0025] If the message carries BIOS identifiers (such as header information in a specific format or hardware interface transmission markers), the target source is determined to be the Basic Input / Output System; if the message is generated by an OS kernel process and passed through a system call, the target source is determined to be the Operating System.

[0026] This provides a foundation for differentiated handling of lag issues, ensuring that hardware and software anomalies are accurately distinguished.

[0027] S12. When the source of the lag message is the basic input / output system, parse the first lag reason contained in the lag message and synchronize the first lag reason to the operating system, so as to instruct the operating system to perform business migration and / or generate a lag alarm according to the first lag reason.

[0028] The first cause of the stuttering indicates a hardware malfunction in the processor.

[0029] Specifically, when a stuttering message originates from the BIOS, it indicates that the stuttering is caused by a CPU hardware malfunction. The process is as follows: First, specific information about the hardware malfunction is extracted from the stuttering message, such as the malfunction type (e.g., memory controller failure, PCIe link error), the affected CPU core number, and the timestamp of the malfunction. This information collectively constitutes the primary cause of the stuttering, directly pointing to the hardware-level fault. Then, this information is synchronized to the operating system and a response is triggered. That is, the BIOS transmits the primary cause of the stuttering to the operating system through a preset hardware interface (e.g., the ACPI specification interface) or a shared memory region. Upon receiving this information, the operating system performs the following corresponding operations based on the severity of the hardware malfunction: If the anomaly is minor and recoverable (such as single-bit error correction), a stuttering alarm will be triggered (logs will be sent to the operations and maintenance system).

[0030] If a serious anomaly occurs (such as a multi-core failure), a high-priority service migration will be performed immediately (migrating tasks on the affected cores to normal cores) to avoid service interruption.

[0031] S13. When the source of the lag message is the operating system, parse the second lag reason contained in the lag message, and perform business migration and / or generate a second lag alarm based on the second lag reason.

[0032] The second cause of the stuttering indicates a software anomaly in the processor.

[0033] Specifically, when a stuttering message originates from the OS, it indicates that the stuttering is caused by a software scheduling anomaly. The specific processing steps are as follows: First, the secondary cause of the stuttering is analyzed, that is, the specific information of the software anomaly is extracted from the stuttering message, such as the anomaly type (e.g., thread scheduling delay, task queue blocking), the ID of the task involved, the time difference between global and local timers, etc. This information constitutes the secondary cause of the stuttering, reflecting a scheduling problem at the software level; then, the operating system performs targeted processing based on the secondary cause of the stuttering. If the localized lag is caused by a single-task blocking issue, the abnormal task can be forcibly woken up or terminated through the process management mechanism, and subsequent tasks in the queue can be rescheduled. If the widespread lag is caused by uneven core load, start the load balancing algorithm to migrate tasks from high-load cores to low-load cores, adjust thread priorities to prevent further backlog, and log exceptions for subsequent optimization.

[0034] Furthermore, by distinguishing the source and cause of the lag message through the above steps, this application achieves layered monitoring and precise response to CPU hardware and software anomalies, ensuring timely handling of hardware failures and improving the recovery efficiency of software scheduling anomalies, ultimately enhancing system stability and business continuity.

[0035] This application distinguishes the source of lag messages, namely the Basic Input / Output System (PIS) or the Operating System (OS), and analyzes hardware and software lag causes separately, executing differentiated responses. By classifying and analyzing the first lag cause (hardware lag) and the second lag cause (software lag), it accurately locates the root cause of lag, avoiding the difficulty in identifying lag causes in the background technology. Furthermore, leveraging the collaborative mechanism between the PIS and the OS, it can quickly trigger business migration or generate tiered alarms for hardware or software lag causes, significantly improving the response speed of lag handling, ensuring system reliability and business continuity, and proactively monitoring processor lag, thus solving the pain point of the background technology's inability to detect processor lag itself.

[0036] As an extension and refinement of the above embodiments, refer to Figure 2As shown in the embodiments of this application, the generation of processor stuttering messages in the above embodiments is refined, and the specific steps include the following: S21. Obtain the processor's hardware abnormal status through the basic input / output system.

[0037] It should be noted that before obtaining the processor's hardware abnormal status through the basic input / output system, the processor's reliability, availability, and serviceability functions need to be configured. These functions include hardware fault detection mechanisms, error recovery strategies, and abnormal status reporting interfaces.

[0038] Specifically, RAS function configuration refers to the parameter settings and function activation of the three core capabilities of computer hardware (especially core components in servers and industrial equipment such as CPU, memory, and bus). Its essence is to improve the fault response capability of the hardware system through underlying hardware mechanisms and firmware configuration, so as to provide a guarantee for the stable operation of upper-layer services.

[0039] Therefore, before obtaining the abnormal hardware status of the processor (CPU) through the Basic Input / Output System (BIOS), the CPU must first be configured with the RAS function.

[0040] In this embodiment, the hardware fault detection mechanism enables real-time detection of hardware problems such as memory data errors, bus transmission anomalies, and core operation failures by activating the error detection circuit inside the CPU (such as the ECC memory verification module, bus error monitoring unit, etc.). Error recovery strategy involves configuring the CPU to automatically recover from correctable errors (such as data retransmission and resetting of the arithmetic unit) when it detects a correctable error (such as a single-bit ECC error), in order to avoid minor errors accumulating and causing stuttering.

[0041] The abnormal status reporting interface opens a hardware-level communication channel between the CPU and the BIOS (such as dedicated register mapping and interrupt signal link) to ensure that when a hardware abnormality occurs in the CPU, it can actively push abnormal information (such as fault type, location, and severity level) to the BIOS through this interface.

[0042] Through the above-mentioned RAS function configuration, the CPU can have the ability to "detect faults, recover from minor errors, and report serious anomalies" at the hardware level, providing underlying technical support for the BIOS to obtain hardware abnormal status and accurately identify the causes of stuttering, ensuring the comprehensiveness and timeliness of hardware anomaly monitoring.

[0043] Furthermore, after configuring the RAS function for the processor, the processor's hardware abnormal status can be obtained through the basic input / output system.

[0044] Specifically, as the underlying firmware that interacts directly with the hardware, the BIOS uses a preset hardware monitoring mechanism to capture abnormal hardware states of the processor (CPU) in real time. This can be achieved by reading the processor's status register or receiving hardware interrupts.

[0045] Therefore, the above steps in this application (obtaining the processor's hardware abnormal state through the basic input / output system) can be further refined into the following two specific acquisition methods: (1) Periodically query the processor’s target status register through the basic input / output system to obtain the hardware abnormal status.

[0046] Specifically, this method can be understood as an active query of status registers. That is, the BIOS can access the processor's internal hardware status registers (such as error report registers, fault status registers, etc.) at preset intervals (such as every 100ms) and read the hardware event information recorded in the registers, such as memory check errors (ECC errors), PCIe bus link interruptions, core voltage abnormalities, cache coherence errors, etc., and then directly obtain the real-time operating status of the processor hardware based on the register values ​​to obtain hardware abnormal states.

[0047] (2) In firmware priority mode, the error alarm issued by the processor's error recovery module through hardware interrupt is received through the basic input / output system, and the corresponding status register is read according to the error alarm to obtain the hardware abnormal status.

[0048] Specifically, this method can be understood as passively receiving abnormal states. In FirmwareFirstMode, the processor's error recovery module (such as the CPU's Machine Check Architecture module and the GPU's Error Recovery Engine) will prioritize reporting hardware abnormalities to the BIOS via interrupt signals. Specifically, when the processor experiences a serious or sudden hardware abnormality (such as simultaneous failure of multiple cores, permanent bus interruption, or physical damage to video memory), the error recovery module immediately generates a hardware interrupt signal (such as the CPU's MCE interrupt or the GPU's PCIe error interrupt) and sends it to the BIOS via hardware links (such as interrupt controllers or dedicated signal lines).

[0049] Subsequently, after receiving the interrupt signal, the BIOS suspends the current low-priority task and triggers the exception handler, which parses the source identifier of the interrupt signal (such as the interrupt vector value) to determine the processor component where the exception occurred (such as "interrupt vector 0x2C corresponds to a cache error in CPU core 1"). Then, based on the source identifier, it accesses the corresponding detailed log register (such as the "Error Detail Register") to read information such as the timestamp of the exception, the fault location, and the scope of impact (such as "core 1 experienced a double-bit L2 cache error at T=12ms, affecting task queue number 0x0A").

[0050] Ultimately, this information is integrated into hardware anomaly status, providing a basis for subsequent analysis of the impact of stuttering.

[0051] Through these two methods, the BIOS can comprehensively obtain the abnormal hardware status of the CPU, providing raw data for subsequent analysis.

[0052] S22. Perform a stuttering impact analysis on the hardware abnormal state to determine if there is a hardware abnormality in the operating system based on the stuttering impact analysis results, and generate a processor stuttering message.

[0053] The processor lag message includes the first reason for the lag.

[0054] In this embodiment of the application, after the BIOS obtains the abnormal hardware status, it needs to further analyze whether the abnormality will have a substantial impact on the processor's computing power and task processing continuity (i.e. whether it may cause stuttering), and then determine whether to trigger the hardware abnormality.

[0055] Specifically, hardware anomalies can be pre-classified into fatal anomalies, impactful anomalies, and negligible anomalies. For example, core physical damage and permanent bus interruption are fatal anomalies, which will directly prevent the CPU from processing tasks normally; single-bit ECC errors (which can be automatically corrected) are negligible anomalies, which usually do not affect real-time computing; while multi-bit ECC errors (which cannot be corrected) and frequent link retries are impactful anomalies, which may cause task processing delays.

[0056] Furthermore, quantitative analysis is performed on impactful anomalies. For example, the number of bus errors per unit time is counted. If it exceeds a preset threshold (e.g., 5 errors within 1 second), it is determined that it will cause data transmission lag. The number of affected cores is counted. If it exceeds 20% of the total number of cores, it is determined that it will affect the overall computing power.

[0057] Through the above analysis, the BIOS can determine whether a current hardware malfunction will cause CPU lag, thus avoiding the accidental triggering of the lag handling process due to minor, harmless hardware events.

[0058] It should be noted that performing stuttering impact analysis on hardware anomalies, and determining the specific circumstances under which the processor may have hardware anomalies based on the stuttering impact analysis results, can include the following: (1) When the hardware abnormality is a hardware link failure, count the number of fault channels. If the number of fault channels exceeds the first threshold, it is determined that the processor's computing power is affected.

[0059] Specifically, hardware links (such as the DDR channel between the processor and memory, the PCIe link connecting to external devices, etc.) are the "physical channels" for processor data transmission, and their failures will directly hinder data interaction.

[0060] Furthermore, the BIOS first locates the specific channel that has failed by reading the link status register (such as the PCIe link status register and the DDR channel health status register) (e.g., "DDR memory channel 0 signal lost" or "PCIe 4.0 link 2 protocol error"), and counts the total number of channels currently in a fault state (denoted as F).

[0061] The first threshold (denoted as T1) is set based on the system link redundancy design and the minimum bandwidth requirements of the service. For example, if the server is configured with 8 DDR memory channels, and the core service requires at least 6 channels to operate normally to ensure data throughput, then T1 can be set to 2 (i.e., a maximum of 2 channels can fail). When F > T1, the total bandwidth of the remaining normal channels cannot meet the data interaction requirements between the processor and memory / peripherals, which will cause tasks to be blocked while waiting for data (such as CPU instructions stalling due to memory read delays), and is therefore judged as affecting the processor's computing power.

[0062] (2) When the hardware abnormality is a data verification error, the data retransmission amount is counted. If the data retransmission amount exceeds the second threshold, it is determined that the processor's computing power is affected.

[0063] Specifically, data verification errors (such as memory ECC errors or cache CRC verification failures) will trigger data retransmission or error correction processes, which will consume additional processor resources.

[0064] Furthermore, the BIOS first records the number of data retransmissions caused by checksum errors per unit time (e.g., memory read / write retransmission count R) or the total number of bytes of retransmitted data (e.g., cache line retransmission bytes B) through the error log register. For example, if a single-bit ECC error is detected during memory read, data needs to be read again from the backup unit, which is recorded as 1 retransmission; a 64-byte cache line retransmission caused by cache consistency check failure is recorded as 64-byte retransmission amount.

[0065] The second threshold (denoted as T2) is set based on the processor's computing power redundancy (e.g., the retransmission count threshold T2_R = 10 times / second, or the retransmission byte count threshold T2_B = 1MB / second). When R > T2_R or B > T2_B, it indicates that a large amount of processor time is used for data retransmission (rather than executing business tasks), resulting in a decrease in effective computing power and an increase in task processing latency, thus being judged as affecting the processor's computing power.

[0066] Through the above quantitative judgment, minor anomalies (such as single redundant link failure or occasional data retransmission) can be accurately distinguished from anomalies that substantially affect the calculation, ensuring that subsequent processing (such as generating a stuttering message) is triggered only for hardware problems that may actually cause stuttering. This avoids excessive response and waste of resources, while also ensuring timely handling of critical anomalies.

[0067] In this embodiment of the application, if it is determined through analysis that a hardware malfunction will cause CPU lag (i.e., there is a substantial hardware malfunction), the BIOS will generate a corresponding processor lag message, which includes a first cause of lag. The first cause of lag may include the specific type of hardware malfunction (such as "PCIe link failure" or "core 0 cache error"), the timestamp and duration of the malfunction, the affected CPU core, hardware components (such as memory channels and bus interfaces), and the severity level of the malfunction (such as "service migration is required" or "alarm prompt is recommended").

[0068] Furthermore, this lag message will serve as a carrier for the BIOS to synchronize hardware anomaly information to the operating system in subsequent steps, ensuring that the operating system can accurately locate hardware problems and execute targeted responses (such as service migration and lag alarms).

[0069] The above steps establish a hardware-level pre-detection mechanism for stuttering by actively monitoring, analyzing the impact of, and generating messages for CPU hardware anomalies through the BIOS. This lays the foundation for subsequent hardware and software collaborative processing of stuttering issues and effectively improves the accuracy and timeliness of identifying hardware anomalies and stuttering.

[0070] As an extension and refinement of the above embodiments, refer to Figure 3 As shown in the embodiments of this application, the generation of processor stuttering messages in the above embodiments is refined, and the specific steps include the following: S31. For any task processing thread in the operating system, obtain the start timestamp of the task sequence that the task processing thread starts processing and the effective processing time of each task in the task sequence.

[0071] In this embodiment, the operating system allocates a task processing thread to each core of the processor, and each thread corresponds to a sequence of tasks to be executed; a global timer is used to record the start timestamp of each task processing thread when it begins processing the corresponding task sequence; each task processing thread is configured with a corresponding local timer to record the duration of processing each task in its own task sequence.

[0072] Therefore, the operating system maintains an independent task processing thread for each core of the processor, and each thread corresponds to a sequence of tasks to be executed (such as a process queue or a thread pool task list).

[0073] The start timestamp refers to the unified system time (i.e., the start timestamp) recorded by the operating system through a global timer when a task processing thread is scheduled to a certain core of the processor and begins to execute its corresponding task sequence. This timestamp marks the starting point for the core to process the entire task sequence.

[0074] The effective processing time of each task refers to the time taken for each task sequence to process multiple subtasks. The operating system configures an independent local timer for each task processing thread. When a thread starts processing a subtask, the local timer starts counting. After each subtask is completed, the timer stops and records the effective processing time of that subtask (i.e., the local time difference).

[0075] For example, a task processing thread has a start timestamp of T0, and its task sequence contains 3 subtasks. The effective processing times recorded by the local timer are t1, t2, and t3, respectively.

[0076] S32. By combining the start timestamps of multiple task processing threads and the effective processing time of each task, determine that there is a software exception in the operating system and generate a processor stall message.

[0077] The processor lag message includes a second reason for the lag.

[0078] In this embodiment of the application, the operating system compares the time data of multiple threads and analyzes the matching between the task execution progress and the passage of time to determine whether there are software-level task processing anomalies (such as scheduling delay, thread blocking, task backlog, etc.).

[0079] Specifically, the detailed steps for determining that the operating system has a software anomaly and generating a processor stall message by combining the start timestamps of multiple task processing threads and the effective processing time of each task include the following steps 1 and 2: Step 1: For any task in each task processing thread, calculate the difference between the total time from the start timestamp of the task thread to the completion of task processing and the effective processing time accumulated by the local timer of that task.

[0080] In this step, by comparing two time dimensions, the ineffective time consumed by the task during execution due to software scheduling issues is quantified.

[0081] Specifically, it refers to any specific task within each task processing thread in the operating system (i.e., refined to the single-task level).

[0082] Furthermore, the total duration refers to the time span from the start timestamp of the thread to which the task belongs (the initial time when the thread begins processing the task sequence, recorded by a global timer) to the time when the current task is completed (also recorded by a global timer). This duration reflects the global time elapsed from thread startup to task completion, including all processes such as task execution, waiting, and blocking.

[0083] Effective processing time refers to the actual runtime accumulated by a thread-specific local timer during the execution of the task. The local timer only counts when the task is actually occupying processor cores for execution. When the task is paused due to blocking (such as waiting for resources or I / O responses) or being preempted by a higher-priority thread, the local timer stops counting. Therefore, this duration only reflects the "pure execution time of the task actually consuming CPU resources."

[0084] Then, the difference between the total duration and the effective processing time is obtained. This difference directly represents the non-execution time of the task during execution (i.e., the lag time caused by software scheduling anomalies).

[0085] Step 2: If the difference exceeds the preset time threshold, it is determined that there is a software abnormality in the operating system, and a processor lag message is generated.

[0086] Then, the difference is compared with a preset duration threshold (set according to the task type, such as 200ms for computationally intensive tasks and 1000ms for I / O intensive tasks). If the difference exceeds the threshold, it indicates that the task's lag time is too long and exceeds the system's tolerance range.

[0087] At this point, it is directly determined that there is a software anomaly in the operating system (such as thread scheduling delay, blocking caused by resource contention, low IO processing efficiency, etc.), and then a processor stutter message containing the second cause of the stutter is generated. The thread ID, task ID, time difference, and over-limit threshold of the abnormal task must be clearly specified to provide accurate basis for subsequent business migration or stutter alarm.

[0088] This application embodiment uses single-task-level time difference analysis to accurately capture micro-scheduling anomalies at the software level, namely the stuttering and non-timing characteristics of local timers. This allows the time difference value to directly point to the non-execution time of the task, thereby distinguishing between the task's own computation time and the stuttering time caused by scheduling problems, and achieving accurate identification of software anomalies.

[0089] Furthermore, this message will serve as the basis for the operating system to execute targeted responses (such as task migration, process priority adjustment, and lag alerts) in subsequent steps, ensuring that software lag is quickly located and handled.

[0090] It should be noted that the embodiments of this application can also compare the execution progress of multiple task processing threads. For example, if a thread corresponding to a certain core is in an over-limit state for a long time, while the time difference of other core threads is within the normal range, it may be that the thread is preempted by a higher priority process, or there may be problems such as deadlock or I / O blocking; if multiple threads simultaneously exceed the time difference limit and the proportion of unfinished tasks surges, it may be that the operating system scheduling algorithm is abnormal or global resources are insufficient (such as task blocking caused by memory leaks).

[0091] This application embodiment constructs a software-level lag detection mechanism by meticulously collecting task processing time data and verifying abnormal states from multiple dimensions through the above steps. This enables accurate identification of operating system task scheduling anomalies and provides reliable support for improving the stability of system software operation.

[0092] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0093] Embodiments of this application also provide a processor stuttering monitoring device, which corresponds one-to-one with the method claims. Figure 4 This is a schematic diagram of the structure of a processor lag monitoring device 400 provided in this disclosure, as shown below. Figure 4 As shown, the device 400 of this embodiment includes: The receiving unit 41 is used to receive a stutter message from the processor; the stutter message is generated when the basic input / output system reads the status register of the processor or receives a hardware interrupt; or it is generated by the operating system by comparing the time difference between the global timer and the local timers of each task processing thread. The first processing unit 42 is configured to, when the source of the lag message is the basic input / output system, parse the first lag reason contained in the lag message and synchronize the first lag reason to the operating system, so as to instruct the operating system to perform service migration and / or generate a lag alarm according to the first lag reason; the first lag reason indicates that there is a hardware abnormality in the processor; The second processing unit 43 is used to parse the second cause of lag contained in the lag message when the source of the lag message is the operating system, and to perform service migration and / or generate a second lag alarm based on the second cause of lag; the second cause of lag indicates that there is a software abnormality in the processor.

[0094] As an optional implementation of this application, the processor stuttering monitoring device further includes a generation unit, specifically used to obtain the hardware abnormal state of the processor through the basic input / output system; perform stuttering impact analysis on the hardware abnormal state, so as to determine that the operating system has a hardware abnormality based on the stuttering impact analysis results, and generate the processor stuttering message; the processor stuttering message includes the first stuttering cause.

[0095] As an optional implementation of this application, the generating unit is further configured to, for any task processing thread of the operating system, obtain the start timestamp of the task sequence corresponding to the task processing thread and the effective processing time of each task in the task sequence; combine the start timestamps of multiple task processing threads and the effective processing time of each task to determine that the operating system has a software anomaly, and generate the processor stutter message; the processor stutter message includes the second stutter cause.

[0096] As an optional implementation of this application, the generation unit is further configured to perform reliability, availability and serviceability functions on the processor; the reliability, availability and serviceability functions include a hardware fault detection mechanism, an error recovery strategy and an abnormal status reporting interface.

[0097] As an optional implementation of this application, the generation unit is further configured to periodically query the target status register of the processor through the basic input / output system to obtain the hardware abnormal state; or, in firmware priority mode, to receive error alarms issued by the processor's error recovery module via hardware interrupts through the basic input / output system, and to read the corresponding status registers according to the error alarms to obtain the hardware abnormal state.

[0098] As an optional implementation of this application, the generation unit is further configured to: when the hardware abnormal state is a hardware link failure, count the number of fault channels; if the number of fault channels exceeds a first threshold, determine that the processor's computing power is affected, and generate the stuttering message containing the first stuttering cause; when the hardware abnormal state is a data verification error, count the number of data retransmissions; if the number of data retransmissions exceeds a second threshold, determine that the processor's computing power is affected, and generate the stuttering message containing the first stuttering cause.

[0099] As an optional implementation of this application, the generation unit is further configured to calculate, for any task in each task processing thread, the difference between the total duration from the start timestamp of the task thread to the completion of the task processing and the effective processing duration accumulated by the task's local timer; if the difference exceeds a preset duration threshold, it is determined that the operating system has a software anomaly, and the processor lag message is generated.

[0100] As an optional implementation of this application, the operating system allocates a task processing thread to each core of the processor, and each thread corresponds to a task sequence to be executed; the global timer is used to record the start timestamp of each task processing thread starting to process the corresponding task sequence; each task processing thread is configured with a corresponding local timer to record the duration of processing each task in its own task sequence.

[0101] As an optional implementation of this application, the processor stuttering monitoring device further includes: a third processing unit, specifically used to perform a hardware status check on the basic input / output system when the source of the stuttering message is the operating system, and after performing service migration according to the second stuttering cause, if a stuttering message originating from the same processor core is detected again within a preset time.

[0102] For a description of the features in the embodiment corresponding to the processor stuttering monitoring device, please refer to the relevant description of the embodiment corresponding to the processor stuttering monitoring method, which will not be repeated here.

[0103] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the processor stuttering monitoring method embodiments described above.

[0104] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the processor stuttering monitoring method embodiments described above when running.

[0105] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0106] The embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the processor stuttering monitoring method embodiments described above.

[0107] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the processor stuttering monitoring method embodiments described above.

[0108] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0109] The processor stuttering monitoring method and apparatus provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for monitoring processor lag, characterized in that, The controller used in the processor stuttering monitoring system includes: Receive processor stutter messages; the stutter messages are generated when the basic input / output system reads the processor's status register or receives a hardware interrupt; or they are generated by the operating system by comparing the time difference between the global timer and the local timers of each task processing thread; When the source of the lag message is the basic input / output system, the first lag reason contained in the lag message is parsed, and the first lag reason is synchronized to the operating system to instruct the operating system to perform service migration and / or generate a lag alarm based on the first lag reason; the first lag reason indicates that the processor has a hardware abnormality; When the source of the lag message is the operating system, the second lag reason contained in the lag message is parsed, and service migration and / or second lag alarm are performed based on the second lag reason; the second lag reason indicates that there is a software abnormality in the processor.

2. The method according to claim 1, characterized in that, Before obtaining the processor's stuttering message, the method further includes: The hardware abnormal status of the processor is obtained through the basic input / output system; A lag impact analysis is performed on the hardware abnormal state to determine whether the operating system has a hardware abnormality based on the lag impact analysis results, and a processor lag message is generated; the processor lag message includes the first lag cause.

3. The method according to claim 1, characterized in that, Before obtaining the processor's stuttering message, the method further includes: For any of the task processing threads in the operating system, obtain the start timestamp of the task processing thread when it begins processing the corresponding task sequence and the effective processing time of each task in the task sequence; By combining the start timestamps of the multiple task processing threads and the effective processing time of each task, it is determined that the operating system has a software anomaly, and a processor lag message is generated; the processor lag message includes the second lag cause.

4. The processor lag monitoring method according to claim 2, characterized in that, Before obtaining the processor's hardware abnormal state through the basic input / output system, the method further includes: Configure the processor with reliability, availability, and serviceability features; the reliability, availability, and serviceability features include hardware fault detection mechanisms, error recovery strategies, and abnormal status reporting interfaces.

5. The processor lag monitoring method according to claim 2, characterized in that, The step of obtaining the processor's hardware abnormal state through the basic input / output system includes: The processor's target status register is periodically queried through the basic input / output system to obtain the hardware abnormal status. or; In firmware priority mode, the basic input / output system receives error alarms issued by the processor's error recovery module via hardware interrupts, and reads the corresponding status registers based on the error alarms to obtain the hardware abnormal state.

6. The processor lag monitoring method according to claim 2, characterized in that, The step of performing a stuttering impact analysis on the hardware abnormal state, to determine, based on the stuttering impact analysis results, that the operating system has a hardware abnormality, and to generate a processor stuttering message, includes: When the hardware abnormality is a hardware link failure, the number of fault channels is counted. If the number of fault channels exceeds a first threshold, it is determined that the processor's computing power is affected, so as to generate the lag message containing the first cause of the lag. When the hardware abnormality is a data verification error, the data retransmission volume is counted. If the data retransmission volume exceeds the second threshold, it is determined that the processor's computing power is affected, so as to generate the stuttering message containing the first stuttering cause.

7. The processor lag monitoring method according to claim 3, characterized in that, The method combines the start timestamps of multiple task processing threads with the effective processing time of each task to determine that the operating system has a software anomaly and generates a processor lag message, including: For any task in each of the task processing threads, calculate the difference between the total duration from the start timestamp of the task thread to the completion of the task processing and the effective processing time accumulated by the local timer of the task. If the difference exceeds a preset time threshold, it is determined that the operating system has a software anomaly, and a processor lag message is generated.

8. The processor lag monitoring method according to claim 3, characterized in that, The operating system allocates a task processing thread to each core of the processor, and each thread corresponds to a sequence of tasks to be executed; the global timer is used to record the start timestamp of each task processing thread when it begins processing the corresponding task sequence; each task processing thread is configured with a corresponding local timer to record the duration of processing each task in its own task sequence.

9. The processor lag monitoring method according to claim 1, characterized in that, The method further includes: When the source of the lag message is the operating system, and after performing service migration based on the second lag cause, if a lag message originating from the same processor core is detected again within a preset time, then a hardware status check is performed on the basic input / output system.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, used to implement the steps of the processor stuttering monitoring method as described in any one of claims 1 to 9 when executing the computer program.

Images