Performance test method, device and system for embedded operating system

Abstract

The invention relates to a performance testing method, device, system and equipment for an embedded operating system and a medium. The method comprises the steps that a monitoring point is added to at least one position of a kernel of the embedded operating system; setting test configuration information of the real-time performance analysis module, including setting a monitoring point to be monitored and setting an abnormal threshold corresponding to performance index data acquired from the monitoring point; running a test task, acquiring performance index data from the monitored monitoring point in real time through a real-time performance analysis module, and recording current abnormal call stack information and a timestamp when the performance index data exceeds a corresponding abnormal threshold value; and printing the recorded abnormal call stack information and the timestamp through a system idle thread. Therefore, the method can go deep into the kernel layer of the operating system to directly capture and monitor the key performance index data, and once the performance index data is abnormal, the system can immediately position a specific kernel function or module.

Description

Technical Field

[0001] The present application relates to the technical field of real-time performance testing of operating systems, and in particular to a performance testing method, device, system, equipment and medium for an embedded operating system. Background Art

[0002] With the development of technology and the increase in demand, the real-time performance requirements of embedded systems are becoming increasingly stringent. Especially in some key applications, such as automated production lines, real-time data processing systems, and precision instrument control, the system response time must reach the microsecond (us) level, which is directly related to the stability and efficiency of the system. Therefore, embedded operating systems, such as SylixOS, must have a high degree of real-time performance to ensure that they can respond and process tasks in a timely manner under any circumstances.

[0003] At present, the commonly used real-time performance testing methods mainly rely on stress testing programs built on the application layer, which simulate various workloads by calling system interfaces to evaluate the real-time performance of the operating system. These tests usually cover key indicators such as resource competition, task scheduling, and interrupt response time in a multi-threaded environment, such as measuring the time required for a high-priority thread to acquire a mutex lock.

[0004] However, the above test method also has the following limitations:

[0005] Insufficient information depth: Although it can provide an intuitive assessment of real-time performance from the application level, it lacks in-depth insights into the internal mechanisms of the operating system kernel, making it difficult for developers to identify specific performance bottlenecks, limiting further optimization space.

[0006] Low test efficiency: There are many test routines and they need to be run under multiple conditions to cover all possible execution paths and scenarios. This not only consumes a lot of time and computing resources, but also complicates the analysis and application of test results, affecting the overall efficiency and effectiveness of the test. Summary of the invention

[0007] In view of the above problems in the prior art, the present application provides a performance testing method, apparatus, system, equipment and medium for an embedded operating system. By directly adding monitoring points in the kernel of the embedded operating system, the present application can go deep into the kernel level of the operating system and directly capture and monitor key performance indicator data. Once the performance indicator data reaches an abnormal threshold, the system can immediately locate the specific kernel function or module.

[0008] To achieve the above objectives, the present application provides a first aspect of a performance testing method for an embedded operating system, comprising:

[0009] Adding a monitoring point at at least one location of the kernel of the embedded operating system;

[0010] Set the test configuration information of the real-time performance analysis module, including setting the monitoring points to be monitored and setting the abnormal thresholds corresponding to the performance indicator data obtained from the monitoring points;

[0011] Run the test task and obtain the performance indicator data from the monitored monitoring points in real time through the real-time performance analysis module. When the performance indicator data exceeds the corresponding abnormal threshold, record the current abnormal call stack information and timestamp;

[0012] The recorded exception call stack information and timestamp are printed through the system idle thread.

[0013] Thus, in the present application, by directly adding monitoring points in the kernel of the embedded operating system, it is possible to go deep into the kernel level of the operating system and directly capture and monitor key performance indicator data. This deep kernel monitoring method enables developers to clearly see the actual operating status inside the system. Once the performance indicator data reaches an abnormal threshold, the system can immediately locate the specific kernel function or module, thereby helping developers to accurately identify performance bottlenecks and achieve instant discovery of real-time performance problems, thereby avoiding serious system delays or crashes in the later stages.

[0014] As a possible implementation manner of the first aspect, adding a monitoring point at at least one location of the kernel of the embedded operating system includes at least one of the following:

