Jitter detection method, device and equipment for critical task process in operating system

Abstract

The application discloses a jitter detection method for a key task process in an operating system, and comprises the following steps: sending a starting signal to each process state parameter monitoring module in a kernel layer by a jitter detection module in a user layer during operating system running; wherein each process state parameter monitoring module is a monitoring module for process state data of a corresponding category; collecting process state data of a corresponding category by each process state parameter monitoring module, and screening target process state data corresponding to a key task process from the collected initial process state data; and performing jitter detection on the key task process according to the target process state data by the jitter detection module. The application greatly reduces time consumption and complexity, and improves the efficiency and accuracy of the analysis of the causes of task process jitter. The application also discloses a device, equipment and storage medium, which have corresponding technical effects.

Description

Technical Field

[0001] This application relates to the field of computer application technology, and in particular to a method, apparatus, device, and computer-readable storage medium for detecting jitter in critical task processes of an operating system. Background Technology

[0002] In modern computer operating system environments, which include multi-core processors, multiple task processes run simultaneously. These task processes may interfere with each other. Accurate identification and intervention of the causes of jitter in a specific task process are crucial to ensuring the normal operation of the task process.

[0003] Currently, when critical task processes experience jitter, it's generally necessary to manually analyze the cause using system tools. However, this analysis cannot pinpoint the exact moment the jitter occurred during the task's execution. Furthermore, this method is typically time-consuming and complex, failing to meet the requirements for efficient and accurate monitoring.

[0004] In summary, how to effectively solve the problems of manual analysis of the causes of task process jitter being time-consuming and complex, and failing to meet the needs of efficient and accurate monitoring, is an urgent issue that needs to be addressed by those skilled in the art. Summary of the Invention

[0005] The purpose of this application is to provide a method for detecting jitter in critical task processes in an operating system. This method significantly reduces time consumption and complexity, and improves the efficiency and accuracy of analyzing the causes of jitter in task processes. Another purpose of this application is to provide a device, apparatus, and computer-readable storage medium for detecting jitter in critical task processes in an operating system.

[0006] To solve the above-mentioned technical problems, this application provides the following technical solution:

[0007] A method for detecting jitter in critical task processes in an operating system includes:

[0008] During the operation of the operating system, the jitter detection module in the user layer sends a start signal to the process status parameter monitoring modules in the kernel layer; wherein, each of the process status parameter monitoring modules is a module that monitors the process status data of its corresponding category.

[0009] The process status parameter monitoring modules of each process after startup are used to collect process status data of their respective categories to obtain initial process status data.

[0010] Obtain the target identification information of the preset key task processes to be detected;

[0011] Based on the target identification information, the target process status data corresponding to the key task process is filtered from each of the initial process status data, and the target process status data is returned to the jitter detection module;

[0012] The jitter detection module is used to detect jitter in the critical task process based on the target process status data.

[0013] In one specific embodiment of this application, during the operation of the operating system, a start signal is sent from the jitter detection module in the user layer to the process status parameter monitoring module in the kernel layer, including:

[0014] During the operation of the operating system, the jitter detection module sends a start signal to one or more process status parameter monitoring modules, including the kernel call monitoring module, input / output wait monitoring module, cross-inconsistent memory access architecture access monitoring module, and scheduling monitoring module.

[0015] In one specific embodiment of this application, the process status parameter monitoring modules that have completed startup collect process status data of their respective corresponding categories, including:

[0016] The extended Berkeley packet filter technique was used to trace the key functions corresponding to the process state parameter monitoring modules in the operating system kernel.

[0017] In one specific embodiment of this application, when the process state parameter monitoring module includes the scheduling monitoring module, the extended Berkeley packet filtering technology is used to trace the key functions corresponding to each process state parameter monitoring module in the operating system kernel, including:

[0018] The scheduling monitoring module initializes the extended Berkeley packet filter process based on the operating framework of the extended Berkeley packet filter technology of the operating system.

[0019] The extended Berkeley packet filtering technique is used to trace the process wake-up and process switching functions of the operating system kernel;

[0020] Accordingly, the target identifier information of the preset key task processes to be detected is obtained, including:

[0021] Obtain the second process control character of the critical task process;

[0022] Accordingly, the target process status data corresponding to the critical task process is filtered from the initial process status data according to the target identification information, and the target process status data is returned to the jitter detection module, including:

[0023] When the execution of the process wake-up function is traced, the first process control character contained in the process wake-up function is obtained;

[0024] Determine whether the first process control character and the second process control character are consistent;

[0025] If so, the execution time of the process wake-up function is obtained from each of the initial process state data, and the execution time of the process wake-up function is determined as the process wake-up time;

[0026] The process wake-up time is saved to a pre-generated map memory;

[0027] When the execution of the process switching function is traced, the third process control character contained in the process switching function is obtained;

[0028] Determine whether the third process control character is consistent with the second process control character;

[0029] If so, the execution time of the process switching function is obtained from each of the initial process state data, and the execution time of the process switching function is determined as the time when the critical task process is scheduled to the central processing unit.

[0030] Obtain the process wake-up time from the map memory;

[0031] Calculate the process scheduling delay based on the process wake-up time and the time when the critical task process is scheduled to the central processing unit.

[0032] Increment the process scheduling count by 1 to obtain the number of times the critical task process was scheduled between different central processing units;

[0033] The process scheduling latency and the number of scheduling attempts are saved to the map memory;

[0034] The process scheduling delay and the number of scheduling attempts are returned to the jitter detection module.

[0035] Accordingly, the jitter detection module performs jitter detection on the critical task process based on the target process status data, including:

[0036] Obtain the preset scheduling delay threshold and the preset scheduling count threshold;

[0037] The process scheduling delay is compared with the preset scheduling delay threshold to obtain a first comparison result;

[0038] The number of scheduling attempts is compared with the preset scheduling attempt threshold to obtain a second comparison result;

[0039] When the first comparison result is that the process scheduling delay exceeds the preset scheduling delay threshold and / or the second comparison result is that the scheduling number exceeds the preset scheduling number threshold, it is determined that the critical task process is jittering.

[0040] In one specific embodiment of this application, when the process state parameter monitoring module includes the kernel call monitoring module, the extended Berkeley packet filtering technology is used to trace the key functions corresponding to each process state parameter monitoring module in the operating system kernel, including:

[0041] The kernel call monitoring module is used to initialize the extended Berkeley packet filter process according to the operating framework of the extended Berkeley packet filter technology of the operating system;

[0042] The extended Berkeley packet filtering technique is used to trace the kernel entry and exit functions of the operating system kernel.

[0043] Accordingly, the target identifier information of the preset key task processes to be detected is obtained, including:

[0044] Obtain the second process control character of the critical task process;

[0045] Accordingly, the target process status data corresponding to the critical task process is filtered from the initial process status data according to the target identification information, and the target process status data is returned to the jitter detection module, including:

[0046] When the execution of the kernel entry function is traced, the fourth process control character contained in the kernel entry function is obtained;

[0047] Determine whether the fourth process control character is consistent with the second process control character;

[0048] If so, the execution time of the kernel entry function is obtained from the initial process state data, and the execution time of the kernel entry function is determined as the time when the kernel executes the system call.

[0049] The start time of the kernel system call execution is saved to the pre-generated map memory;

[0050] When the execution of the kernel output function is traced, the fifth process control character contained in the kernel output function is obtained;

[0051] Determine whether the fifth process control character is consistent with the second process control character;

[0052] If so, the execution time of the kernel output function is obtained from each of the initial process state data, and the execution time of the kernel output function is determined as the time when the kernel execution system call ends;

[0053] Obtain the start time of the kernel executing the system call from the map memory;

[0054] The total execution time of the kernel system call is calculated based on the end time and start time of the kernel system call, and the total execution time of the kernel system call is saved to the map memory.

[0055] The total execution time of the kernel system call is returned to the jitter detection module;

[0056] Accordingly, the jitter detection module performs jitter detection on the critical task process based on the target process status data, including:

[0057] Get the preset kernel system call execution time threshold;

[0058] The total execution time of the kernel system call is compared with the preset kernel system call execution time threshold to obtain a third comparison result;

[0059] When the third comparison result indicates that the total execution time of the kernel system call exceeds the preset kernel system call execution time threshold, it is determined that the critical task process is jittering.

[0060] In one specific embodiment of this application, when the process state parameter monitoring module includes the input / output waiting monitoring module, the extended Berkeley packet filtering technology is used to trace the key functions corresponding to each process state parameter monitoring module in the operating system kernel, including:

[0061] The input / output waiting monitoring module is used to initialize the extended Berkeley packet filter process according to the operating framework of the extended Berkeley packet filter technology of the operating system;

[0062] The extended Berkeley packet filtering technique is used to trace the waiting input / output processing functions of the operating system kernel;

[0063] Accordingly, the target identifier information of the preset key task processes to be detected is obtained, including:

[0064] Obtain the second process control character of the critical task process;

[0065] Accordingly, the target process status data corresponding to the critical task process is filtered from the initial process status data according to the target identification information, and the target process status data is returned to the jitter detection module, including:

[0066] When the execution of the waiting input / output processing function is traced, the sixth process control character contained in the waiting input / output processing function is obtained;

[0067] Determine whether the sixth process control character is consistent with the second process control character;

[0068] If so, the waiting time for input / output is obtained from the initial process state data.

[0069] The time spent waiting for input / output is saved to the pre-generated map memory;

[0070] The waiting time for input / output is returned to the jitter detection module;

[0071] Accordingly, the jitter detection module performs jitter detection on the critical task process based on the target process status data, including:

[0072] Obtain the preset waiting time threshold for input / output;

[0073] The waiting time for input / output is compared with the preset waiting time threshold to obtain a fourth comparison result;

[0074] When the fourth comparison result indicates that the waiting time for input / output exceeds the preset waiting time threshold, it is determined that the critical task process is jittering.

[0075] In one specific embodiment of this application, when the process state parameter monitoring module includes the cross-inconsistent memory access architecture monitoring module, the extended Berkeley packet filtering technology is used to trace the key functions corresponding to each process state parameter monitoring module in the operating system kernel, including:

[0076] The cross-inconsistent memory access architecture access monitoring module initializes the extended Berkeley packet filter process according to the operating framework of the operating system extended Berkeley packet filter technology.

[0077] The extended Berkeley packet filtering technique is used to trace the memory allocation functions of the operating system kernel;

[0078] Accordingly, the target identifier information of the preset key task processes to be detected is obtained, including:

[0079] Obtain the second process control character of the critical task process;

[0080] Accordingly, the target process status data corresponding to the critical task process is filtered from the initial process status data according to the target identification information, and the target process status data is returned to the jitter detection module, including:

[0081] When the execution of the memory allocation function is traced, the seventh process control character contained in the memory allocation function is obtained;

[0082] Determine whether the seventh process control character is consistent with the second process control character;

[0083] If so, the memory descriptor of the critical task process is obtained from each of the initial process state data;

[0084] Traverse the virtual memory spaces in the memory descriptor and obtain the non-consistent memory access architecture node where each virtual memory space is located; wherein, the non-consistent memory access architecture node includes local non-consistent memory access architecture nodes and remote non-consistent memory access architecture nodes;

[0085] The memory usage of processes in each of the aforementioned local non-consistent memory access architecture nodes is statistically analyzed to obtain the memory usage of local processes.

[0086] The memory usage of processes in each of the aforementioned remote non-consistent memory access architecture nodes is statistically analyzed to obtain the memory usage of remote processes.

[0087] The memory used by the local process and the memory used by the remote process are saved to the map memory;

[0088] The memory usage of the local process and the memory usage of the remote process are returned to the jitter detection module.

[0089] Accordingly, the jitter detection module performs jitter detection on the critical task process based on the target process status data, including:

[0090] Calculate the percentage of memory used by the local process and the percentage of memory used by the remote process;

[0091] Get the preset percentage threshold;

[0092] The percentage is compared with the preset percentage threshold to obtain the fifth comparison result;

[0093] When the fifth comparison result is that the percentage exceeds the preset percentage threshold, it is determined that the critical task process is jittering.

[0094] A jitter detection device for critical task processes in an operating system, comprising:

[0095] The signal sending unit is used to send a start signal to each process status parameter monitoring module in the kernel layer through the jitter detection module in the user layer during the operation of the operating system; wherein, each of the process status parameter monitoring modules is a module that monitors process status data of its corresponding category.

[0096] The data collection unit is used to collect process status data of their respective categories by utilizing the process status parameter monitoring modules of each process after startup, so as to obtain the initial process status data.

[0097] The identification information acquisition unit is used to acquire the target identification information of the preset key task process to be detected.

[0098] The data filtering unit is used to filter the target process status data corresponding to the key task process from each of the initial process status data according to the target identification information, and return the target process status data to the jitter detection module.

[0099] A jitter detection unit is used to perform jitter detection on the critical task process based on the jitter detection module according to the status data of each target process.

[0100] A jitter detection device for critical task processes in an operating system, comprising:

[0101] Memory, used to store computer programs;

[0102] A processor, used to implement the jitter detection method for a critical task process in the operating system as described above when executing the computer program.

[0103] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the jitter detection method for a critical task process in the operating system as described above.

[0104] The jitter detection method for critical task processes in the operating system provided in this application sends a start signal to each process status parameter monitoring module in the kernel layer through the jitter detection module in the user layer during the operation of the operating system. Each process status parameter monitoring module monitors process status data of its corresponding category. The started process status parameter monitoring modules collect process status data of their respective categories to obtain initial process status data. Target identification information of the preset critical task process to be detected is obtained. Based on the target identification information, target process status data corresponding to the critical task process is filtered from the initial process status data, and the target process status data is returned to the jitter detection module. The jitter detection module then performs jitter detection on the critical task process based on the target process status data.

[0105] As described above, the technical solution involves deploying a jitter detection module at the user layer of the operating system and process status parameter monitoring modules at the kernel layer. During operating system operation, the jitter detection module in the user layer sends a start signal to the process status parameter monitoring modules in the kernel layer. Once started, each process status parameter monitoring module collects process status data for its corresponding category, obtaining initial process status data. Based on the target identifier information of the critical task process to be detected, the system filters the target process status data corresponding to the critical task process from the initial process status data and returns this target process status data to the jitter detection module. The jitter detection module then performs jitter detection on the critical task process based on the target process status data, thereby determining the interference of a specified interference source on the process. This provides effective information for development or maintenance personnel, facilitating timely implementation of corresponding measures to ensure the operation of critical processes. Compared to manually analyzing the causes of task process jitter, this method significantly reduces time consumption and complexity, improving the efficiency and accuracy of analyzing the causes of task process jitter.

[0106] Accordingly, this application also provides a jitter detection device, apparatus, and computer-readable storage medium for critical task processes in an operating system, corresponding to the jitter detection method for critical task processes in the above-mentioned operating system, which has the above-mentioned technical effects, and will not be elaborated here. Attached Figure Description

[0107] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art 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.

[0108] Figure 1This is a flowchart illustrating one implementation of a jitter detection method for critical task processes in an operating system according to an embodiment of this application.

[0109] Figure 2 This is a structural block diagram of a jitter detection system for a critical task process in an operating system, as described in an embodiment of this application.

[0110] Figure 3 This is a flowchart illustrating another implementation of the jitter detection method for critical task processes in the operating system according to the embodiments of this application;

[0111] Figure 4 This is a flowchart illustrating another implementation of the jitter detection method for critical task processes in the operating system according to the embodiments of this application;

[0112] Figure 5 This is a flowchart illustrating another implementation of the jitter detection method for critical task processes in the operating system according to the embodiments of this application;

[0113] Figure 6 This is a flowchart illustrating another implementation of the jitter detection method for critical task processes in the operating system according to the embodiments of this application;

[0114] Figure 7 This is a flowchart illustrating another implementation of the jitter detection method for critical task processes in the operating system according to the embodiments of this application;

[0115] Figure 8 This is a structural block diagram of a jitter detection device for a critical task process in an operating system according to an embodiment of this application;

[0116] Figure 9 This is a structural block diagram of a jitter detection device for a critical task process in an operating system, as described in an embodiment of this application.

[0117] Figure 10 This is a schematic diagram of the specific structure of a jitter detection device for critical task processes in an operating system provided in this embodiment. Detailed Implementation

[0118] 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. Obviously, the described embodiments are merely some embodiments of the present application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0119] See Figure 1 , Figure 1 This is a flowchart illustrating an implementation of a jitter detection method for critical task processes in an operating system, as described in this application. The method may include the following steps:

[0120] S101: During the operation of the operating system, the jitter detection module in the user layer sends a start signal to the process status parameter monitoring module in the kernel layer.

[0121] Each process status parameter monitoring module monitors the process status data of its corresponding category.

[0122] See Figure 2 , Figure 2 This is a block diagram illustrating the structure of a jitter detection system for critical task processes in an operating system, as described in this application. A jitter detection module is pre-deployed at the user layer of the operating system (e.g., Linux), and process status parameter monitoring modules are deployed at the kernel layer. The user-layer jitter detection module communicates with the process status parameter monitoring modules in the kernel layer using EBPF (Extended Berkeley Packet Filter) technology and acquires the data collected by these modules. During operating system operation, the user-layer jitter detection module sends start signals to the process status parameter monitoring modules in the kernel layer. These start signals can be sent to one or more of the following modules: kernel call monitoring module, input and output wait (IO wait) monitoring module, non-uniform memory access (NUMA) monitoring module, and scheduling monitoring module. This allows for analysis of whether critical task processes are affected by these disturbances at different levels. Furthermore, the operation of each process status parameter monitoring module is independent, reducing the complexity of the analysis. When it is determined that there is jitter in the process of a critical task, corresponding intervention measures can be provided to eliminate the process jitter, ensure the operation of the critical process, and thus maintain the normal progress of the task.

