Method and system for detecting and diagnosing abnormal calling of linux system timer

Abstract

The invention discloses a method and a system for detecting and diagnosing abnormal calling of timers of a linux system. The method comprises the following steps of: respectively acquiring running time and calling times of a callback function of each timer; matching and calling a kernel function operated by the timer according to the callback function; if both the callback function and the kernel function for calling the timer to run are within the kernel code range of the module required for running the test scene, the timer call is invalid call; if the running time and the calling frequency of the callback function both meet the judgment rule of the abnormal high-frequency calling, the timer calling is the abnormal high-frequency calling; and if the timer call is invalid call or abnormal high-frequency call, obtaining call times of each category in a kernel function running by calling the timer, determining an abnormal category according to the call times, and diagnosing a reason for abnormal call of the timer according to information of the abnormal category. According to the method, abnormal calling can be directly judged, the cause of abnormal calling can be indicated, and the detection and diagnosis efficiency is improved.

Description

Technical Field

[0001] The present invention relates to an abnormality detection technology for operating system timers, and in particular to a detection and diagnosis method and system for abnormal call of a timer in a Linux system. Background Art

[0002] In the context of improving energy efficiency, in order to save power consumption, it is hoped that the CPU will be in an idle state for a long time; and the CPU in the idle state is awakened by an interrupt. In many systems, the frequency of timer event interrupts is usually two orders of magnitude higher than any other interrupts or even more, so they may be the main reason for the CPU to wake up from the idle state. In addition, in some scenarios such as high-performance computing, interrupts should be avoided as much as possible; this is mainly because the interrupt mechanism may have a negative impact on the performance of parallel computing; timer event interrupts are a common type of interrupt in these scenarios. Obviously, after the timer is called abnormally, it will have a very large impact on the energy saving and performance effects of the system.

[0003] However, it is difficult to detect and diagnose abnormal timer calls. Currently, many performance and power optimization tools such as perf and powertop cannot directly determine abnormal calls and indicate the causes of abnormal calls. They only present relevant probe point data, and then experienced system and R&D personnel continue to analyze and add more debugging methods to find possible abnormal points and causes.

[0004] It is obvious that the current technical solutions cannot meet the needs of practical applications, and a more efficient detection and diagnosis method for abnormal timer calls is urgently needed. Summary of the invention

[0005] The technical problem to be solved by the present invention is as follows: In view of the above-mentioned problems in the prior art, a method and system for detecting and diagnosing abnormal calls of a Linux system timer is provided, which can directly determine the abnormal calls and indicate the causes of the abnormal calls, thereby improving the detection and diagnosis efficiency.

[0006] In order to solve the above technical problems, the technical solution adopted by the present invention is:

[0007] A method for detecting and diagnosing abnormal calls of a timer in a Linux system comprises the following steps:

[0008] Get the running time and calling times of each timer's callback function respectively;

[0009] According to the callback function match, call the kernel function running on the corresponding timer;

[0010] Determine whether the callback function and the kernel function that calls the corresponding timer are both within the kernel code range of the module required for the test scenario to run, otherwise the corresponding timer call is an invalid call;

[0011] Determine whether the running time and calling times of the callback function meet the judgment rule of abnormally high frequency calling, if yes, the corresponding timer calling is abnormally high frequency calling;

[0012] If the corresponding timer call is an invalid call or an abnormally high-frequency call, obtain the number of calls of each category in the kernel function that calls the corresponding timer, determine the exception category based on the number of calls, and diagnose the cause of the abnormal timer call based on the information of the exception category.

[0013] Further, when respectively obtaining the running time and calling times of the callback function of each timer, the following steps are included:

[0014] Insert a probe into the tracepoint point where the callback function starts, obtain the CPU number and the function pointer value in real time through the probe, and obtain the corresponding first system time, combine the CPU number and the function pointer value as the key in a key-value pair, use the corresponding first system time as the value in the key-value pair, and store the key-value pair in the first hash map;

[0015] Insert a probe into the tracepoint where the callback function ends, obtain the CPU number and function pointer value in real time through the probe, and obtain the corresponding second system time, combine the CPU number and function pointer value and match the first hash map, if there is a match, calculate the time difference between the second system time and the matched first system time, and use the time difference to update the running time corresponding to the callback function, and update and save the number of calls corresponding to the callback function.