[0015] Add monitoring points at the entry and / or exit of the scheduler;

[0016] Add monitoring points at the entry and / or exit of the interrupt controller;

[0017] Add monitoring points at the acquisition initiation point, acquisition completion point and / or release point of at least one of the kernel lock, spin lock or thread lock;

[0018] Add monitoring points at the acquisition initiation point and acquisition completion point of the semaphore;

[0019] Add monitoring points when shutting down and / or re-enabling interrupts;

[0020] Add watchpoints at user-defined locations in the kernel code.

[0021] In this way, since the monitoring points are configurable, users can add only necessary monitoring points at specific locations without affecting system performance. This design allows users to flexibly deploy monitoring points according to their own needs, greatly improving the flexibility and configurability of the system.

[0022] As a possible implementation of the first aspect, the performance indicator data includes: data related to a timestamp;

[0023] The abnormal threshold corresponding to the performance indicator data includes at least one of the following abnormal thresholds set based on the timestamp data:

[0024] The abnormal threshold of the task execution time of the scheduled task or the abnormal threshold of the task switching time,

[0025] The abnormal threshold of the interrupt processing duration,

[0026] The abnormal threshold of lock acquisition time of kernel lock, spin lock or thread lock, or the abnormal threshold of lock execution time,

[0027] Abnormal threshold for semaphore acquisition time,

[0028] The abnormal threshold of interrupt duration for disabling interrupts, the abnormal threshold of kernel critical section duration,

[0029] A user-defined abnormal threshold for the execution time of the monitoring object.

[0030] In this way, by setting the abnormal threshold based on the timestamp data, the performance indicator data that exceeds the abnormal threshold (i.e. the normal range) can be quickly identified, which is conducive to users to timely discover and solve potential performance bottlenecks. In addition, allowing users to set abnormal thresholds according to their own needs enhances the flexibility of the system, so that the system can better adapt to the monitoring needs in different application scenarios.

[0031] As a possible implementation manner of the first aspect, the timestamp is created in a manner including: creating it by stubbing through a system clock interface.

[0032] Thus, creating timestamps in this way can ensure the accuracy and consistency of timestamps. The accuracy and consistency of timestamps make it easier for developers to debug and perform performance analysis, especially in a multi-tasking or multi-threaded environment, so that they can more accurately understand the interactions and execution order between tasks or threads.

[0033] As a possible implementation of the first aspect, the method further includes: when the test task is run, a pressurization program is also run;

[0034] The compression program includes one of the following: a memory compression program, a storage compression program, and a network compression program.

[0035] In this way, the stress program can simulate high memory, high load and other situations in actual applications, making the test environment closer to the actual operating conditions, thereby more accurately evaluating the performance and stability of the system.

[0036] To achieve the above-mentioned purpose, the second aspect of the present application provides a performance testing device for an embedded operating system, comprising:

[0037] A monitoring point is added at least one location of the kernel of the embedded operating system;

[0038] A setting module is used to set the test configuration information of the real-time performance analysis module, including setting the monitoring points to be monitored and setting the abnormal thresholds corresponding to the performance indicator data obtained from the monitoring points;

[0039] The test module is used to run the test task and obtain the performance index data from the monitored monitoring points in real time through the real-time performance analysis module. When the performance index data exceeds the corresponding abnormal threshold, the current abnormal call stack information and timestamp are recorded;

[0040] The output module is used to print the recorded exception call stack information and timestamp through the system idle thread.

[0041] To achieve the above-mentioned purpose, the third aspect of the present application provides an embedded operating system, including:

[0042] User space, where test programs are deployed to run test tasks;

[0043] Kernel space, which deploys the system idle thread module, real-time performance analysis module, scheduler, and interrupt controller;

[0044] Wherein, a monitoring point is added at the entrance and / or exit of the scheduler, and a monitoring point is added at the entrance and / or exit of the interrupt controller;

[0045] The real-time performance analysis module is provided with test configuration information, including setting the monitoring points to be monitored and setting the abnormal thresholds corresponding to the performance indicator data obtained from the monitoring points;