[0123] The kernel call monitoring module monitors the total execution time of kernel system calls (syscalls), the input / output wait monitoring module monitors the time spent waiting for input / output, the cross-inconsistent memory access architecture access monitoring module monitors the memory usage of local processes and remote processes, and the scheduling monitoring module monitors process scheduling latency and scheduling count.

[0124] The syscall kernel provides a standard set of interfaces for user-space programs to interact with kernel space, allowing user-space programs to access hardware devices in a restricted manner.

[0125] EBPF is a packet filtering technology that is an extension of BPF (Berkeley Packet Filter).

[0126] NUMA is a processor architecture in which multiple processors and memory controllers are connected via a high-speed bus. Each processor has its own local memory but can access the memory of other processors.

[0127] S102: The process status parameter monitoring modules of each process after startup are used to collect the process status data of their respective categories to obtain the initial process status data.

[0128] After sending a start signal to the process status parameter monitoring modules in the kernel layer, the started process status parameter monitoring modules collect process status data of their respective categories and return the collected process status data to the jitter detection module in the user layer.

[0129] S103: Obtain the target identification information of the preset key task process to be detected.

[0130] The system pre-configures jitter detection for specific critical task processes and pre-stores the target identifier information of the critical task processes to be detected. After collecting the process status data of their respective categories using the process status parameter monitoring modules after startup, and obtaining the initial process status data, the system retrieves the target identifier information of the pre-defined critical task processes to be detected.

[0131] The target identification information can be a process ID, process control character, etc.

[0132] S104: Based on the target identification information, filter the target process status data corresponding to the critical task process from the initial process status data, and return the target process status data to the jitter detection module.

[0133] Each initial process status data contains identification information corresponding to its respective process. After obtaining the target identification information of the critical task process, the target process status data corresponding to the critical task process is filtered from the initial process status data based on the target identification information, and the target process status data is returned to the jitter detection module. By filtering the process status data that needs to be returned from the kernel layer to the user layer based on the target identification information, only the target process status data corresponding to the critical task process needs to be returned to the user layer, which greatly reduces the amount of data returned, improves the data return efficiency, and thus improves the efficiency of critical process jitter detection.

[0134] S105: Use the jitter detection module to perform jitter detection on the critical task process based on the target process status data.

[0135] The jitter detection module receives target process status data returned by the process status parameter monitoring module. Based on the received target process status data, the jitter detection module performs jitter detection on the critical task process to be detected. For example, the target process status data can be compared with its corresponding pre-set parameter thresholds to determine whether the critical task process has jitter.

[0136] As described above, the technical solution involves deploying a jitter detection module at the user layer of the operating system and process status parameter monitoring modules at the kernel layer. During operating system operation, the jitter detection module in the user layer sends a start signal to the process status parameter monitoring modules in the kernel layer. Once started, each process status parameter monitoring module collects process status data for its corresponding category, obtaining initial process status data. Based on the target identifier information of the critical task process to be detected, the system filters the target process status data corresponding to the critical task process from the initial process status data and returns this target process status data to the jitter detection module. The jitter detection module then performs jitter detection on the critical task process based on the target process status data, thereby determining the interference of a specified interference source on the process. This provides effective information for development or maintenance personnel, facilitating timely implementation of corresponding measures to ensure the operation of critical processes. Compared to manually analyzing the causes of task process jitter, this method significantly reduces time consumption and complexity, improving the efficiency and accuracy of analyzing the causes of task process jitter.

[0137] It should be noted that, based on the above embodiments, this application also provides corresponding improvement solutions. In subsequent embodiments, steps that are the same as or corresponding to those in the above embodiments can be referred to each other, and the corresponding beneficial effects can also be referred to each other. These improvements will not be elaborated upon in the following improved embodiments.

[0138] See Figure 3 , Figure 3 This is another implementation flowchart of the jitter detection method for critical task processes in the operating system according to the embodiments of this application. The method may include the following steps:

[0139] S301: During the operation of the operating system, the jitter detection module sends a start signal to one or more process status parameter monitoring modules, including the kernel call monitoring module, input / output wait monitoring module, cross-inconsistent memory access architecture access monitoring module, and scheduling monitoring module.

[0140] Each process status parameter monitoring module monitors the process status data of its corresponding category.

[0141] During operating system operation, the jitter detection module sends start signals to one or more process status parameter monitoring modules, including the kernel call monitoring module, input / output wait monitoring module, cross-inconsistent memory access architecture monitoring module, and scheduling monitoring module. By sending start signals to one or more process status parameter monitoring modules according to monitoring requirements, jitter detection can be performed on critical task processes based on the monitored process status data of the corresponding categories.

[0142] S302: Using extended Berkeley packet filtering technology, the key functions corresponding to the process state parameter monitoring modules in the operating system kernel are tracked to obtain the initial process state data.

[0143] By utilizing extended Berkeley packet filtering technology, key functions corresponding to process status parameter monitoring modules in the operating system kernel are traced. These functions include tracing `sys_enter` (kernel entry function) and `sys_exit` (kernel exit function) for the kernel call monitoring module, `sched_stat_iowait` (wait for input / output processing function) for the input / output wait monitoring module, `kmalloc` (memory allocation function) for the cross-inconsistent memory access architecture monitoring module, and `sched_wakeup` (process wake-up function) and `sched_switch` (process switching function) for the scheduling monitoring module. This process yields initial process status data. By using extended Berkeley packet filtering technology to trace these key functions, critical data is obtained. This data is then used to determine the extent of interference from specified sources on critical task processes, facilitating timely and appropriate intervention to ensure the normal operation of critical task processes.

[0144] S303: Obtain the target identification information of the preset key task process to be detected.

[0145] S304: Based on the target identification information, filter the target process status data corresponding to the critical task process from the initial process status data, and return the target process status data to the jitter detection module.

[0146] S305: Use the jitter detection module to perform jitter detection on critical task processes based on the target process status data.

[0147] See Figure 4 , Figure 4 This is another implementation flowchart of the jitter detection method for critical task processes in the operating system according to the embodiments of this application. The method may include the following steps:

[0148] S401: During the operation of the operating system, the jitter detection module sends a start signal to one or more process status parameter monitoring modules, including the kernel call monitoring module, input / output wait monitoring module, cross-inconsistent memory access architecture access monitoring module, and scheduling monitoring module.

[0149] Each process status parameter monitoring module monitors the process status data of its corresponding category.

[0150] S402: When the process status parameter monitoring module includes a scheduling monitoring module, the scheduling monitoring module is used to initialize the extended Berkeley packet filter process according to the operating framework of the extended Berkeley packet filter technology of the operating system.

[0151] When the user-layer jitter detection module needs to monitor scheduling latency and scheduling count, the process status parameter monitoring module, which includes a scheduling monitoring module, sends a start signal to the scheduling monitoring module through the jitter detection module. The scheduling monitoring module then initializes the extended Berkeley packet filter process based on the operating framework of the operating system-extended Berkeley packet filter technology.

[0152] S403: Tracks process wake-up and process switching functions in the operating system kernel using extended Berkeley packet filtering technology.

[0153] After initializing the extended Berkeley packet filter process, the operating system kernel's process wake-up function (sched_wakeup) and process switching function (sched_switch) are traced according to the extended Berkeley packet filter technology.

[0154] S404: Obtain the second process control character for the critical task process.

[0155] Obtain the second process control character for the critical task process.

[0156] S405: When the execution of the process wake-up function is traced, obtain the first process control character contained in the process wake-up function.

[0157] When the execution of the process wake-up function is traced, the first process control character (pid) contained in the process wake-up function is obtained.

[0158] S406: Determine whether the first process control character and the second process control character are consistent. If yes, proceed to step S407; otherwise, do nothing.

[0159] After obtaining the first process control character and the second process control character of the critical task process contained in the process wake-up function, it is determined whether the first process control character and the second process control character are consistent. If they are consistent, it means that the currently woken process is the preset critical task process, and step S407 is executed. If they are inconsistent, it means that the currently woken process is not the preset critical task process, and no processing is performed.

[0160] S407: Obtain the execution time of the process wake-up function from the initial process state data, and determine the execution time of the process wake-up function as the process wake-up time.

[0161] When it is determined that the first process control character is consistent with the second process control character, it indicates that the currently awakened process is the preset critical task process. The execution time of the process wake-up function is obtained from the initial process state data, and the execution time of the process wake-up function is determined as the process wake-up time.

[0162] S408: Save the process wake-up time to the pre-generated map memory.

[0163] After determining the process wake-up time, the process wake-up time is saved to the pre-generated map memory.

[0164] S409: When the execution of the process switching function is traced, obtain the third process control character contained in the process switching function.

[0165] When the execution of the process switching function is traced, the third process control character contained in the process switching function is obtained.

[0166] S410: Determine whether the third process control character is consistent with the second process control character. If yes, execute step S411; otherwise, do nothing.

[0167] After obtaining the third process control character contained in the process switching function, it is determined whether the third process control character is consistent with the second process control character. If they are consistent, it means that the critical task process is currently scheduled to the central processing unit (CPU) and step S411 is executed. If not, no action is taken.