[0016] Furthermore, updating the running time corresponding to the callback function with the time difference is specifically to add the corresponding value of the key whose key value is the function pointer value in the second hash map to the time difference as the updated running time; updating and saving the number of calls corresponding to the callback function is specifically to add one to the corresponding value of the key whose key value is the function pointer value in the third hash map as the updated number of calls.

[0017] Furthermore, after calculating the time difference between the second system time and the matched first system time, the method further includes: storing the function pointer value and the corresponding time difference in a histogram map to count the hit numbers of different callback functions in different running time intervals.

[0018] Further, when the kernel function corresponding to the timer is called according to the callback function match, it includes:

[0019] Use regular expression matching according to the name of the callback function to obtain the code segment when the callback function in the corresponding timer is initialized;

[0020] Target information is extracted from the code segment. If the code segment that calls the start of the corresponding timer is matched based on the target information and the corresponding timer start function API function field characteristics, the function containing the code segment that calls the start of the corresponding timer will be used as the kernel function that calls the corresponding timer to run. The target information includes the parent structure information of the corresponding timer and the corresponding parameter naming.

[0021] Further, judging whether the running time and calling times of the callback function satisfy the judgment rule of abnormally high frequency calling includes:

[0022] If the running time of the current callback function is greater than the preset running time threshold, and the number of calls of the current callback function is greater than the preset call number threshold, then the running time and the number of calls of the current callback function both meet the judgment rule of abnormally high frequency calls;

[0023] Alternatively, the performance index and energy-saving index of the current callback function are calculated according to the running time and the number of calls of the current callback function. If the performance index of the current callback function is greater than a preset performance index threshold, and the energy-saving index of the current callback function is greater than a preset energy-saving index threshold, then the running time and the number of calls of the current callback function both meet the judgment rule of abnormally high frequency calls;

[0024] Alternatively, if the running time and calling number of the current callback function are much greater than the running time and calling number of other callback functions, then the running time and calling number of the current callback function both meet the judgment rules of abnormally high-frequency calls. The running time and calling number of the current callback function are much greater than the running time and calling number of other callback functions, specifically means that the running time and calling number of the current callback function are greater than the sum of the running time and the sum of the calling number of other callback functions, or the difference between the running time and calling number of the current callback function and the running time and calling number of other callback functions is greater than the preset first difference threshold.

[0025] Furthermore, the expressions of the performance index and energy saving index are as follows:

[0026] P=Perf_t×t+Perf_c×c

[0027] E=E_t×t+E_c×c

[0028] Among them, P represents the performance index, E represents the energy saving index, Perf_t represents the parameter affecting the performance due to the running time, Perf_c represents the parameter affecting the performance due to the number of calls, E_t represents the parameter affecting the power consumption due to the running time, E_c represents the parameter affecting the power consumption due to the number of calls, t represents the running time of the callback function, and c represents the number of calls of the callback function.

[0029] Furthermore, when determining the exception category based on the number of calls, it includes:

[0030] If the number of calls of the current category is greater than the preset call number threshold, the current category is an abnormal category;

[0031] Alternatively, the mean or standard deviation of the number of calls of all categories is calculated, and if the number of calls of the current category is greater than a specified multiple of the mean or standard deviation, the current category is an abnormal category;

[0032] Alternatively, if the number of calls of the current category is much greater than the number of calls of other categories, the current category is an abnormal category. The number of calls of the current category is much greater than the number of calls of other categories, which specifically means that the number of calls of the current category is greater than the sum of the number of calls of other categories or the difference between the number of calls of the current category and the number of calls of other categories is greater than the preset second difference threshold.

[0033] Furthermore, the cause of the timer abnormal call is diagnosed based on the abnormal category information, including:

[0034] If the bottom of the stack information of the exception category is a syscall call, the out-of-core exception application is located based on the process ID, parent process ID, and process name string of the exception category;

[0035] If the bottom of the stack information of the exception category is not a syscall call, the abnormal kernel module is located by combining the kernel source code and the stack information of the exception category.