[0046] The real-time performance analysis module is used to obtain performance indicator data from the monitored monitoring points in real time when the test task is running, and record the current abnormal call stack information and timestamp when the performance indicator data exceeds the corresponding abnormal threshold;

[0047] The system idle thread module is used to print the recorded exception call stack information and timestamp.

[0048] To achieve the above-mentioned object, the fourth aspect of the present application provides a computing device, including:

[0049] processor, and

[0050] A memory having program instructions stored thereon, wherein when the program instructions are executed by the processor, the processor executes the method described in any one of the first aspects above.

[0051] To achieve the above-mentioned purpose, the fifth aspect of the present application provides a computer-readable storage medium having program instructions stored thereon, and when the program instructions are executed by a computer, the computer implements any of the methods described in the first aspect above. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] Figure 1 It is a flow chart of the main steps of a performance testing method for an embedded operating system provided by the present application;

[0053] Figure 2 It is a structural schematic diagram of a performance testing device for an embedded operating system provided by the present application;

[0054] Figure 3 It is a structural schematic diagram of an embedded operating system provided by the present application;

[0055] Figure 4 It is a structural schematic diagram of a computing device provided by the present application.

[0056] It should be understood that the size and shape of each block diagram in the above structural diagram are for reference only and should not constitute an exclusive interpretation of the embodiment of the present invention. The relative position and inclusion relationship between the blocks presented in the structural diagram are only schematic representations of the structural association between the blocks, and do not limit the physical connection method of the embodiment of the present invention. DETAILED DESCRIPTION

[0057] The technical solution provided by the present application is further described below with reference to the accompanying drawings and examples. It should be understood that the system structure and business scenarios provided in the examples of the present application are mainly to illustrate the possible implementation methods of the technical solution of the present application and should not be interpreted as the only limitation on the technical solution of the present application. It is known to those of ordinary skill in the art that with the evolution of the system structure and the emergence of new business scenarios, the technical solution provided by the present application is also applicable to similar technical problems.

[0058] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art of the present application. In case of any inconsistency, the meaning described in this specification or the meaning derived from the contents recorded in this specification shall prevail. In addition, the terms used herein are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application.

[0059] User space and kernel space are important components of embedded operating systems, but they each have different responsibilities and different permission levels in the operating system.

[0060] User space: It is where applications and other user-level services run. Applications, libraries, and other user-level services are all executed in user space. Programs in user space usually do not have the ability to directly access hardware, nor can they directly call underlying system resources. Instead, they interact with the kernel through the System Call Interface to request services provided by the kernel. This approach can ensure the security and stability of the system because errors in user space will not directly affect the underlying operation of the system.

[0061] Kernel space: This is where the operating system kernel runs. The kernel is responsible for managing the system's hardware resources, including CPU time, memory, input / output devices, etc. The code in the kernel space has the highest permissions and can directly access and manage hardware resources. The kernel space contains the core services of the operating system, such as process management, memory management, file system management, network stack, etc.

[0062] The present application embodiment provides a performance testing method for an embedded operating system. Figure 1 As shown, including:

[0063] S101, adding a monitoring point at at least one location of a kernel of an embedded operating system;

[0064] This step can be understood as: some key locations can be selected in the core code of the embedded operating system to insert monitoring codes so as to collect performance indicator data at these locations.

[0065] S102, setting the test configuration information of the real-time performance analysis module, including setting the monitoring points to be monitored and setting the abnormal thresholds corresponding to the performance indicator data obtained from the monitoring points;

[0066] The real-time performance analysis module is located in the kernel space (see Figure 3 ), data can be directly obtained from a monitoring point added to at least one position of the kernel of the embedded operating system.

[0067] The setting of the monitoring points to be monitored can be understood as: determining the setting range and number of the monitoring points according to the monitoring objectives and requirements, that is, selecting at least one monitoring point to be monitored from the various monitoring points in step S101.

[0068] In addition, users have two different ways to set abnormal thresholds: one is to directly edit the configuration file and restart the service through the command line interface; the other is to indirectly affect the behavior of the program or service by setting system environment variables.