[0168] S411: Obtain the execution time of the process switching function from the initial process state data, and determine the execution time of the process switching function as the time for the critical task process to be scheduled to the central processing unit.

[0169] When it is determined that the third process control character is consistent with the second process control character, it indicates that the critical task process has been scheduled to the central processing unit. The execution time of the process switching function is obtained from the initial process state data, and the execution time of the process switching function is determined as the time when the critical task process is scheduled to the central processing unit.

[0170] S412: Get the process wake-up time from the map memory.

[0171] After obtaining the time when the critical task process is scheduled to the central processing unit, the process wake-up time is obtained from the map memory.

[0172] S413: Calculate process scheduling latency based on process wake-up time and the time it takes for critical task processes to be scheduled to the central processing unit.

[0173] The process scheduling latency is calculated based on the process wake-up time and the time when the critical task process is scheduled to the central processing unit. That is, the process scheduling latency is obtained by subtracting the process wake-up time from the time when the critical task process is scheduled to the central processing unit.

[0174] S414: Increment the process scheduling count by 1 to obtain the number of times the critical task process is scheduled between different central processing units.

[0175] The number of times the critical task process is scheduled between different CPUs is stored in advance. After obtaining the time when the critical task process is scheduled to the CPU, the scheduling count is incremented by 1, and the latest scheduling count of the critical task process between different CPUs is obtained.

[0176] S415: Save the process scheduling latency and scheduling count to the map memory.

[0177] After calculating the process scheduling latency and counting the number of scheduling attempts, the process scheduling latency and the number of scheduling attempts are saved to the map memory.

[0178] S416: Return the process scheduling latency and scheduling count to the jitter detection module.

[0179] After calculating the process scheduling delay and counting the number of scheduling attempts, the process scheduling delay and the number of scheduling attempts are returned to the jitter detection module.

[0180] S417: Obtain the preset scheduling delay threshold and the preset scheduling count threshold.

[0181] Pre-set scheduling delay threshold and scheduling count threshold. After calculating the process scheduling delay and counting the number of scheduling operations, obtain the preset scheduling delay threshold and preset scheduling count threshold.

[0182] S418: Compare the process scheduling delay with the preset scheduling delay threshold to obtain the first comparison result.

[0183] After calculating the process scheduling delay and obtaining the preset scheduling delay threshold, the process scheduling delay is compared with the preset scheduling delay threshold to obtain the first comparison result.

[0184] S419: Compare the number of scheduling attempts with the preset scheduling attempt threshold to obtain the second comparison result.

[0185] After counting the number of scheduling attempts and obtaining the preset scheduling attempt threshold, the number of scheduling attempts is compared with the preset scheduling attempt threshold to obtain a second comparison result.

[0186] S420: When the first comparison result is that the process scheduling delay exceeds the preset scheduling delay threshold and / or the second comparison result is that the number of scheduling exceeds the preset scheduling number threshold, it is determined that the critical task process is jittering.

[0187] After obtaining the first comparison result and the second comparison result, it is determined whether the first comparison result indicates that the process scheduling latency exceeds the preset scheduling latency threshold, and whether the second comparison result indicates that the number of scheduling operations exceeds the preset scheduling number threshold. If the first comparison result indicates that the process scheduling latency exceeds the preset scheduling latency threshold, but the second comparison result indicates that the number of scheduling operations does not exceed the preset scheduling number threshold, it is determined that the critical task process exhibits jitter. If the first comparison result indicates that the process scheduling latency does not exceed the preset scheduling latency threshold, but the second comparison result indicates that the number of scheduling operations exceeds the preset scheduling number threshold, it is determined that the critical task process exhibits jitter. If the first comparison result indicates that the process scheduling latency exceeds the preset scheduling latency threshold, and the second comparison result indicates that the number of scheduling operations exceeds the preset scheduling number threshold, it is determined that the critical task process exhibits jitter. By determining that either the process scheduling latency or the number of scheduling operations exceeds its corresponding preset threshold, or both exceed their respective preset thresholds, it indicates that the parameter exceeding the corresponding threshold in the current process scheduling latency and number of scheduling operations will affect the performance of the critical task process, leading to jitter in the critical task process.

[0188] See Figure 5 , Figure 5 This is another implementation flowchart of the jitter detection method for critical task processes in the operating system according to the embodiments of this application. The method may include the following steps:

[0189] S501: During the operation of the operating system, the jitter detection module sends a start signal to one or more process status parameter monitoring modules, including the kernel call monitoring module, input / output wait monitoring module, cross-inconsistent memory access architecture access monitoring module, and scheduling monitoring module.

[0190] Each process status parameter monitoring module monitors the process status data of its corresponding category.

[0191] S502: When the process status parameter monitoring module includes a kernel call monitoring module, the kernel call monitoring module is used to initialize the extended Berkeley packet filter process according to the operating framework of the extended Berkeley packet filter technology of the operating system.

[0192] When the user-level jitter detection module needs to detect the execution duration of system calls, the process status parameter monitoring module, which includes the jitter detection module, sends a start signal to the process status parameter monitoring module. The kernel call monitoring module initializes the extended Berkeley packet filter process according to the operating framework of the operating system's extended Berkeley packet filter technology.

[0193] S503: Tracks kernel entry and exit functions of the operating system kernel using extended Berkeley packet filtering technology.

[0194] After initializing the extended Berkeley packet filter process, the kernel entry function (sys_enter) and kernel exit function (sys_exit) of the operating system kernel are traced according to the extended Berkeley packet filter technology.

[0195] S504: Obtain the second process control character for the critical task process.

[0196] S505: When the execution of a kernel entry function is traced, the fourth process control character contained in the kernel entry function is obtained.

[0197] When the execution of the kernel entry function is traced, the fourth process control character contained in the kernel entry function is obtained.

[0198] S506: Determine whether the fourth process control character is consistent with the second process control character. If yes, proceed to step S507; otherwise, do nothing.

[0199] After obtaining the fourth process control character and the second process control character of the critical task process contained in the kernel entry function, it is determined whether the fourth process control character and the second process control character are consistent. If they are consistent, it means that the process currently executing the system call is a critical task process, and step S507 is executed. If they are inconsistent, it means that the process currently executing the system call is not a critical task process, and no action is taken.

[0200] S507: Obtain the execution time of the kernel entry function from the initial process state data, and determine the execution time of the kernel entry function as the start time of the kernel system call.

[0201] When it is determined that the fourth process control descriptor is consistent with the second process control descriptor, the execution time of the kernel entry function is obtained from the initial process state data, and the execution time of the kernel entry function is determined as the time when the kernel executes the system call.

[0202] S508: Saves the start time of the kernel executing system calls to the pre-generated map memory.

[0203] After determining the start time of the kernel system call, the start time of the kernel system call is saved to the pre-generated map memory.

[0204] S509: When the execution of a kernel export function is traced, obtain the fifth process control character contained in the kernel export function.

[0205] When the execution of a kernel output function is traced, the fifth process control character contained in the kernel output function is obtained.

[0206] S510: Determine whether the fifth process control character is consistent with the second process control character. If yes, execute step S511; otherwise, do nothing.

[0207] After obtaining the fifth process control character contained in the kernel output function, it is determined whether the fifth process control character is consistent with the second process control character. If they are the same, it means that the process currently executing the system call is a critical task process, and step S511 is executed. If not, it means that the process currently executing the system call is not a critical task process, and no action is taken.

[0208] S511: Obtain the execution time of the kernel output function from the initial process state data, and determine the execution time of the kernel output function as the time when the kernel execution system call ends.

[0209] After confirming that the fifth process control descriptor is consistent with the second process control descriptor, the execution time of the kernel output function is obtained from the initial process state data, and the execution time of the kernel output function is determined as the time when the kernel execution system call ends.

[0210] S512: Obtain the start time of the kernel executing system call from the map memory.

[0211] After determining the end time of the kernel system call execution, the start time of the kernel system call execution is obtained from the map memory.

[0212] S513: Calculate the total execution time of the kernel system call based on the end time and start time of the kernel system call, and save the total execution time of the kernel system call to the map memory.

[0213] After determining the end time of the kernel system call and obtaining the start time of the kernel system call, the total execution time of the kernel system call is calculated based on the end time and start time of the kernel system call. That is, the total execution time of the kernel system call is obtained by calculating the difference between the end time and start time of the kernel system call, and the total execution time of the kernel system call is saved to the map memory.

[0214] S514: Returns the total execution time of the kernel system call to the jitter detection module.

[0215] After calculating the total execution time of the kernel system call, the total execution time of the kernel system call is returned to the jitter detection module in the user layer.

[0216] S515: Get the preset kernel system call execution time threshold.

[0217] A kernel system call execution time threshold is preset. After calculating the total execution time of the kernel system call, the preset kernel system call execution time threshold is obtained.

[0218] S516: Compare the total execution time of kernel system calls with the preset kernel system call execution time threshold to obtain the third comparison result.

[0219] After calculating the total execution time of the kernel system call and obtaining the preset kernel system call execution time threshold, the total execution time of the kernel system call is compared with the preset kernel system call execution time threshold to obtain the third comparison result.