[0036] The present invention also proposes a detection and diagnosis system for abnormal call of a timer in a Linux system, comprising a microprocessor and a computer-readable storage medium connected to each other, wherein the microprocessor is programmed or configured to execute any one of the detection and diagnosis methods for abnormal call of a timer in a Linux system.

[0037] Compared with the prior art, the advantages of the present invention are:

[0038] The present invention analyzes the callback function of the timer, obtains the running time and the number of calls of the callback function and uses this to determine whether the timer is called with abnormally high frequency. At the same time, the kernel function that calls the timer is matched according to the callback function. By determining whether the callback function and the kernel function that calls the timer are both within the kernel code range of the module required for the test scenario to run, it is determined whether the timer is an invalid call, thereby realizing automatic judgment of invalid and abnormal timer calls.

[0039] After determining that the timer call is an invalid call or an abnormally high-frequency call, the present invention determines the specific exception category by the number of calls of each category in the kernel function that calls the timer, and further diagnoses the cause of the abnormal timer call based on the information of the exception category. Compared with manual analysis and diagnosis, the efficiency of detecting and diagnosing abnormal timer calls is significantly improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 is a flow chart of an embodiment of the present invention.

[0041] Figure 2 This is a flowchart for obtaining the running time and calling times of a callback function in an embodiment of the present invention.

[0042] Figure 3 This is a flowchart of searching for a kernel function that calls a timer to run in an embodiment of the present invention.

[0043] Figure 4 The figure is a flow chart of determining invalid calls in an embodiment of the present invention.

[0044] Figure 5 The flowchart of determining abnormally high frequency calls in an embodiment of the present invention. DETAILED DESCRIPTION

[0045] The present invention is further described below in conjunction with the accompanying drawings and specific preferred embodiments, but the protection scope of the present invention is not limited thereby.

[0046] Embodiment 1

[0047] This embodiment proposes a method for detecting and diagnosing abnormal timer calls in a Linux system, which can significantly improve the efficiency of detecting and diagnosing abnormal timer calls and provide an optimization basis for solving system power consumption and performance problems caused by abnormal timer calls. Figure 1 As shown, the following steps are included:

[0048] S1) respectively obtain the running time and calling number of the callback function of each timer;

[0049] S2) calling the kernel function corresponding to the timer according to the callback function matching;

[0050] S3) Determine whether the timer call is an invalid call by combining the affiliation of the module required for the test scenario operation and the callback function and the kernel function that calls the corresponding timer operation, specifically, determine whether the callback function and the kernel function that calls the corresponding timer operation are both within the kernel code range of the module required for the test scenario operation. If so, the corresponding timer call is a valid call, and step S4 is executed; otherwise, the corresponding timer call is an invalid call, and step S5 is jumped;

[0051] S4) judging whether the timer call is an abnormally high-frequency call based on the running time and the number of calls of the callback function, specifically judging whether the running time and the number of calls of the callback function meet the judgment rule of abnormally high-frequency calls, if so, the corresponding timer call is an abnormally high-frequency call, and executing step S5, otherwise, the corresponding timer call is a non-abnormally high-frequency call, and the process ends and exits;

[0052] S5) if the corresponding timer call is an invalid call or an abnormally high frequency call, obtain the number of calls of each category in the kernel function that calls the corresponding timer to run, and determine the abnormal category according to the number of calls;

[0053] S6) Diagnose the cause of the timer abnormal call based on the information of the abnormal category.

[0054] Through the above steps, it is possible to automatically determine whether the timer call is an abnormal call, and automatically indicate the cause of the abnormal call when it is determined to be an abnormal call, thereby improving the efficiency of detection and diagnosis of abnormal timer calls. Each step is described in detail below.

[0055] Step S1 of this embodiment specifically obtains the running time and calling times of each callback function by inserting a probe into the tracepoint of the kernel recording the start and end of the timer callback function, such as Figure 2 As shown, the following steps are included:

[0056] S11) defining a hash map named start, called the first hash map, wherein the key key in the key-value pair of the first hash map start consists of a CPU number and a function pointer; defining a hash map named timer_exprit and a hash map named timer_count, called the second hash map and the third hash map, to store the running time and call count data of each callback function, wherein the key key in the key-value pair of the second hash map timer_exprit and the third hash map timer_count are both function pointers; in addition, defining a histogram map named hdisk;