[0069] S103, running the test task, and obtaining performance indicator data from the monitored monitoring points in real time through the real-time performance analysis module, and when the performance indicator data exceeds the corresponding abnormal threshold, recording the current abnormal call stack information and timestamp;

[0070] The call stack is a data structure used to save temporary variables when a task or function is running. The call stack mainly records the function call history of the currently executing task, that is, the order of a series of function calls. The information contained in each stack frame usually includes the address of the current function, local variables, parameters, and return address, etc. By recording the current exception call stack information and timestamp, it helps to quickly locate the specific function or code segment when a problem occurs.

[0071] S104: Print the recorded exception call stack information and timestamp through the system idle thread.

[0072] Using the system idle thread to print exception information can avoid introducing additional performance overhead due to printing operations during critical moments of performance testing or normal system operation. The idle thread performs printing tasks when system resources are relatively idle, thereby reducing interference with the main functions of the system.

[0073] Thus, in the present application, by directly adding monitoring points in the kernel of the embedded operating system, it is possible to go deep into the kernel level of the operating system and directly capture and monitor key performance indicator data. This deep kernel monitoring method enables developers to clearly see the actual operating status inside the system. Once the performance indicator data reaches an abnormal threshold, the system can immediately locate the specific kernel function or module, thereby helping developers to accurately identify performance bottlenecks and achieve instant discovery of real-time performance problems, thereby avoiding serious system delays or crashes in the later stages.

[0074] In some embodiments, adding a monitoring point at at least one location of the kernel of the embedded operating system includes at least one of the following:

[0075] Add monitoring points at the entry and / or exit of the scheduler;

[0076] Add monitoring points at the entry and / or exit of the interrupt controller;

[0077] Add monitoring points at the acquisition initiation point, acquisition completion point and / or release point of at least one of the kernel lock, spin lock or thread lock;

[0078] Add monitoring points at the acquisition initiation point and acquisition completion point of the semaphore;

[0079] Add monitoring points when shutting down and / or re-enabling interrupts;

[0080] Add watchpoints at user-defined locations in the kernel code.

[0081] Specifically, a monitoring point is added where the scheduler starts to execute, and a hook function is inserted into the monitoring point to record information such as the time when the task is called. Similarly, a monitoring point is added where the scheduler ends to execute, and a hook function is inserted into the monitoring point to record the time when the task is completed. Among them, the execution time of the task can be determined based on the time when the task is called and the time when the task is completed.

[0082] In the interrupt processing flow of the interrupt controller, a hook function for time recording is added. That is, a time point is recorded when the interrupt is triggered (i.e., interrupt entry), and another time point is recorded when the interrupt is processed (i.e., interrupt exit). These two time points can be used to calculate the total time consumed by interrupt processing.

[0083] Taking the spin lock as an example, a monitoring point is added at the acquisition initiation point of the spin lock to record the time point when the lock acquisition attempt starts; a monitoring point is added at the acquisition completion point of the spin lock (including successful acquisition or failed acquisition) to record the actual acquisition time of the lock, that is, the time interval from the acquisition attempt to the successful acquisition or failure.

[0084] By adding monitoring points at the acquisition initiation point and the acquisition completion point of the semaphore, recording the time point of attempting to acquire the semaphore and the time point of successfully acquiring the semaphore, the time spent from attempting to acquire to successfully acquiring, that is, the waiting time, can be determined based on these two times.

[0085] By adding monitoring points at closing and / or reopening interruptions, the exact time when the interruption is closed is recorded, and the time when the interruption is reopened is recorded. Based on these two times, the total duration of the interruption closure can also be determined.

[0086] Of course, the above content is only an example. In actual applications, monitoring points can be added at user-defined locations in the kernel code as needed to obtain time information in specific scenarios, which improves the flexibility of the design and meets the needs of different scenarios.

[0087] In addition, as in step S102 above, since the monitoring points to be monitored are configurable, the user can monitor only some monitoring points as needed without affecting the system performance. This design allows the user to flexibly set the monitoring points to be monitored according to their own needs, thereby greatly improving the flexibility and configurability of the system.

[0088] In some embodiments, the performance indicator data includes: data associated with a timestamp;