[0220] S517: When the third comparison result shows that the total execution time of the kernel system call exceeds the preset kernel system call execution time threshold, it is determined that the critical task process is jittering.

[0221] After obtaining the third comparison result, determine whether the total execution time of the kernel system call exceeds the preset kernel system call execution time threshold. If so, it indicates that the current kernel system call has an impact on the performance of the critical task process, which may cause the critical task process to jitter.

[0222] See Figure 6 , Figure 6 This is another implementation flowchart of the jitter detection method for critical task processes in the operating system according to the embodiments of this application. The method may include the following steps:

[0223] S601: During the operation of the operating system, the jitter detection module sends a start signal to one or more process status parameter monitoring modules, including the kernel call monitoring module, input / output wait monitoring module, cross-inconsistent memory access architecture access monitoring module, and scheduling monitoring module.

[0224] Each process status parameter monitoring module monitors the process status data of its corresponding category.

[0225] S602: When the process status parameter monitoring module includes an input / output wait monitoring module, the input / output wait monitoring module is used to initialize the extended Berkeley packet filter process according to the operating framework of the extended Berkeley packet filter technology of the operating system.

[0226] When the user-level jitter detection module needs to monitor input / output wait times, the process status parameter monitoring module, which includes an input / output wait monitoring module, sends a start signal to the input / output wait monitoring module through the jitter detection module. The input / output wait monitoring module then initializes the extended Berkeley packet filter process according to the operating framework of the operating system's extended Berkeley packet filter technology.

[0227] S603: Tracks the waiting input / output processing functions of the operating system kernel based on the extended Berkeley packet filtering technology.

[0228] After initializing the extended Berkeley packet filter process, the operating system kernel's wait-for-input / output (sched_stat_iowait) function is traced according to the extended Berkeley packet filter technology.

[0229] S604: Obtain the second process control character for the critical task process.

[0230] S605: When the execution of the waiting input / output processing function is traced, obtain the sixth process control character contained in the waiting input / output processing function.

[0231] When the execution of the waiting input / output processing function is traced, the sixth process control character contained in the waiting input / output processing function is obtained.

[0232] S606: Determine whether the sixth process control character is consistent with the second process control character. If yes, proceed to step S607; otherwise, do nothing.

[0233] After obtaining the sixth process control character and the second process control character of the critical task process contained in the waiting input / output processing function, it is determined whether the sixth process control character and the second process control character are consistent. If they are, it means that the process currently waiting for input / output is the preset critical task process, and step S607 is executed. If not, it means that the process currently waiting for input / output is not the preset critical task process, and no processing is performed.

[0234] S607: Obtain the waiting time for input / output from the initial process state data.

[0235] The waiting time for input / output is recorded in advance. When it is determined that the sixth process control character is consistent with the second process control character, it indicates that the process currently waiting for input / output is the preset critical task process. The waiting time for input / output is obtained from the initial process status data.

[0236] S608: Save the time spent waiting for input / output to the pre-generated map memory.

[0237] After obtaining the waiting time for input / output, the waiting time is saved to the pre-generated map memory.

[0238] S609: Return the waiting time for input / output to the jitter detection module.

[0239] After obtaining the waiting time for input / output, the waiting time is returned to the jitter detection module.

[0240] S610: Obtain the preset waiting time threshold for input / output.

[0241] A preset input / output waiting time threshold is set. After obtaining the waiting time for input / output, the preset input / output waiting time threshold is obtained.

[0242] S611: Compare the waiting time for input / output with the preset waiting time threshold to obtain the fourth comparison result.

[0243] After obtaining the waiting time for input / output and the preset waiting time threshold, the waiting time for input / output is compared with the preset waiting time threshold to obtain the fourth comparison result.

[0244] S612: When the fourth comparison result is that the waiting time for input / output exceeds the preset waiting time threshold, it is determined that the critical task process is jittering.

[0245] After obtaining the fourth comparison result, it is determined whether the fourth comparison result indicates that the waiting time for input / output exceeds the preset waiting time threshold. If it is determined that the fourth comparison result indicates that the waiting time for input / output exceeds the preset waiting time threshold, it means that the current waiting time for input / output will affect the performance of the critical task process and will cause the critical task process to jitter.

[0246] See Figure 7 , Figure 7 This is another implementation flowchart of the jitter detection method for critical task processes in the operating system according to the embodiments of this application. The method may include the following steps:

[0247] S701: During the operation of the operating system, the jitter detection module sends a start signal to one or more process status parameter monitoring modules, including the kernel call monitoring module, input / output wait monitoring module, cross-inconsistent memory access architecture access monitoring module, and scheduling monitoring module.

[0248] Each process status parameter monitoring module monitors the process status data of its corresponding category.

[0249] S702: When the process status parameter monitoring module includes a cross-inconsistent memory access architecture monitoring module, the cross-inconsistent memory access architecture monitoring module is used to initialize the extended Berkeley packet filter process according to the operating framework of the operating system extended Berkeley packet filter technology.

[0250] When the user-level jitter detection module needs to monitor memory usage by both local and remote processes, the process status parameter monitoring module, which includes a cross-inconsistent memory access architecture monitoring module, sends a start signal to this module via the jitter detection module. The cross-inconsistent memory access architecture monitoring module then initializes the extended Berkeley packet filter process based on the operating framework of the operating system's extended Berkeley packet filter technology.

[0251] S703: Tracks memory allocation functions of the operating system kernel using extended Berkeley packet filtering technology.

[0252] After initializing the extended Berkeley packet filter process, the operating system kernel's memory allocation function (kmalloc) is traced according to the extended Berkeley packet filter technology.

[0253] S704: Obtain the second process control character for the critical task process.

[0254] S705: When the execution of a memory allocation function is traced, obtain the seventh process control character contained in the memory allocation function.

[0255] When the execution of the memory allocation function is traced, the seventh process control character contained in the memory allocation function is obtained.

[0256] S706: Determine whether the seventh process control character is consistent with the second process control character. If yes, proceed to step S707; otherwise, do nothing.

[0257] After obtaining the seventh process control character and the second process control character of the critical task process contained in the memory allocation function, it is determined whether the seventh process control character and the second process control character are consistent. If they are consistent, it means that the process currently making memory allocation is the preset critical task process, and step S707 is executed. If they are inconsistent, it means that the process currently making memory allocation is not the preset critical task process, and no action is taken.

[0258] S707: Obtain the memory descriptor of the critical task process from the initial process state data.

[0259] When it is determined that the seventh process control character is consistent with the second process control character, it indicates that the process currently requesting memory is the preset critical task process, and the memory descriptor (mm_struct) of the critical task process is obtained from the initial process state data.

[0260] S708: Traverse the virtual memory space in the memory descriptor and obtain the non-consistent memory access architecture node where each virtual memory space is located; wherein, the non-consistent memory access architecture node includes local non-consistent memory access architecture node and remote non-consistent memory access architecture node.

[0261] The memory descriptor contains multiple virtual memory spaces. After obtaining the memory descriptor of the critical task process, the virtual memory spaces in the memory descriptor are traversed, and the non-uniform memory access architecture (numa) node where each virtual memory space is located is obtained, that is, the local non-uniform memory access architecture node or the remote non-uniform memory access architecture node where each virtual memory space is located is obtained.

[0262] S709: Calculate the memory usage of processes in each local non-consistent memory access architecture node to obtain the memory usage of local processes.

[0263] After obtaining the non-consistent memory access architecture node where each virtual memory space is located, the memory used by the processes in each local non-consistent memory access architecture node is counted to obtain the memory used by the local processes.

[0264] S710: Calculate the memory usage of processes in each remote non-consistent memory access architecture node to obtain the memory usage of remote processes.

[0265] After obtaining the non-consistent memory access architecture node where each virtual memory space is located, the memory usage of processes in each remote non-consistent memory access architecture node is counted to obtain the memory usage of remote processes.

[0266] S711: Saves the memory used by the local process and the memory used by the remote process to the map memory.

[0267] After obtaining the memory usage of local processes and remote processes, the memory usage of local processes and remote processes is saved to the map memory.

[0268] S712: Returns the memory usage of the local process and the memory usage of the remote process to the jitter detection module.

[0269] After obtaining the memory usage of local processes and remote processes, the memory usage of local processes and remote processes is returned to the jitter detection module.

[0270] S713: Calculates the percentage of memory used by local processes and the percentage of memory used by remote processes.

[0271] After obtaining the memory usage of local processes and remote processes, calculate the percentage of memory used by local processes and remote processes. For example, you can calculate the percentage of memory used by local processes relative to the memory used by remote processes; or you can calculate the percentage of memory used by remote processes relative to the memory used by local processes; or you can first calculate the sum of memory usage by local processes and remote processes, then calculate the percentage of memory used by local processes relative to the sum of memory usage, and finally calculate the percentage of memory used by remote processes relative to the sum of memory usage.

[0272] S714: Get the preset percentage threshold.

[0273] After calculating the percentage of memory used by local processes and the percentage of memory used by remote processes, a preset percentage threshold is obtained.