[0057] S12) insert a probe into the tracepoint where the callback function starts, such as Figure 1As shown, when the probe is running, the CPU number and the function pointer value fun provided by the tracepoint are obtained at this time, and the system time nsecs at this time are obtained at the same time, so that the CPU number and the function pointer value can be obtained in real time through the inserted probe, and the system time when the callback function starts can be obtained, which is called the first system time in this embodiment;

[0058] Combine the CPU number and the function pointer value as the key in the key-value pair, use the corresponding first system time as the value in the key-value pair, and store the key-value pair in the first hash map start;

[0059] S13) insert a probe into the tracepoint where the callback function ends, such as Figure 1 As shown, when the probe is running, the timer pointer address is obtained according to the kernel version and the function pointer value is obtained according to the data pointed to by the pointer, or the function pointer value is directly obtained, and the CPU number and system time at this time are obtained at the same time, so that the CPU number and function pointer value can be obtained in real time through the probe, and the system time when the callback function ends can be obtained, which is called the second system time in this embodiment;

[0060] Combine the CPU number and the function pointer value as the key key and match the first hash map start to find the value of the first system time nsecs recorded. If there is a match result, calculate the time difference between the second system time and the matched first system time nsecs, and then delete the value corresponding to the key key in the first hash map start;

[0061] Finally, the time difference delete is used to update the running time corresponding to the callback function. Specifically, the function pointer value is used as the key, and the corresponding value of the key whose key value is the function pointer value in the second hash map timer_exprit is added to the time difference delete as the updated running time; at the same time, the number of calls corresponding to the callback function is updated and saved. Specifically, the corresponding value of the key whose key value is the function pointer value in the third hash map timer_count is added by one as the updated number of calls.

[0062] In step S13 of this embodiment, after calculating the time difference between the second system time and the matched first system time, it also includes: storing the function pointer value and the corresponding time difference in a histogram mapping, and the histogram mapping refers to a mapping operation tool for counting the frequency distribution of the callback function running time interval, which can calculate the number of hits of different callback functions in different running time intervals.

[0063] The timers in this embodiment are divided into common timers and high-precision and low-precision timers hrtimers; the pin points of their callback functions are timer_expire_entry, timer_expire_exit and hrtimer_expire_entry, hrtimer_expire_exit respectively.

[0064] In step S2 of this embodiment, since in most programming environments and libraries, a timer object is usually bound to only one callback function, the timer can be determined according to the callback function and the kernel function that calls the timer can be located. Figure 3 As shown, the specific steps include:

[0065] S21) extracting a function pointer of the callback function from the second hash map timer_exprit or the third hash map timer_count, converting it into a corresponding callback function name through a symbol table, and using regular matching according to the name of the callback function to obtain a code segment when the callback function in the corresponding timer is initialized;

[0066] S22) extracting target information from the code segment, the target information including parent structure information of the corresponding timer, corresponding parameter naming, etc.;

[0067] S23) If the code segment for calling the start of the corresponding timer is matched according to the target information and the API function field characteristics of the corresponding timer start function, the function containing this code segment is the kernel function for calling the timer to run. Therefore, the function containing the code segment for calling the start of the corresponding timer is used as the kernel function for calling the corresponding timer to run.

[0068] like Figure 4 As shown, step S3 of this embodiment includes the following steps:

[0069] S31) obtaining the module that needs to be run by the system through the test scenario, and locating the kernel code range of the module. How to obtain the module that needs to be run through the test scenario and locate the kernel code range of the module is well known to those skilled in the art. This embodiment does not involve improvements to the relevant process, so the specific implementation process is not repeated;

[0070] S32) Determine whether the callback function of the timer and the kernel function that calls the timer are within the kernel code range of the module. If not, it is an invalid call and jumps to step S5. If so, it is not an invalid call, but it is necessary to further determine whether it is an abnormally high-frequency call and execute step S4.

[0071] In step S4 of this embodiment, the running time and calling number of the callback function are respectively obtained by matching the second hash map timer_exprit and the third hash map timer_count according to the function pointer value of the callback function. When judging whether the running time and calling number of the callback function both meet the judgment rule of abnormally high frequency calling, if Figure 5 As shown, including:

[0072] Directly set the thresholds of running time and calling times. If the running time of the current callback function is greater than the preset running time threshold, and the calling times of the current callback function are greater than the preset calling times threshold, then the running time and calling times of the current callback function both meet the judgment rule of abnormally high frequency calling.

[0073] Alternatively, a performance index, an energy-saving index and corresponding thresholds are set, and the performance index and energy-saving index of the current callback function are calculated according to the running time and the number of calls of the current callback function. If the performance index of the current callback function is greater than a preset performance index threshold, and the energy-saving index of the current callback function is greater than a preset energy-saving index threshold, then the running time and the number of calls of the current callback function both meet the judgment rule of abnormally high frequency calls;

[0074] Alternatively, an internal comparison is performed. If the running time and the number of calls of the current callback function are much larger than the running time and the number of calls of other callback functions, then the running time and the number of calls of the current callback function both meet the judgment rules of abnormally high-frequency calls. The running time and the number of calls of the current callback function are much larger than the running time and the number of calls of other callback functions. Specifically, it means that the running time and the number of calls of the current callback function are both larger than the sum of the running time and the sum of the calling times of other callback functions, or the difference between the running time and the number of calls of the current callback function and the running time and the number of calls of other callback functions is larger than the preset first difference threshold.

[0075] In this embodiment, when setting the performance index, energy-saving index and corresponding threshold, the parameters Perf_t that affect the performance due to the running time and the parameter Perf_c that affect the performance due to the number of calls are set according to the application scenario and requirements; the parameters E_t that affect the power consumption due to the running time and the parameter E_c that affect the power consumption due to the number of calls are set. At the same time, according to the application scenario and requirements and the type and purpose of the timer, the performance threshold Perf_threshold and the energy-saving threshold E_threshold are determined; the running time t corresponding to the timer is obtained, and the number of calls c is used to calculate the impact of this timer on performance and energy saving as the performance index and energy-saving index. The expressions are as follows:

[0076] P=Perf_t×t+Perf_c×c

[0077] E=E_t×t+E_c×c

[0078] Among them, P represents the performance index, E represents the energy saving index, Perf_t represents the parameter affecting the performance due to the running time, Perf_c represents the parameter affecting the performance due to the number of calls, E_t represents the parameter affecting the power consumption due to the running time, E_c represents the parameter affecting the power consumption due to the number of calls, t represents the running time of the callback function, and c represents the number of calls of the callback function.

[0079] In step S5 of this embodiment, the number of calls of each category in the kernel function that calls the corresponding timer is obtained. Specifically, when the timer call is an abnormally high-frequency call or an invalid call, the probe is continued to be inserted into the kernel function that calls this timer to obtain the number of calls of the stack information, process name, etc. during runtime. Different categories can be obtained by classification with the stack information, process name, etc. as keys. Based on the divided categories, the number of calls of different categories can be obtained from the number of calls of the stack information, process name, etc. in the kernel function that calls this timer.

[0080] In step S5 of this embodiment, when determining the abnormality category according to the number of calls, it includes:

[0081] According to the scenario requirements, directly set the call count threshold. If the call count of the current category is greater than the preset call count threshold, the current category is an abnormal category.

[0082] Alternatively, an internal comparison is performed to calculate the mean or standard deviation of the number of calls for all categories. If the number of calls for the current category is greater than a specified multiple of the mean or standard deviation, the current category is an abnormal category; alternatively, if the number of calls for the current category is much greater than the number of calls for other categories, the current category is an abnormal category. The number of calls for the current category is much greater than the number of calls for other categories specifically means that the number of calls for the current category is greater than the sum of the number of calls for other categories or the difference between the number of calls for the current category and the number of calls for other categories is greater than a preset second difference threshold.

[0083] In step S6 of this embodiment, considering that the timer call can be called in different environments, the stack information and process name are used to classify the callers inside and outside the kernel, so the stack information, process name and other information of the exception category are combined to diagnose the application or kernel module that causes the timer to be abnormally called, specifically including:

[0084] If the bottom of the stack information of the exception category is a syscall call, the timer is called by the out-of-core application through the syscall interface, and the out-of-core exception application is located according to the process ID, parent process ID, process name string and other information of the exception category. How to locate the out-of-core exception application according to the relevant information is well known to those skilled in the art. This embodiment does not involve improvements to the specific implementation process, so the specific implementation process is not repeated;

[0085] If the bottom of the stack information of the exception category is not a syscall call, the timer call is not directly introduced by an out-of-core application. The abnormal kernel module is located in combination with the kernel source code and the stack information of the exception category. How to locate the abnormal kernel module based on relevant information is well known to those skilled in the art. This embodiment does not involve improvements to the specific implementation process, so the specific implementation process is not repeated.

[0086] Embodiment 2

[0087] This embodiment proposes a detection and diagnosis system for abnormal call of a timer in a Linux system, including a microprocessor and a computer-readable storage medium connected to each other, wherein the microprocessor is programmed or configured to execute the detection and diagnosis method for abnormal call of a timer in a Linux system described in Embodiment 1.

[0088] In summary, the present invention proposes a method for detecting and diagnosing abnormal calls of timers in a Linux system, and proposes a system for detecting and diagnosing abnormal calls of timers in a Linux system that executes the method, which can significantly improve the efficiency of detecting and diagnosing abnormal calls of timers, and provide an optimization basis for solving system power consumption and performance problems caused by abnormal calls of timers. Compared with the prior art, it has the following beneficial effects:

[0089] 1) It can directly determine whether the timer is invalid, abnormal call, and indicate the cause of the abnormal call.

[0090] 2) Significantly improves the efficiency of detecting and diagnosing timer abnormal calls.

[0091] 3) Provides detailed detection and diagnosis methods for performance and energy saving issues caused by abnormal timer calls.

[0092] The above is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiments. All technical solutions under the concept of the present invention belong to the protection scope of the present invention. It should be pointed out that for ordinary technicians in this technical field, some improvements and modifications without departing from the principle of the present invention should also be regarded as the protection scope of the present invention.

Claims

1. A method for detecting and diagnosing abnormal calls of a timer in a Linux system, characterized in that: The following steps are involved: Get the running time and calling times of each timer's callback function respectively; According to the callback function match, call the kernel function of the corresponding timer; Determine whether the callback function and the kernel function that calls the corresponding timer are both within the kernel code range of the module required for the test scenario to run, otherwise the corresponding timer call is an invalid call; Determine whether the running time and calling times of the callback function meet the judgment rule of abnormally high frequency calling, if yes, the corresponding timer calling is abnormally high frequency calling; If the corresponding timer call is an invalid call or an abnormally high-frequency call, obtain the number of calls of each category in the kernel function that calls the corresponding timer, determine the exception category based on the number of calls, and diagnose the cause of the abnormal timer call based on the information of the exception category.

2. The method for detecting and diagnosing abnormal call of a Linux system timer according to claim 1, characterized in that: To obtain the running time and calling times of each timer's callback function respectively, the following steps are included: Insert a probe into the tracepoint point where the callback function starts, obtain the CPU number and the function pointer value in real time through the probe, and obtain the corresponding first system time, combine the CPU number and the function pointer value as the key in a key-value pair, use the corresponding first system time as the value in the key-value pair, and store the key-value pair in the first hash map; Insert a probe into the tracepoint where the callback function ends, obtain the CPU number and function pointer value in real time through the probe, and obtain the corresponding second system time, combine the CPU number and function pointer value and match the first hash map, if there is a match, calculate the time difference between the second system time and the matched first system time, and use the time difference to update the running time corresponding to the callback function, and update and save the number of calls corresponding to the callback function.

3. The method for detecting and diagnosing abnormal calls of a Linux system timer according to claim 2, characterized in that: Using the time difference to update the running time corresponding to the callback function specifically involves adding the corresponding value of the key whose key value is the function pointer value in the second hash map to the time difference as the updated running time; updating and saving the number of calls corresponding to the callback function specifically involves adding one to the corresponding value of the key whose key value is the function pointer value in the third hash map as the updated number of calls.