[0089] The abnormal threshold corresponding to the performance indicator data includes at least one of the following abnormal thresholds set based on the timestamp data:

[0090] The abnormal threshold of the task execution time of the scheduled task or the abnormal threshold of the task switching time,

[0091] The abnormal threshold of the interrupt processing duration,

[0092] The abnormal threshold of lock acquisition time of kernel lock, spin lock or thread lock, or the abnormal threshold of lock execution time,

[0093] Abnormal threshold for semaphore acquisition time,

[0094] The abnormal threshold of interrupt duration for disabling interrupts, the abnormal threshold of kernel critical section duration,

[0095] A user-defined abnormal threshold for the execution time of the monitoring object.

[0096] It is worth noting here that the kernel critical section duration can be understood as: the time taken for a task to enter and completely exit this critical section (a critical section usually refers to a section of code that must exclusively access shared resources in a multi-threaded or multi-processor environment), that is, the longest time that a task is not allowed to be interrupted. In some embodiments, monitoring the kernel critical section duration can be achieved by recording a timestamp when entering and exiting the critical section. When the system enters the critical section, the current timestamp is recorded; when leaving the critical section, the timestamp is recorded again, and the difference between the two is calculated, which is the time spent in the critical section. In other embodiments, when a task enters the kernel critical section, it will turn off interrupts to ensure that it will not be interrupted by external interrupts. When exiting the critical section, the interrupts will be re-enabled. The kernel critical section duration can be monitored by recording timestamps when turning off and re-enabling interrupts.

[0097] In this way, by setting the abnormal threshold based on the timestamp data, the performance indicator data that exceeds the abnormal threshold (i.e. the normal range) can be quickly identified, which is conducive to users to timely discover and solve potential performance bottlenecks. In addition, allowing users to set abnormal thresholds according to their own needs enhances the flexibility of the system, so that the system can better adapt to the monitoring needs in different application scenarios.

[0098] In some embodiments, the timestamp is created by: creating it by stubbing through a system clock interface.

[0099] Thus, creating timestamps in this way can ensure the accuracy and consistency of timestamps. The accuracy and consistency of timestamps make it easier for developers to debug and perform performance analysis, especially in a multi-tasking or multi-threaded environment, so that they can more accurately understand the interactions and execution order between tasks or threads.

[0100] In some embodiments, it also includes: when the test task is run, a pressurization program is also run;

[0101] The compression program includes one of the following: a memory compression program, a storage compression program, and a network compression program.

[0102] Three pressurization procedures are described below.

[0103] Memory stress program: used to stress test the system's memory resources. It simulates high memory usage scenarios by allocating a large amount of memory resources, frequently allocating and releasing memory, or trying to access memory space that exceeds the actual physical memory size. The purpose is to detect the behavior of the system when memory resources are tight, whether there will be memory leaks, memory overflow errors, or a sharp drop in performance.

[0104] Storage stress tester: used to perform stress tests on storage systems (such as hard disks, SSDs, cloud storage, etc.). It simulates a high-load storage environment by performing a large number of read and write operations, concurrent access, or creating a large number of small files. The purpose is to evaluate the storage system's read and write speed, response time, and whether it can maintain data consistency and integrity under high load.

[0105] Network stress program: used to simulate network traffic and load to test the performance of network devices and systems under high network traffic. By generating a large number of network data packets, it simulates multiple network protocols and data transmission modes, such as TCP / IP, HTTP, FTP, etc. The purpose is to help find network bottlenecks, optimize network configuration, and verify the reliability and stability of network systems.

[0106] In summary, memory stress tester, storage stress tester and network stress tester are all tools used to simulate and test the performance of the system under different stress conditions. They perform stress tests on three different aspects: memory, storage and network, to help developers, system administrators and network engineers evaluate the stability and performance of the system, and discover and solve potential problems.

[0107] In this way, the stress program can simulate high memory, high load and other situations in actual applications, making the test environment closer to the actual operating conditions, thereby more accurately evaluating the performance and stability of the system.

[0108] In order to more clearly illustrate the above method, the present application provides a specific embodiment.

[0109] Example: Take the duration of interrupt processing as an example.