[0274] Following the example in step S713, the percentage threshold can be set as a percentage of the memory used by the local process relative to the memory used by the remote process, or as a percentage of the memory used by the remote process relative to the memory used by the local process, or as a percentage of the total memory usage of the local process relative to the total memory usage, or as a percentage of the total memory usage of the remote process relative to the total memory usage. The percentage to be calculated can be adaptively adjusted according to the set percentage threshold.

[0275] S715: Compare the percentage with the preset percentage threshold to obtain the fifth comparison result.

[0276] After calculating the percentage of memory used by local processes and remote processes, and obtaining a preset percentage threshold, the percentages are compared with the preset percentage threshold to obtain the fifth comparison result.

[0277] S716: When the percentage of the fifth comparison result exceeds the preset percentage threshold, it is determined that there is jitter in the critical task process.

[0278] After obtaining the fifth comparison result, determine whether the percentage of the fifth comparison result exceeds the preset percentage threshold. When the percentage of the fifth comparison result exceeds the preset percentage threshold, it means that the percentage of memory used by the current local process and the percentage of memory used by the remote process will affect the performance of the critical task process, which will cause the critical task process to jitter.

[0279] It should be noted that the process control characters (first, second, third, fourth, fifth, sixth, and seventh) do not have any order of importance or sequence; they are only used to distinguish the process control characters of each critical task process and the process control characters contained in each function.

[0280] It should also be noted that the first, second, third, fourth, and fifth comparison results do not have any order of magnitude or sequence; they are only used to distinguish the comparison results between the obtained actual values ​​and the corresponding thresholds.

[0281] Corresponding to the above method embodiments, this application also provides a jitter detection device for critical task processes in an operating system. The jitter detection device for critical task processes in an operating system described below and the jitter detection method for critical task processes in an operating system described above can be referred to in correspondence with each other.

[0282] See Figure 8 , Figure 8 This is a structural block diagram of a jitter detection device for a critical task process in an operating system, as described in an embodiment of this application. The device may include:

[0283] The signal sending unit 81 is used to send a start signal to the process status parameter monitoring modules in the kernel layer through the jitter detection module in the user layer during the operation of the operating system; wherein, each process status parameter monitoring module is a module that monitors the process status data of its corresponding category.

[0284] The data collection unit 82 is used to collect the process status data of each corresponding category by using the process status parameter monitoring module after startup to obtain the initial process status data.

[0285] The identification information acquisition unit 83 is used to acquire the target identification information of the preset key task process to be detected.

[0286] The data filtering unit 84 is used to filter the target process status data corresponding to the key task process from each initial process status data according to the target identification information, and return the target process status data to the jitter detection module.

[0287] The jitter detection unit 85 is used to perform jitter detection on the critical task process based on the target process status data using the jitter detection module.

[0288] As described above, the technical solution involves deploying a jitter detection module at the user layer of the operating system and process status parameter monitoring modules at the kernel layer. During operating system operation, the jitter detection module in the user layer sends a start signal to the process status parameter monitoring modules in the kernel layer. Once started, each process status parameter monitoring module collects process status data for its corresponding category, obtaining initial process status data. Based on the target identifier information of the critical task process to be detected, the system filters the target process status data corresponding to the critical task process from the initial process status data and returns this target process status data to the jitter detection module. The jitter detection module then performs jitter detection on the critical task process based on the target process status data, thereby determining the interference of a specified interference source on the process. This provides effective information for development or maintenance personnel, facilitating timely implementation of corresponding measures to ensure the operation of critical processes. Compared to manually analyzing the causes of task process jitter, this method significantly reduces time consumption and complexity, improving the efficiency and accuracy of analyzing the causes of task process jitter.

[0289] In one specific embodiment of this application, the signal sending unit 81 is specifically a unit that sends a start signal to one or more process status parameter monitoring modules among the kernel call monitoring module, input / output wait monitoring module, cross-inconsistent memory access architecture access monitoring module, and scheduling monitoring module through the jitter detection module during the operation of the operating system.

[0290] In one specific embodiment of this application, the data collection unit 82 is specifically a unit that uses extended Berkeley packet filtering technology to track the key functions corresponding to the process state parameter monitoring modules in the operating system kernel.

[0291] In one specific embodiment of this application, the data collection unit 82 includes:

[0292] The first initialization subunit is used to initialize the extended Berkeley packet filter process by utilizing the scheduling monitoring module according to the operating framework of the extended Berkeley packet filter technology of the operating system when the process state parameter monitoring module includes the scheduling monitoring module.

[0293] The first function tracing subunit is used to trace the process wake-up functions and process switching functions of the operating system kernel based on the extended Berkeley packet filtering technology;

[0294] The identification information acquisition unit 83 is specifically a unit for acquiring the second process control character of the critical task process;

[0295] Data filtering unit 84 includes:

[0296] The first control character acquisition subunit is used to acquire the first process control character contained in the process wake-up function when the execution of the process wake-up function is traced.

[0297] The first judgment subunit is used to determine whether the first process control character and the second process control character are consistent.

[0298] The process wake-up time determination subunit is used to obtain the execution time of the process wake-up function from each initial process state data when it is determined that the first process control character and the second process control character are consistent, and to determine the execution time of the process wake-up function as the process wake-up time.

[0299] The process wake-up time saving subunit is used to save the process wake-up time to the pre-generated map memory;

[0300] The second control character acquisition subunit is used to acquire the third process control character contained in the process switching function when the execution of the process switching function is traced.

[0301] The second judgment subunit is used to determine whether the third process control character is consistent with the second process control character;

[0302] The scheduling time determination subunit is used to obtain the execution time of the process switching function from each initial process state data when it is determined that the third process control descriptor is consistent with the second process control descriptor, and to determine the execution time of the process switching function as the time for the critical task process to be scheduled to the central processing unit.

[0303] The process wake-up time determination subunit is used to obtain the process wake-up time from the map memory;

[0304] The scheduling delay calculation subunit is used to calculate the process scheduling delay based on the process wake-up time and the time when the critical task process is scheduled to the central processing unit.

[0305] The scheduling count statistics subunit is used to increment the process scheduling count by 1 and count the number of times the critical task process is scheduled between different central processing units.

[0306] The latency and count storage subunit is used to save the process scheduling latency and scheduling count to the map memory;

[0307] The latency and count return subunit is used to return the process scheduling latency and scheduling count to the jitter detection module;

[0308] The jitter detection unit 85 includes:

[0309] The delay threshold and number threshold acquisition subunit is used to acquire the preset scheduling delay threshold and the preset scheduling number threshold;

[0310] The first comparison subunit is used to compare the process scheduling delay with a preset scheduling delay threshold to obtain the first comparison result;

[0311] The second comparison subunit is used to compare the number of scheduling attempts with a preset scheduling attempt threshold to obtain a second comparison result;

[0312] The first jitter determination subunit is used to determine that there is jitter in the critical task process when the first comparison result is that the process scheduling delay exceeds the preset scheduling delay threshold and / or the second comparison result is that the scheduling number exceeds the preset scheduling number threshold.

[0313] In one specific embodiment of this application, the data collection unit 82 includes:

[0314] The second initialization subunit is used to initialize the extended Berkeley packet filter process using the kernel call monitoring module according to the operating framework of the extended Berkeley packet filter technology of the operating system when the process state parameter monitoring module includes the kernel call monitoring module.

[0315] The kernel input / output function tracing subunit is used to trace the kernel entry and output functions of the operating system kernel using extended Berkeley packet filtering technology;

[0316] The identification information acquisition unit is specifically a unit that acquires the second process control character of the critical task process;

[0317] Data filtering unit 84 includes:

[0318] The third control character acquisition subunit is used to acquire the fourth process control character contained in the kernel entry function when the execution of the kernel entry function is traced.

[0319] The third judgment subunit is used to determine whether the fourth process control character is consistent with the second process control character;

[0320] The system call start time determination subunit is used to obtain the execution time of the kernel entry function from the initial process state data when it is determined that the fourth process control character is consistent with the second process control character, and determine the execution time of the kernel entry function as the start time of the kernel system call execution.

[0321] The system call start time saving subunit is used to save the start time of the kernel executing the system call to the pre-generated map memory;

[0322] The fourth control character acquisition subunit is used to acquire the fifth process control character contained in the kernel output function when the execution of the kernel output function is traced.

[0323] The fourth judgment subunit is used to determine whether the fifth process control character is consistent with the second process control character;

[0324] The execution system call end time determination subunit is used to obtain the execution time of the kernel output function from the initial process state data when it is determined that the fifth process control character is consistent with the second process control character, and determine the execution time of the kernel output function as the end time of the kernel execution system call;

[0325] The system call start time acquisition sub-unit is used to obtain the start time of the kernel system call execution from the map memory;

[0326] The system call total execution time storage subunit is used to calculate the total execution time of the kernel system call based on the end time and start time of the kernel system call execution, and save the total execution time of the kernel system call to the map memory;

[0327] The total execution time return subunit is used to return the total execution time of the kernel system calls to the jitter detection module;

[0328] The jitter detection unit 85 includes:

[0329] The system call execution time threshold acquisition subunit is used to acquire the preset kernel system call execution time threshold;

[0330] The third comparison subunit is used to compare the total execution time of the kernel system call with the preset kernel system call execution time threshold to obtain the third comparison result;

[0331] The second jitter determination subunit is used to determine that there is jitter in the critical task process when the third comparison result is that the total execution time of the kernel system call exceeds the preset kernel system call execution time threshold.

[0332] In one specific embodiment of this application, the data collection unit 82 includes:

[0333] The third initialization subunit is used to initialize the extended Berkeley packet filter process by utilizing the input / output waiting monitoring module according to the operating framework of the extended Berkeley packet filter technology of the operating system when the process status parameter monitoring module includes an input / output waiting monitoring module.

[0334] The I / O wait function tracking subunit is used to track the I / O wait functions of the operating system kernel using extended Berkeley packet filtering technology;

[0335] The identification information acquisition unit is specifically a unit that acquires the second process control character of the critical task process;

[0336] Data filtering unit 84 includes:

[0337] The fifth control character acquisition subunit is used to acquire the sixth process control character contained in the waiting input / output processing function when the execution of the waiting input / output processing function is traced.

[0338] The fifth judgment subunit is used to determine whether the sixth process control character is consistent with the second process control character;

[0339] The input / output waiting time acquisition subunit is used to acquire the input / output waiting time from each initial process state data when it is determined that the sixth process control character is consistent with the second process control character.

[0340] The input / output waiting time storage subunit is used to save the waiting time for input / output to the pre-generated map memory;

[0341] The input / output time return subunit is used to return the input / output time to the jitter detection module.

[0342] The jitter detection unit 85 includes:

[0343] The waiting input / output time threshold acquisition subunit is used to acquire the preset waiting input / output time threshold;

[0344] The fourth comparison subunit is used to compare the waiting time for input / output with a preset waiting time threshold to obtain the fourth comparison result;

[0345] The third jitter determination subunit is used to determine that there is jitter in the critical task process when the fourth comparison result is that the waiting time for input / output exceeds the preset waiting time threshold.

[0346] In one specific embodiment of this application, the data collection unit 82 includes:

[0347] The fourth initialization subunit is used to initialize the extended Berkeley packet filter process using the cross-inconsistent memory access architecture access monitoring module, when the process state parameter monitoring module includes the cross-inconsistent memory access architecture access monitoring module, based on the operating framework of the extended Berkeley packet filter technology of the operating system.

[0348] The memory allocation function tracing subunit is used to trace the operating system kernel's memory allocation functions based on the extended Berkeley packet filtering technology;

[0349] The identification information acquisition unit is specifically a unit that acquires the second process control character of the critical task process;

[0350] Data filtering unit 84 includes:

[0351] The sixth control character acquisition subunit is used to retrieve the seventh process control character contained in the memory allocation function when the execution of the memory allocation function is traced.

[0352] The sixth judgment subunit is used to determine whether the seventh process control character is consistent with the second process control character;

[0353] The memory descriptor acquisition subunit is used to retrieve the memory descriptor of the critical task process from the initial process state data when it is determined that the seventh process control character is consistent with the second process control character.

[0354] The Inconsistent Memory Access Architecture Node Acquisition Sub-unit is used to traverse the virtual memory space in the memory descriptor and obtain the Inconsistent Memory Access Architecture Node where each virtual memory space is located; wherein, the Inconsistent Memory Access Architecture Node includes local Inconsistent Memory Access Architecture Node and remote Inconsistent Memory Access Architecture Node.

[0355] The local process memory statistics subunit is used to count the memory used by processes in each local non-consistent memory access architecture node, and to obtain the memory used by local processes.

[0356] The remote process memory statistics subunit is used to count the memory used by processes in each remote non-consistent memory access architecture node, and to obtain the memory used by remote processes.

[0357] Use a memory storage subunit to save the memory used by the local process and the memory used by the remote process into the map memory;

[0358] The memory return subunit is used to return the memory usage of the local process and the memory usage of the remote process to the jitter detection module.

[0359] The jitter detection unit 85 includes:

[0360] The percentage calculation subunit is used to calculate the percentage of memory used by local processes and the percentage of memory used by remote processes;

[0361] The percentage threshold acquisition sub-unit is used to acquire a preset percentage threshold.

[0362] The fifth comparison subunit is used to compare the percentage with a preset percentage threshold to obtain the fifth comparison result;

[0363] The fourth jitter determination subunit is used to determine that there is jitter in the critical task process when the percentage of the fifth comparison result exceeds the preset percentage threshold.

[0364] For the method embodiments described above, see [link to relevant documentation]. Figure 9 , Figure 9 This is a schematic diagram of a jitter detection device for mission-critical processes in an operating system provided in this application. The device may include:

[0365] Memory 332 is used to store computer programs;

[0366] The processor 322 is used to implement the steps of the jitter detection method for critical task processes in the operating system of the above method embodiment when executing a computer program.

[0367] For details, please refer to Figure 10 , Figure 10 This embodiment provides a schematic diagram of the specific structure of a jitter detection device for a critical task process in an operating system. The jitter detection device for a critical task process in the operating system can vary significantly due to different configurations or performance. It may include a processor (central processing unit, CPU) 322 (e.g., one or more processors) and a memory 332. The memory 332 stores one or more computer programs 342 or data 344. The memory 332 can be temporary or persistent storage. The program stored in the memory 332 may include one or more modules (not shown in the diagram), each module may include a series of instruction operations on the data processing device. Furthermore, the processor 322 may be configured to communicate with the memory 332 and execute the series of instruction operations stored in the memory 332 on the jitter detection device 301 for the critical task process in the operating system.

[0368] The jitter detection device 301 for critical task processes in the operating system may also include one or more power supplies 326, one or more wired or wireless network interfaces 350, one or more input / output interfaces 358, and / or one or more operating systems 341.

[0369] The steps in the jitter detection method for critical task processes in the operating system described above can be implemented by the structure of the jitter detection device for critical task processes in the operating system.

[0370] Corresponding to the above method embodiments, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can perform the following steps:

[0371] During operating system operation, the jitter detection module in the user layer sends a start signal to the process status parameter monitoring modules in the kernel layer. Each process status parameter monitoring module monitors process status data for its corresponding category. Once started, each process status parameter monitoring module collects process status data for its respective category to obtain initial process status data. It then acquires target identifier information for a preset critical task process to be detected. Based on the target identifier information, it filters the target process status data corresponding to the critical task process from the initial process status data and returns the target process status data to the jitter detection module. Finally, the jitter detection module performs jitter detection on the critical task process based on the target process status data.

[0372] The computer-readable storage medium may include various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0373] For a description of the computer-readable storage medium provided in this application, please refer to the above method embodiments; further details will not be repeated here.

[0374] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatuses, devices, and computer-readable storage media disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant parts can be referred to the method section.

[0375] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the technical solutions and core ideas of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A method for detecting jitter in critical task processes of an operating system, characterized in that, Comprise: In the process of operating system running, send start signal to each process state parameter monitoring module in kernel layer through jitter detection module in user layer; wherein, each process state parameter monitoring module is a module for monitoring process state data of corresponding category respectively; Collect process state data of corresponding category of each process state parameter monitoring module respectively to obtain each initial process state data; Obtain target identification information of preset key task process to be detected; According to the target identification information, filter target process state data corresponding to the key task process from each initial process state data, and return the target process state data to the jitter detection module; Use the jitter detection module to detect the key task process according to the target process state data; Wherein, in the process of operating system running, send start signal to each process state parameter monitoring module in kernel layer through jitter detection module in user layer, comprising: In the process of operating system running, send start signal to one or more process state parameter monitoring modules in kernel call monitoring module, input output waiting monitoring module, cross non-coherent memory access architecture access monitoring module and scheduling monitoring module through the jitter detection module; Collect process state data of corresponding category of each process state parameter monitoring module respectively, comprising: Use extended Berkeley packet filter technology to track key functions corresponding to each process state parameter monitoring module in operating system kernel respectively; Wherein, when the process state parameter monitoring module contains the scheduling monitoring module, the key function is process wake-up function and process switching function; when the process state parameter monitoring module contains the kernel call monitoring module, the key function is kernel entry function and kernel output function; when the process state parameter monitoring module contains the input output waiting monitoring module, the key function is waiting input output processing function; when the process state parameter monitoring module contains the cross non-coherent memory access architecture access monitoring module, the key function is memory application function.