4. The method for detecting and diagnosing abnormal calls of a Linux system timer according to claim 2, characterized in that: After calculating the time difference between the second system time and the matched first system time, the method further includes: storing the function pointer value and the corresponding time difference in a histogram map to count the hit numbers of different callback functions in different running time intervals.

5. The method for detecting and diagnosing abnormal call of a Linux system timer according to claim 1, characterized in that: When the kernel function corresponding to the timer is called according to the callback function match, it includes: Use regular expression matching according to the name of the callback function to obtain the code segment when the callback function in the corresponding timer is initialized; Target information is extracted from the code segment. If the code segment that calls the start of the corresponding timer is matched based on the target information and the corresponding timer start function API function field characteristics, the function containing the code segment that calls the start of the corresponding timer will be used as the kernel function that calls the corresponding timer to run. The target information includes the parent structure information of the corresponding timer and the corresponding parameter naming.

6. The method for detecting and diagnosing abnormal call of a Linux system timer according to claim 1, characterized in that: When judging whether the running time and calling times of the callback function meet the judgment rules of abnormally high frequency calling, it includes: If the running time of the current callback function is greater than the preset running time threshold, and the number of calls of the current callback function is greater than the preset call number threshold, then the running time and the number of calls of the current callback function both meet the judgment rule of abnormally high frequency calls; Alternatively, the performance index and energy-saving index of the current callback function are calculated according to the running time and the number of calls of the current callback function. If the performance index of the current callback function is greater than a preset performance index threshold, and the energy-saving index of the current callback function is greater than a preset energy-saving index threshold, then the running time and the number of calls of the current callback function both meet the judgment rule of abnormally high frequency calls; Alternatively, if the running time and calling number of the current callback function are much greater than the running time and calling number of other callback functions, then the running time and calling number of the current callback function both meet the judgment rules of abnormally high-frequency calls. The running time and calling number of the current callback function are much greater than the running time and calling number of other callback functions, specifically means that the running time and calling number of the current callback function are greater than the sum of the running time and the sum of the calling number of other callback functions, or the difference between the running time and calling number of the current callback function and the running time and calling number of other callback functions is greater than the preset first difference threshold.

7. The method for detecting and diagnosing abnormal call of a timer in a Linux system according to claim 6, characterized in that: The expressions of the performance index and energy saving index are as follows: P=Perf_t×t+Perf_c×c E=E_t×t+E_c×c Among them, P represents the performance index, E represents the energy saving index, Perf_t represents the parameter affecting the performance due to the running time, Perf_c represents the parameter affecting the performance due to the number of calls, E_t represents the parameter affecting the power consumption due to the running time, E_c represents the parameter affecting the power consumption due to the number of calls, t represents the running time of the callback function, and c represents the number of calls of the callback function.

8. The method for detecting and diagnosing abnormal call of a Linux system timer according to claim 1, characterized in that: When determining the exception category based on the number of calls, it includes: If the number of calls of the current category is greater than the preset call number threshold, the current category is an abnormal category; Alternatively, the mean or standard deviation of the number of calls of all categories is calculated, and if the number of calls of the current category is greater than a specified multiple of the mean or standard deviation, the current category is an abnormal category; Alternatively, if the number of calls of the current category is much greater than the number of calls of other categories, the current category is an abnormal category. The number of calls of the current category is much greater than the number of calls of other categories, which specifically means that the number of calls of the current category is greater than the sum of the number of calls of other categories or the difference between the number of calls of the current category and the number of calls of other categories is greater than the preset second difference threshold.

9. The method for detecting and diagnosing abnormal call of a Linux system timer according to claim 1, characterized in that: Diagnose the cause of the timer exception call based on the exception category information, including: If the bottom of the stack information of the exception category is a syscall call, the out-of-core exception application is located based on the process ID, parent process ID, and process name string of the exception category; If the bottom of the stack information of the exception category is not a syscall call, the abnormal kernel module is located by combining the kernel source code and the stack information of the exception category.

10. A detection and diagnosis system for abnormal call of timer in Linux system, characterized in that: The invention comprises a microprocessor and a computer-readable storage medium connected to each other, wherein the microprocessor is programmed or configured to execute the detection and diagnosis method of abnormal call of a timer in a Linux system as claimed in any one of claims 1 to 9.

Images