[0110] Step 1: adding a monitoring point at at least one location of the kernel of the embedded operating system;

[0111] Step 2: Setting the test configuration information of the real-time performance analysis module, including setting the monitoring points to be monitored and setting the abnormal thresholds corresponding to the performance indicator data obtained from the monitoring points;

[0112] This embodiment includes adding monitoring points at the entry and exit of the interrupt controller. Specifically, a hook function is added at the entry and exit of the interrupt controller.

[0113] Furthermore, in this embodiment, the abnormal threshold corresponding to the acquired performance indicator data can be set by means of command line configuration or system environment variable configuration, such as setting it to 80 μs.

[0114] Step 3: Start the pressurization procedure;

[0115] Specifically, the pressure program includes: a memory pressure program, a storage pressure program and a network pressure program to simulate a high-load scenario.

[0116] Step 4: Run the test task;

[0117] In the process of running the test task, since hook functions are added at the entry and exit of the interrupt controller, a time point is recorded when the interrupt is triggered (i.e., the interrupt entry), and another time point is recorded when the interrupt is processed (i.e., the interrupt exit). In addition, these two time points can be used to calculate the total time consumed by the interrupt processing, that is, the duration of the interrupt processing.

[0118] Step 5: Obtain performance indicator data from the monitored monitoring points in real time through the real-time performance analysis module, that is, the duration of the interrupt processing, such as set to 100 μs;

[0119] Step 6: When the acquired performance indicator data (100 μs) exceeds the abnormal threshold (80 μs), the real-time performance analysis module records the current call stack and timestamp.

[0120] Step 7: When the system idle thread is scheduled, the real-time performance analysis module outputs the recorded current call stack and timestamp.

[0121] The call stack shows the code path that causes the interrupt shutdown timeout, helping developers understand which function or code path causes the interrupt shutdown time to be too long.

[0122] The timestamp provides the exact time when the shutdown event occurred and can be used to compare with other system events or logs to identify possible concurrent operations or system state changes.

[0123] Figure 2 1 is a structural schematic diagram of a performance test device for an embedded operating system provided in an embodiment of the present application. The embodiment of the present application provides a performance test device 200 for an embedded operating system, including:

[0124] A monitoring point 201 is added to at least one location of the kernel of the embedded operating system;

[0125] A setting module 202, used to set the test configuration information of the real-time performance analysis module, including setting the monitoring points to be monitored and setting the abnormal thresholds corresponding to the performance indicator data obtained from the monitoring points;

[0126] The test module 203 is used to run the test task and obtain the performance index data from the monitored monitoring points in real time through the real-time performance analysis module. When the performance index data exceeds the corresponding abnormal threshold, the current abnormal call stack information and timestamp are recorded;

[0127] The output module 204 is used to print the recorded exception call stack information and timestamp through the system idle thread.

[0128] Figure 3 is a structural schematic diagram of an embedded operating system provided in an embodiment of the present application. The embodiment of the present application provides an embedded operating system 300, including:

[0129] User space 301, in which a test program is deployed and used to run test tasks;

[0130] Kernel space 302, which is deployed with a system idle thread module, a real-time performance analysis module, a scheduler, and an interrupt controller;

[0131] Wherein, a monitoring point is added at the entrance and / or exit of the scheduler, and a monitoring point is added at the entrance and / or exit of the interrupt controller;

[0132] The real-time performance analysis module is provided with test configuration information, including setting the monitoring points to be monitored and setting the abnormal thresholds corresponding to the performance indicator data obtained from the monitoring points;

[0133] The real-time performance analysis module is used to obtain performance indicator data from the monitored monitoring points in real time when the test task is running, and record the current abnormal call stack information and timestamp when the performance indicator data exceeds the corresponding abnormal threshold;

[0134] The system idle thread module is used to print the recorded exception call stack information and timestamp.

[0135] In some embodiments, the user space is further deployed with a pressure program for running in the background when the test task is running;

[0136] The compression program includes one of the following: a memory compression program, a storage compression program, and a network compression program.