2. The method of claim 1, wherein the method further comprises: When the process state parameter monitoring module contains the scheduling monitoring module, use extended Berkeley packet filter technology to track key functions corresponding to each process state parameter monitoring module in operating system kernel respectively, comprising: Use the scheduling monitoring module to initialize extended Berkeley packet filter process according to the operation framework of extended Berkeley packet filter technology in operating system; According to the extended Berkeley packet filter technology, track process wake-up function and process switching function of operating system kernel; Correspondingly, obtaining target identification information of preset key task process to be detected, comprising: Obtain the second process control symbol of the key task process; Accordingly, the target process state data corresponding to the key task process is screened from each of the initial process state data according to the target identification information, and the target process state data is returned to the jitter detection module, including: When the process wakeup function execution is tracked, a first process control symbol contained in the process wakeup function is acquired; It is judged whether the first process control symbol is consistent with the second process control symbol; If yes, the execution time of the process wakeup function is acquired from each of the initial process state data, and the execution time of the process wakeup function is determined as the process wakeup time; The process wakeup time is saved to the pre-generated map memory; When the process switching function execution is tracked, a third process control symbol contained in the process switching function is acquired; It is judged whether the third process control symbol is consistent with the second process control symbol; If yes, the execution time of the process switching function is acquired from each of the initial process state data, and the execution time of the process switching function is determined as the time when the key task process is scheduled to the central processing unit; The process wakeup time is acquired from the map memory; The process scheduling delay is calculated according to the process wakeup time and the time when the key task process is scheduled to the central processing unit; The scheduling number of the process is added by 1, and the scheduling number of the key task process between different central processing units is counted; The process scheduling delay and the scheduling number are saved to the map memory; The process scheduling delay and the scheduling number are returned to the jitter detection module; Accordingly, the jitter detection module is used to detect the jitter of the key task process according to the target process state data, including: A preset scheduling delay threshold and a preset scheduling number threshold are acquired; The process scheduling delay is compared with the preset scheduling delay threshold, and a first comparison result is obtained; The scheduling number is compared with the preset scheduling number threshold, and a second comparison result is obtained; When the first comparison result is that the process scheduling delay exceeds the preset scheduling delay threshold and / or the second comparison result is that the scheduling number exceeds the preset scheduling number threshold, it is determined that the key task process has jitter.

3. The method of claim 1, wherein the method further comprises: When the process state parameter monitoring module contains the kernel call monitoring module, each key function corresponding to the process state parameter monitoring module in the operating system kernel is tracked by using the extended Berkeley packet filter technology, including: The kernel call monitoring module is used to initialize the extended Berkeley packet filter process according to the operation framework of the extended Berkeley packet filter technology in the operating system; The kernel entry function and the kernel output function of the operating system kernel are tracked according to the extended Berkeley packet filter technology; Accordingly, the target identification information of the preset key task process to be detected is acquired, including: The second process control symbol of the key task process is acquired; Accordingly, the target process state data corresponding to the key task process is screened from the initial process state data according to the target identification information, and the target process state data is returned to the jitter detection module, including: When the kernel entry function execution is tracked, a fourth process control symbol contained in the kernel entry function is acquired; It is judged whether the fourth process control symbol is consistent with the second process control symbol; If yes, the execution time of the kernel entry function is acquired from each initial process state data, and the execution time of the kernel entry function is determined as the time when the kernel executes the system call; The time when the kernel executes the system call is saved to the pre-generated map memory; When the kernel output function execution is tracked, a fifth process control symbol contained in the kernel output function is acquired; It is judged whether the fifth process control symbol is consistent with the second process control symbol; If yes, the execution time of the kernel output function is acquired from each initial process state data, and the execution time of the kernel output function is determined as the time when the kernel executes the system call; The time when the kernel executes the system call is acquired from the map memory; The total execution time of the kernel system call is calculated according to the time when the kernel executes the system call and the time when the kernel executes the system call, and the total execution time of the kernel system call is saved to the map memory; The total execution time of the kernel system call is returned to the jitter detection module; Accordingly, the jitter detection module is used to detect the jitter of the key task process according to the target process state data, including: A preset kernel system call execution time threshold is acquired; The total execution time of the kernel system call is compared with the preset kernel system call execution time threshold to obtain a third comparison result; When the third comparison result is that the total execution time of the kernel system call exceeds the preset kernel system call execution time threshold, it is determined that the key task process has jitter.

4. The method of jitter detection of a critical task process in an operating system according to claim 1, wherein, When the process state parameter monitoring module contains the input and output waiting monitoring module, each key function corresponding to the process state parameter monitoring module in the operating system kernel is tracked by using the extended Berkeley packet filter technology, including: The input and output waiting monitoring module is initialized according to the operation framework of the extended Berkeley packet filter technology in the operating system; The waiting input and output processing function of the operating system kernel is tracked according to the extended Berkeley packet filter technology; Accordingly, the target identification information of the preset key task process to be detected is acquired, including: The second process control symbol of the key task process is acquired; Accordingly, the target process state data corresponding to the key task process is screened from the initial process state data according to the target identification information, and the target process state data is returned to the jitter detection module, including: When the waiting input / output processing function execution is tracked, a sixth process control symbol contained in the waiting input / output processing function is acquired; It is judged whether the sixth process control symbol is consistent with the second process control symbol; If yes, the waiting input / output time is acquired from each of the initial process state data; The waiting input / output time is saved to the pre-generated map memory; The waiting input / output time is returned to the jitter detection module; Correspondingly, the jitter detection module is used to perform jitter detection on the key task process according to the target process state data, comprising: A preset waiting input / output time threshold is acquired; The waiting input / output time is compared with the preset waiting input / output time threshold to obtain a fourth comparison result; When the fourth comparison result is that the waiting input / output time exceeds the preset waiting input / output time threshold, it is determined that the key task process exists jitter.

5. The method of claim 1, wherein the method further comprises: When the process state parameter monitoring module contains the cross-non-coherent memory access architecture access monitoring module, each key function corresponding to the process state parameter monitoring module in the operating system kernel is tracked by using the extended Berkeley packet filter technology, comprising: The cross-non-coherent memory access architecture access monitoring module is initialized according to the operation framework of the extended Berkeley packet filter technology in the operating system; The memory application function of the operating system kernel is tracked according to the extended Berkeley packet filter technology; Correspondingly, the target identification information of the preset key task process to be detected is acquired, comprising: The second process control symbol of the key task process is acquired; Correspondingly, the target process state data corresponding to the key task process is screened from each of the initial process state data according to the target identification information, and the target process state data is returned to the jitter detection module, comprising: When the memory application function execution is tracked, a seventh process control symbol contained in the memory application function is acquired; It is judged whether the seventh process control symbol is consistent with the second process control symbol; If yes, the memory descriptor of the key task process is acquired from each of the initial process state data; The virtual memory space in the memory descriptor is traversed, and each virtual memory space is located in a non-coherent memory access architecture node; wherein the non-coherent memory access architecture node comprises a local non-coherent memory access architecture node and a remote non-coherent memory access architecture node; The process used memory in each of the local non-coherent memory access architecture nodes is counted to obtain the local process used memory; The process used memory in each of the remote non-coherent memory access architecture nodes is counted to obtain the remote process used memory; The local process used memory and the remote process used memory are saved to the map memory; The local process used memory and the remote process used memory are returned to the jitter detection module; Correspondingly, the jitter detection module is utilized to detect jitter of the critical task process according to the target process state data, including: calculating the percentage of the local process used memory and the remote process used memory; acquiring a preset percentage threshold; comparing the percentage with the preset percentage threshold to obtain a fifth comparison result; when the fifth comparison result is that the percentage exceeds the preset percentage threshold, it is determined that the critical task process has jitter.

6. A jitter detection device for critical task processes in an operating system, characterized in that, including: a signal sending unit, configured to send a start signal to each process state parameter monitoring module in a kernel layer through a jitter detection module in a user layer during operation of an operating system; each process state parameter monitoring module is a module for monitoring process state data of a corresponding category; a data collection unit, configured to collect process state data of a corresponding category by each process state parameter monitoring module that has completed starting to obtain each initial process state data; an identification information acquisition unit, configured to acquire target identification information of a preset critical task process to be detected; a data screening unit, configured to screen target process state data corresponding to the critical task process from each initial process state data according to the target identification information, and return the target process state data to the jitter detection module; a jitter detection unit, configured to detect jitter of the critical task process according to the target process state data by the jitter detection module; the signal sending unit is specifically a unit for sending a start signal to one or more process state parameter monitoring modules in a kernel call monitoring module, an input / output waiting monitoring module, a non-coherent memory access architecture access monitoring module, and a scheduling monitoring module through a jitter detection module during operation of an operating system; the data collection unit is specifically a unit for tracking a key function corresponding to each process state parameter monitoring module in an operating system kernel by using an extended Berkeley packet filter technology; when the process state parameter monitoring module includes the scheduling monitoring module, the key function is a process wake-up function and a process switching function; when the process state parameter monitoring module includes the kernel call monitoring module, the key function is a kernel entry function and a kernel output function; when the process state parameter monitoring module includes the input / output waiting monitoring module, the key function is a waiting input / output processing function; and when the process state parameter monitoring module includes the non-coherent memory access architecture access monitoring module, the key function is a memory application function.

7. A jitter detection device for critical task processes in an operating system, characterized in that, including: a memory, configured to store a computer program; a processor, configured to implement the steps of the jitter detection method of the critical task process in the operating system according to any one of claims 1 to 5 when the computer program is executed.

8. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the steps of the jitter detection method of the critical task process in the operating system according to any one of claims 1 to 5.

Images