[0137] Figure 4 4 is a schematic diagram of a computing device 400 provided in an embodiment of the present application. The computing device executes the above method, such as Figure 4 As shown, the computing device 400 includes: a processor 410 , a memory 420 , and a communication interface 430 .

[0138] It should be understood that Figure 4 The communication interface 430 in the computing device 400 shown may be used to communicate with other devices, and may specifically include one or more transceiver circuits or interface circuits.

[0139] The processor 410 may be connected to a memory 420. The memory 420 may be used to store the program code and data. Therefore, the memory 420 may be a storage unit inside the processor 410, or an external storage unit independent of the processor 410, or a component including a storage unit inside the processor 410 and an external storage unit independent of the processor 410.

[0140] Optionally, the computing device 400 may further include a bus. The memory 420 and the communication interface 430 may be connected to the processor 410 via the bus. The bus may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 A line without an arrow is used to represent the bus, but this does not mean that there is only one bus or one type of bus.

[0141] It should be understood that in the embodiment of the present application, the processor 410 may adopt a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. Alternatively, the processor 410 may adopt one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiment of the present application.

[0142] The memory 420 may include a read-only memory and a random access memory, and provides instructions and data to the processor 410. A portion of the processor 410 may also include a nonvolatile random access memory. For example, the processor 410 may also store information on the device type.

[0143] When the computing device 400 is running, the processor 410 executes the computer-executable instructions in the memory 420 to perform any operation step of the above method and any optional embodiment thereof.

[0144] It should be understood that the computing device 400 according to the embodiment of the present application can correspond to the corresponding subjects in the methods according to the embodiments of the present application, and the above-mentioned and other operations and / or functions of each module in the computing device 400 are respectively for implementing the corresponding processes of each method of the present embodiment, which will not be repeated here for the sake of brevity.

[0145] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0146] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0147] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0148] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0149] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0150] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0151] An embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, it is used to execute the above method, which includes at least one of the solutions described in the above embodiments.

[0152] The computer storage medium of the embodiment of the present application can adopt any combination of one or more computer-readable media. Computer-readable media can be computer-readable signal media or computer-readable storage media. Computer-readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or devices, or any combination of the above. More specific examples (non-exhaustive lists) of computer-readable storage media include: electrical connections with one or more wires, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In this document, computer-readable storage media can be any tangible medium containing or storing programs, which can be used by instruction execution systems, devices or devices or used in combination with them.

[0153] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0154] The program code embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0155] Computer program code for performing the operation of the present application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., using an Internet service provider to connect through the Internet).

[0156] In addition, the words "first, second, third, etc." or module A, module B, module C and other similar terms in the specification and claims are only used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that the specific order or sequence can be interchanged where permitted so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0157] In the above description, the numbers representing the steps, such as S110, S120, etc., do not necessarily mean that the steps will be executed in this manner. If permitted, the order of the steps can be interchanged or they can be executed simultaneously.

[0158] The term "comprising" as used in the description and claims should not be interpreted as being limited to what is listed thereafter; it does not exclude other elements or steps. Therefore, it should be interpreted as specifying the presence of the features, integers, steps or components mentioned, but does not exclude the presence or addition of one or more other features, integers, steps or components and groups thereof. Therefore, the expression "a device comprising means A and B" should not be limited to a device consisting of components A and B only.

[0159] References to "one embodiment" or "an embodiment" in this specification mean that a particular feature, structure, or characteristic described in conjunction with the embodiment is included in at least one embodiment of the present application. Therefore, the phrases "in one embodiment" or "in an embodiment" appearing in various places in this specification do not necessarily refer to the same embodiment, but may refer to the same embodiment. In addition, in one or more embodiments, the particular features, structures, or characteristics can be combined in any appropriate manner, as would be apparent to one of ordinary skill in the art from this disclosure.

[0160] Note that the above are only preferred embodiments of the present application and the technical principles used. Those skilled in the art will understand that the present application is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present application. Therefore, although the present application is described in more detail through the above embodiments, the present application is not limited to the above embodiments, and may also include more other equivalent embodiments without departing from the concept of the present application, all of which belong to the scope of protection of the present application.

Claims

1. A performance testing method for an embedded operating system, characterized in that: include: Adding a monitoring point at at least one location of the kernel of the embedded operating system; Set the test configuration information of the real-time performance analysis module, including setting the monitoring points to be monitored and setting the abnormal thresholds corresponding to the performance indicator data obtained from the monitoring points; Run the test task and obtain the performance indicator data from the monitored monitoring points in real time through the real-time performance analysis module. When the performance indicator data exceeds the corresponding abnormal threshold, record the current abnormal call stack information and timestamp; The recorded exception call stack information and timestamp are printed through the system idle thread.

2. The method according to claim 1, characterized in that: Adding a monitoring point at at least one location of the kernel of the embedded operating system includes at least one of the following: Add monitoring points at the entry and / or exit of the scheduler; Add monitoring points at the entry and / or exit of the interrupt controller; Add monitoring points at the acquisition initiation point, acquisition completion point and / or release point of at least one of the kernel lock, spin lock or thread lock; Add monitoring points at the acquisition initiation point and acquisition completion point of the semaphore; Add monitoring points when shutting down and / or re-enabling interrupts; Add watchpoints at user-defined locations in the kernel code.

3. The method according to claim 2, characterized in that The performance indicator data includes: data related to timestamp; The abnormal threshold corresponding to the performance indicator data includes at least one of the following abnormal thresholds set based on the timestamp data: The abnormal threshold of the task execution time of the scheduled task or the abnormal threshold of the task switching time, Abnormal threshold of interrupt processing duration, The abnormal threshold of lock acquisition time of kernel lock, spin lock or thread lock, or the abnormal threshold of lock execution time, Abnormal threshold for semaphore acquisition time, The abnormal threshold of interrupt duration for disabling interrupts, the abnormal threshold of kernel critical section duration, A user-defined abnormal threshold for the execution time of the monitoring object.

4. The method according to claim 3, characterized in that The timestamp is created by: creating it by stubbing through the system clock interface.

5. The method according to any one of claims 1 to 4, characterized in that: Also includes: When the test task is run, a pressurization program is also run; The compression program includes one of the following: a memory compression program, a storage compression program, and a network compression program.

6. A performance testing device for an embedded operating system, characterized in that: include: A monitoring point is added at least one location of the kernel of the embedded operating system; A setting module is used to set the test configuration information of the real-time performance analysis module, including setting the monitoring points to be monitored and setting the abnormal thresholds corresponding to the performance indicator data obtained from the monitoring points; The test module is used to run the test task and obtain the performance index data from the monitored monitoring points in real time through the real-time performance analysis module. When the performance index data exceeds the corresponding abnormal threshold, the current abnormal call stack information and timestamp are recorded; The output module is used to print the recorded exception call stack information and timestamp through the system idle thread.

7. An embedded operating system, characterized in that: include: User space, where test programs are deployed to run test tasks; Kernel space, which deploys the system idle thread module, real-time performance analysis module, scheduler, and interrupt controller; Wherein, a monitoring point is added at the entrance and / or exit of the scheduler, and a monitoring point is added at the entrance and / or exit of the interrupt controller; The real-time performance analysis module is provided with test configuration information, including setting the monitoring points to be monitored and setting the abnormal thresholds corresponding to the performance indicator data obtained from the monitoring points; The real-time performance analysis module is used to obtain performance indicator data from the monitored monitoring points in real time when the test task is running, and record the current abnormal call stack information and timestamp when the performance indicator data exceeds the corresponding abnormal threshold; The system idle thread module is used to print the recorded exception call stack information and timestamp.

8. The system according to claim 7, characterized in that The user space is also deployed with a pressure program for running in the background when the test task is running; The compression program includes one of the following: a memory compression program, a storage compression program, and a network compression program.

9. A computing device, characterized in that include: processor, and A memory having program instructions stored thereon, wherein when the program instructions are executed by the processor, the processor is caused to execute the method according to any one of claims 1 to 5.

10. A computer-readable storage medium, characterized in that: Program instructions are stored thereon, and when the program instructions are executed by a computer, the computer is caused to execute the method according to any one of claims 1 to 5.

Images