Performance event monitoring method, device, equipment, program product and medium

Abstract

The invention provides a performance event monitoring method and device, equipment, a program product and a medium. In the method, a first counter is associated with a first performance event, the counting result of the first counter is read and stored under the condition that a first process is switched to a second process, the counting result of the first counter is read when the second process is switched to a third process, and the second process is switched to the third process according to the counting results read twice. The number of times that the first performance event appears in the process is determined without reading and storing the context information of the process event, so that the processing overhead of monitoring the performance event can be reduced.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a performance event monitoring method, apparatus, device, program product, and medium. Background Technology

[0002] Performance events refer to the monitoring (or detection) of performance metrics of computing devices (such as servers) in order to analyze and identify potential problems in a timely manner based on the monitoring results. Performance events can be divided into software events and hardware events. Software events involve monitoring performance metrics at the software level, while hardware events involve monitoring performance metrics at the hardware level.

[0003] Performance event monitoring is typically performed using software tools. When a software tool monitors a process's performance events, it creates a process event to monitor that process. Process event monitoring switches with process switching. When a computing device switches processes, the operating system kernel needs to read and save the context information of the current process event so that when switching back to that process, it can continue monitoring that process using the process event context information. Thus, the operating system kernel needs to read and write a significant amount of context information, resulting in substantial processing overhead during the monitoring process. Summary of the Invention

[0004] This application provides a performance event monitoring method, apparatus, device, program product, and medium to reduce the processing overhead of performance event monitoring.

[0005] Firstly, embodiments of this application provide a performance event monitoring method. This method can be applied to the performance event monitoring device side. The performance event monitoring device side can also be referred to as the computing device side. The performance event monitoring device side can refer to the performance event monitoring device itself, or a module within the performance event monitoring device, or a logic module or software capable of implementing all or part of the functions. The performance event monitoring device can be, for example, a mobile phone, personal computer, or server, or other computing devices. Modules within the performance event monitoring device can be, for example, a processor, communication module, or circuitry or chip responsible for communication functions. Chips can be, for example, modem chips (also known as baseband chips), or system-on-a-chip (SoC) chips containing modem cores, or system-in-package (SIP) chips, etc. For ease of description, the following description uses a computing device executing this method as an example. The method includes: when switching from a first process to a second process, reading and storing a first counting result of a first counter, wherein the first counter is used to accumulate the number of times a first performance event occurs; when switching from a second process to a third process, reading a second counting result of the first counter; and determining the number of times the first performance event occurs in the second process based on the first counting result and the second counting result.

[0006] Switching from process A to process B means that the process running in the central processing unit (CPU) core is switched from process A to process B. In other words, the CPU core was previously running process A, and is now running process B. Switching from process A to process B indicates that process A and process B are not the same process. Switching from process A to process B can be understood or replaced as the scheduling of the CPU core switching the running process from process A to process B, or the process running on the CPU core switching from process A to process B. For example, process A is the first process, and process B is the second process. Alternatively, process A is the second process, and process B is the third process. Or, process A is the third process, and process B is the fourth process. The first counter can be implemented in software, hardware, or a combination of both; its implementation method is not limited. The Xth count result involved in the embodiments of this application is only for distinguishing the count results of the counter at different times, or distinguishing the count results of different counters, and does not limit the size of the count result, etc.

[0007] In this embodiment, the first counter is bound (or associated) with the first performance event but not with the second process. Therefore, in both cases where the first process is switched to the second process and the second process is switched to another process (such as a third process), the counting result of the first counter is read separately to obtain two counting results. Based on the two counting results, the number of times the first performance event occurs in the second process is determined. There is no need to switch process events, and therefore no need to read and store the context information of the process events, thereby reducing the processing overhead of monitoring performance events. Furthermore, since there is no need to frequently switch process events, the overhead of monitoring performance events themselves can be reduced, thus avoiding the overhead of monitoring performance events preempting the running overhead of processes executing business operations, which is beneficial to improving the accuracy of performance event monitoring. Also, because the overhead of monitoring performance events is low, the first counter can be used to continuously and comprehensively monitor performance events, achieving low-overhead and comprehensive monitoring.

[0008] Switching from the first process to the second process is equivalent to starting the second process. In one possible implementation, the second process runs within a CPU core, where the first counter is bound to the CPU core, or can be described as the first counter being registered within the CPU core, or as the first counter corresponding to, associated with, or related to the CPU core. For example, if the first counter is implemented in software and can be used to monitor the CPU core or processes running on the CPU core, then the first counter is bound to the CPU core. This application's embodiment uses the binding of the first counter to the CPU core as an example; in reality, the first counter can be flexibly bound to different CPU cores. For instance, the first counter can be bound to one CPU core for a period of time, or to another CPU core for a different period of time. Alternatively, the first counter can be set within the CPU core. The first counter can also be implemented in hardware, such as an integrated circuit located within the CPU core.

[0009] A CPU core can be referred to as a CPU physical core or a CPU logical core. The first process could be the initial process that runs when the CPU core comes online, or it could be a business-related process that the CPU core will run; there is no specific limitation on this.

[0010] This allows the first counter to accurately monitor whether the first performance event has occurred in the process running in the CPU core.

[0011] In one possible implementation, the first count result is stored in memory; after determining the number of times the first performance event occurs in the second process, the method further includes updating the first count result in memory with a second count result. For example, the first count result is replaced with the second count result by an overwrite write or a clear write.

[0012] This facilitates improved storage space utilization and enables continuous monitoring based on the second counting result.

[0013] In one possible implementation, before storing the first count result of the first counter, the method further includes: obtaining first monitoring information set by the user through a first interface, the first monitoring information indicating a first performance event of the second process; after determining the number of times the first performance event occurs in the second process, the method further includes: providing feedback to the user through a second interface on the number of times the first performance event occurs in the second process.

[0014] This allows for targeted monitoring based on user settings, reducing unnecessary monitoring. Furthermore, it enables timely feedback to users on the results of monitoring performance events.

[0015] In one possible implementation, after determining the number of times the first performance event occurred in the second process, the method further includes: if the third process switches to the fourth process, reading the third counting result of the first counter; and determining the number of times the first performance event occurred in the third process based on the third counting result and the second counting result. The fourth process and the first process may be the same process or different processes; this is not specifically limited. Optionally, after determining the number of times the first performance event occurred in the third process, the method further includes: updating the second counting result stored in memory to the third counting result.

[0016] In this way, a single counter can be used to monitor various processes, such as the second and third processes, without the counter needing to switch with each process, thus reducing the processing overhead of performance event monitoring.

[0017] In one possible implementation, the method further includes: before storing the first counting result of the first counter, the method further includes: obtaining second monitoring information set by the user through a first interface, the second monitoring information indicating a first performance event of the monitoring container, the container including a second process and a third process; after determining the number of times the first performance event occurs in the second process, the method further includes: feeding back to the user the number of times the first performance event occurs in the container through the second interface, the number of times the first performance event occurs in the container being the sum of the number of times the first performance event occurs in the second process and the number of times the first performance event occurs in the third process.

[0018] In this way, performance events can be monitored at the container level, enriching the granularity of performance event monitoring. Furthermore, when using containers as the monitoring granularity, only the sum of performance events occurring in the processes included in the container needs to be calculated, which does not excessively increase the difficulty of monitoring performance events and facilitates more efficient performance event monitoring.

[0019] In one possible implementation, the method further includes: storing a fourth count result of a second counter while storing a first count result of a first counter, the second counter being used to accumulate the number of times a second performance event occurs, the second performance event being different from the first performance event; reading a fifth count result of the second counter while reading a second count result of the first counter; and determining the number of times the second performance event occurs in the second process based on the fourth count result and the fifth count result. Optionally, the second counter is bound to a CPU core, or the second counter is set in a CPU core.

[0020] In this way, various performance events of the process can be monitored simultaneously, so as to monitor the various performance events of the process more comprehensively.

[0021] In one possible implementation, the second process runs on a CPU core. The method further includes: when the CPU core is online, saving the sixth count result of a third counter, which is used to accumulate the number of times a third performance event occurs, and this third performance event is different from the first performance event; when the CPU core is offline, reading the seventh count result of the third counter; and determining the number of times the third performance event occurred on the CPU core based on the sixth and seventh count results. In this way, other counters can be used to monitor the performance events of the CPU core, providing a more comprehensive monitoring of the CPU core and processes. Here, the CPU core is the one running the second process. Optionally, the third counter is bound to the CPU core, or the third counter is set within the CPU core.

[0022] In one possible implementation, the first performance event includes, but is not limited to: process context switching; page fault; or CPU core migration. This implementation provides some examples of first performance events; in reality, there can be many different first performance events, and this is not limited to any one of them.

[0023] Secondly, embodiments of this application provide a performance event monitoring device. For example, the device includes a processing unit (sometimes also called a processing module) and a storage unit (also called a storage module). Optionally, the device further includes a communication unit (sometimes also called a communication module). The communication unit is used to perform transmit and receive operations, such as functions related to sending and receiving; the communication unit can be called a transceiver unit; optionally, the communication unit includes a receiving unit and a sending unit. The processing unit is used to perform processing operations. Alternatively, the communication unit can be a transmitter and a receiver, or a transmitter and a receiver.

[0024] The performance event monitoring device can be the computing device side described in the first aspect above, for example, it can be a computing device, or a module (e.g., a chip system) configured in a computing device. The performance event monitoring device includes corresponding means or modules for performing the first aspect or any possible implementation described above. For example, a storage unit is used to read and store a first count result of a first counter when the first process switches to a second process, wherein the first counter is used to accumulate the number of times the first performance event occurs; a processing unit is used to read a second count result of the first counter when the second process switches to a third process; and the processing unit is used to determine the number of times the first performance event occurs in the second process based on the first count result and the second count result.

[0025] In one possible implementation, the second process runs in the CPU core, wherein: the first counter is bound to the CPU core; or, the first counter is set in the CPU core.

[0026] In one possible implementation, the storage unit is further configured to: store a first counting result in a memory; and update the first counting result in the memory to a second counting result after determining the number of times the first performance event occurs in the second process.

[0027] In one possible implementation, the communication unit is configured to: before storing the first counting result of the first counter, acquire first monitoring information set by the user through a first interface, the first monitoring information indicating the first performance event of the second process being monitored; and after determining the number of times the first performance event occurs in the second process, provide feedback to the user through a second interface on the number of times the first performance event occurs in the second process.

[0028] In one possible implementation, the processing unit is further configured to: after determining the number of times the first performance event occurs in the second process, in the case of switching from the third process to the fourth process, read the third counting result of the first counter; and determine the number of times the first performance event occurs in the third process based on the third counting result and the second counting result.

[0029] In one possible implementation, the communication unit is configured to: before storing a first count result of a first counter, acquire second monitoring information set by the user through a first interface, the second monitoring information indicating a first performance event of a monitoring container, the container including a second process and a third process; and after determining the number of times the first performance event occurs in the second process, provide feedback to the user through the second interface on the number of times the first performance event occurs in the container, wherein the number of times the first performance event occurs in the container is the sum of the number of times the first performance event occurs in the second process and the number of times the first performance event occurs in the third process.

[0030] In one possible implementation, the storage unit is further configured to: store a fourth count result of a second counter while storing a first count result of a first counter, the second counter being used to accumulate the number of times a second performance event occurs, the second performance event being different from the first performance event; the processing unit is further configured to read a fifth count result of the second counter while reading a second count result of the first counter; the processing unit is configured to determine the number of times the second performance event occurs in the second process based on the fourth count result and the fifth count result.

[0031] In one possible implementation, the storage unit is further configured to: when the CPU core is online, save the sixth count result of the third counter, the third counter being used to accumulate the number of times the third performance event occurs, the third performance event being different from the first performance event; the processing unit is further configured to: when the CPU core is offline, read the seventh count result of the third counter; the processing unit is further configured to: determine the number of times the third performance event occurs on the CPU core based on the sixth count result and the seventh count result.

[0032] In one possible implementation, the first performance event includes: a process context switch; a page fault; or a CPU core migration.

[0033] Thirdly, embodiments of this application provide a performance event monitoring device. The performance event monitoring device may also be referred to as a computing device or performance event monitoring apparatus, etc., and its name is not specifically limited. The performance event monitoring device includes one or more processors. The one or more processors can execute computer programs or instructions stored in memory, and when the computer programs or instructions are executed, cause the performance event monitoring device to implement the method described in the first aspect or any possible implementation of the first aspect.

[0034] Optionally, the performance event monitoring device may include memory, in which case the memory may be coupled to one or more processors, or the memory may be configured relatively independently of one or more processors. Alternatively, the memory may exist independently of the performance event monitoring device.

[0035] In one possible design, the performance event monitoring device may further include an interface circuit, wherein the processor is used to communicate with other devices or components through the interface circuit.

[0036] The aforementioned performance event monitoring device may be a terminal device, or a communication module within a terminal device, or a chip in the terminal responsible for communication functions, such as a modem chip (also known as a baseband chip), or a SoC or SIP chip containing a modem module. Alternatively, the aforementioned performance event monitoring device may be an access network device, or a module within an access network device.

[0037] In the specific implementation process, the performance event monitoring device can be a chip, and the processor can be a transistor, gate circuit, flip-flop, and various logic circuits, etc. The specific implementation method of the processor is not limited in the embodiments of this application.

[0038] In one implementation, the performance event monitoring device can be a wireless communication device, i.e., a computer device that supports wireless communication functionality. Specifically, the wireless communication device can be a terminal device such as a smartphone, or a network device such as a wireless access network device (e.g., a base station).

[0039] In another implementation, the performance event monitoring device can be a component of a wireless communication device, such as an integrated circuit product like a system-on-a-chip (SoC) or communication chip. A SoC can also be called a System-on-a-Chip (SoC). A communication chip can include a baseband processing chip and a radio frequency (RF) processing chip. A baseband processing chip is sometimes called a modem or baseband chip. An RF processing chip is sometimes called an RF transceiver or RF chip. In physical implementation, some or all of the communication chip can be integrated within the SoC. For example, the baseband processing chip is integrated into the SoC, while the RF processing chip is not integrated. The interface circuit can be the RF processing chip in the wireless communication device, and the processor can be the baseband processing chip in the wireless communication device. The interface circuit can be an input / output interface, interface circuit, output circuit, input circuit, pin, or related circuit on the chip or chip system. The processor can also be a processing circuit or logic circuit.

[0040] In another implementation, the performance event monitoring device can be a chip system, which may consist of chips or include chips and other discrete devices. Chip systems may include, for example, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), system-on-chips (SoCs), CPUs, network processors (NPs), digital signal processors (DSPs), microcontroller units (MCUs), programmable logic devices (PLDs), or other integrated chips.

[0041] Fourthly, embodiments of this application provide a computer-readable storage medium. This computer-readable storage medium stores program instructions that, when executed on a computer, cause the computer to perform the methods described in the first aspect and any possible design of the embodiments of this application, or in the second aspect and any possible design. Exemplarily, the computer-readable storage medium can be any available medium accessible to a computer. For example, but not limited to, a computer-readable medium can include a non-transient computer-readable medium, random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), CD-ROM or other optical disk storage, magnetic disk storage media, or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer.

[0042] Fifthly, embodiments of this application provide a chip. The chip includes a processor coupled to a memory, configured to read and execute program instructions stored in the memory to enable the chip to implement the methods described in the first aspect or any possible design of the first aspect, or in the second aspect or any possible design of the second aspect.

[0043] Sixthly, embodiments of this application provide a computer-readable storage medium. This computer-readable storage medium is used to store a computer program or instructions that, when executed, implement the methods as described in the first aspect, any possible implementation of the first aspect, the second aspect, or any possible implementation of the second aspect.

[0044] In a seventh aspect, embodiments of this application provide a computer program product. When the computer program product is executed, it causes a processor to perform a method as described in the first aspect, any possible implementation of the first aspect, the second aspect, or any possible implementation of the second aspect. The computer program product includes a computer program and / or instructions, etc.

[0045] For the various aspects of the second to seventh aspects mentioned above, and the technical effects that each aspect may achieve, please refer to the above description of the technical effects that can be achieved for the first aspect or the various possible solutions in the first aspect, which will not be repeated here. Attached Figure Description

[0046] Figure 1 This is a schematic diagram illustrating a scenario applicable to an embodiment of this application;

[0047] Figure 2 This is a schematic diagram illustrating another scenario to which the embodiments of this application apply;

[0048] Figure 3 This is a schematic diagram of the structure of a computing device applicable to the embodiments of this application;

[0049] Figure 4 A schematic diagram of a CPU architecture provided for an embodiment of this application;

[0050] Figure 5 A schematic diagram of another CPU architecture provided for an embodiment of this application;

[0051] Figure 6 A schematic diagram illustrating the process of performance event monitoring using the perf tool;

[0052] Figure 7 A schematic diagram illustrating a performance event monitoring method provided in an embodiment of this application;

[0053] Figure 8 A schematic diagram of the counter counting process provided in the embodiments of this application. Figure 1 ;

[0054] Figure 9 A schematic diagram of the counter counting process provided in the embodiments of this application. Figure 2 ;

[0055] Figure 10 This is a schematic diagram of the structure of a performance event monitoring device provided in an embodiment of this application;

[0056] Figure 11 This is a schematic diagram of the structure of a performance event monitoring device provided in an embodiment of this application. Detailed Implementation

[0057] The embodiments of this application will now be described in further detail with reference to the accompanying drawings.

[0058] The various embodiments of this application can be applied to scenarios involving the monitoring of performance events (instances) of any computing device or cluster of computing devices. The computing device can also be replaced with or referred to as a performance event monitoring device or performance monitoring device, etc., and its name is not specifically limited.

[0059] A computing device refers to a device with computing capabilities. Examples of computing devices include terminal devices. A terminal device is a device with wireless transceiver capabilities, which can be a fixed device, mobile device, handheld device, wearable device, in-vehicle device, or a wireless device (e.g., a communication module or chip system) built into the aforementioned devices. These terminal devices are used to connect people, objects, and machines, and can be widely used in various scenarios, including but not limited to: cellular communication, device-to-device (D2D) communication, vehicle-to-everything (V2X) communication, machine-to-machine / machine-type communications (M2M / MTC) communication, Internet of Things (IoT), virtual reality (VR), augmented reality (AR), industrial control, self-driving, remote medical care, smart grid, smart furniture, smart office, smart wearables, smart transportation, smart city, drones, robots, and other similar scenarios. The terminal equipment may sometimes be referred to as user equipment (UE), terminal, access station, UE station, remote station, wireless communication equipment, or user device, etc. Computing devices include, for example, servers. Servers are generally used to provide services to users. For example, servers can provide storage services and / or computing services to users.

[0060] Performance events are events that reflect or measure at least one of the performance metrics of a computing device, a process running on that device, or a program installed on that device. A program is a collection of code and instructions written to accomplish a specific task. A process is an instance of program execution and is the basic unit for resource allocation and scheduling by the operating system. Performance events can be categorized into hardware events and software events based on the object they reflect. Hardware events include CPU-related events and cache events. CPU-related events monitor CPU-related performance events, such as CPU instruction count and CPU cycles. CPU instruction count refers to the number of instructions executed by the CPU within a given time period. A CPU cycle is the time unit required for a computing device to complete a basic operation, which may include stages such as instruction fetch, decode, execute, memory access, and write-back. Cache events include cache references and cache misses. Software events include process-related events, such as process context switching, page faults, or CPU core migration. Context switching refers to the process where, when multiple processes share the same CPU core, the CPU core runs different processes, switching the context information between the different processes. A page fault is an interrupt error issued by the central processing unit (such as the CPU's memory management unit) when software attempts to access a page that is mapped in the virtual address space but is not currently loaded into physical memory. CPU core migration, also known as CPU migration, refers to a process being mistakenly run on one CPU core instead of another. Monitoring performance events is crucial for performance analysis, debugging, power management, and software performance optimization of at least one of the following: computing devices, processes, or programs. For example, it can help developers and system administrators gain a deeper understanding of system behavior, enabling effective performance optimization. Specifically, measuring instruction counts and cache hit rates can help identify program performance bottlenecks and allow for tuning accordingly.

[0061] In the various embodiments of this application, the number of nouns, unless otherwise specified, refers to "singular nouns or plural nouns," that is, "one or more." "At least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. For example, A / B means: A or B. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of singular or plural items. For example, at least one of a, b, or c means: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c can be single or multiple.

[0062] In addition, in the embodiments of this application, words such as "exemplarily," "for example," "likely," "optional," "possible implementation," "possible mode of implementation," or "possible design" are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as an "example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the term "example" is intended to present concepts in a concrete manner. In the embodiments of this application, "of," "corresponding / relevant," and "corresponding" may sometimes be used interchangeably, and it should be noted that their intended meanings are consistent unless their distinction is emphasized.

[0063] The following examples illustrate the scenarios in which the performance event monitoring scheme provided in this application is applicable.

[0064] Figure 1 The diagram illustrates a scenario to which the embodiments of this application are applicable. For example... Figure 1 As shown, this scenario includes a computing device corresponding to the user. The user can directly operate the computing device, which performs performance event monitoring. Optionally, the computing device can also provide feedback on the performance event monitoring results to the user, such as displaying the monitoring results so that the user can intuitively see the event monitoring outcome.

[0065] Figure 2 This diagram illustrates another scenario to which the embodiments of this application are applicable. For example... Figure 2 As shown, this scenario includes a cloud platform and at least one user device. A cloud platform can also be referred to as the cloud itself, a computing device cluster, or simply the cloud. A cloud platform can correspond to a cloud provider; in other words, the cloud provider manages the cloud platform.

[0066] For example, application providers can deploy applications on a cloud platform. In other words, applications can rely on the resources of the cloud platform to run. Users can operate at least one user device to access the application and use the services provided by the application. The user device can be, for example, a terminal device. The cloud platform can include at least one computing device. Any two computing devices in the at least one computing device can communicate with each other. Any computation in the at least one computing device can perform performance event monitoring. Optionally, the computing device can also provide feedback on performance event monitoring results to the user through the user device. For example, the computing device sends the performance event monitoring results to the user device, and the user device presents the performance event monitoring results, so that the user can intuitively see the performance event monitoring results.

[0067] Figure 2 The example uses two user devices as the basis for the definition of at least one user device, but there is no actual limitation on the number of user devices included in at least one user device. Figure 2 The example given is that the cloud platform includes two computing devices, but there is no actual limit to the number of computing devices included in a cloud platform.

[0068] The following is combined Figure 3 The diagram shown illustrates the structure of a computing device, and provides an example of its structure. Figure 3 The computing devices involved are, for example, Figure 1 The computing devices involved are, or are Figure 2 Any computing device involved. Figure 3 This illustrates the main hardware structure of a computing device. For example... Figure 3 As shown, a computing device may include one or more CPUs, memory, input devices, and output devices. Figure 3 Taking a computing device that includes two CPUs, CPU1 and CPU2, as an example, there is actually no limit to the number of CPUs included in a computing device.

[0069] The CPU is the core component of a computing device. The CPU can run processes and also call output devices to display performance data. Memory is the storage device in a computer system used to store programs and data. For example, memory can be used to store the monitoring results of performance events. Memory includes main memory (RAM), which can directly interact with the CPU. Input devices are used to input data and information into the computing device. Memory can be coupled to the CPU or set up relatively independently. Memory can store circuits, memory chips, storage devices (or storage units), or registers, etc. Input devices act as a bridge for communication between the computer and the user or other devices. For example, input devices provide input entry points for the user. Output devices are used to receive computer data for output display, printing, sound, and control of peripheral devices; that is, to represent various calculation results or information in the form of numbers, characters, images, sounds, etc. For example, output devices can be responsible for displaying the monitoring results of performance events to the user according to the CPU's requirements.

[0070] Please refer to Figure 4 This is a schematic diagram of the architecture of a computing device provided in an embodiment of this application. Figure 4 This mainly illustrates the overall architecture of the computing device. Compared to Figure 3 , Figure 4 It illustrates the hardware and software distribution in a computing device. Figure 4 The computing devices involved are, for example, Figure 3 The computing devices involved.

[0071] like Figure 4 As shown, computing devices can be divided into three parts: user mode, kernel mode, and hardware. These three parts will be introduced below.

[0072] User mode, also known as user space, is primarily used for executing user-side programs, including areas where processes or threads reside. Figure 4 As shown, processes 1 through 5 are running in user space. Processes 1 and 2 belong to container 1, and processes 3 through 5 belong to container 2. A container contains one or more processes. Processes running in different containers do not affect each other. In short, containers can achieve process isolation and limit the resources used by processes (such as processing resources and / or storage resources).

[0073] Kernel mode, also known as kernel space, is primarily responsible for running the system and accessing hardware. For example... Figure 4As shown, the kernel mode includes a scheduling module and a performance acquisition module (also known as a performance monitoring module or performance event monitoring module, etc.). The scheduling module is mainly responsible for scheduling on a thread-by-thread basis, such as scheduling a specific CPU core to run a specific thread. The performance acquisition module is responsible for performance event monitoring, including performance acquisition logic and reading and writing the monitoring results of performance events. The kernel mode can interact with the user mode through one or more interfaces, which can be called one or more user-mode interfaces or one or more configuration interfaces; their names are not limited. The scheduling module and performance acquisition module can be implemented in software, such as program code set in the operating system, for example, set in the kernel software framework of the operating system. Specifically, the program code corresponding to the scheduling module and performance acquisition module can exist in the operating system kernel and in the interfaces exposed by the kernel to the user mode. At runtime, the program code corresponding to the scheduling module and performance acquisition module is stored in the CPU's memory. Alternatively, the scheduling module and performance acquisition module can also be implemented in hardware or a combination of hardware and software; their implementation forms are not specifically limited.

[0074] In one possible implementation, the performance acquisition module may include one or more counters. These counters have a counting function; for example, they may be modules with counting capabilities within a monitoring instance, or alternatively, they may be described as monitoring instances or monitoring events. The performance acquisition module monitors performance events through these one or more counters. Figure 4 The example given uses a performance acquisition module with three counters, but the actual number of counters is not limited. One or more counters can be bound to the CPU core, or described as one or more counters registered within the CPU core. This can be understood as these one or more counters being used to monitor the CPU core and / or processes running on it. These one or more counters can be implemented in software, such as through software code. Optionally, these one or more counters can be divided into general-purpose counters and dedicated counters. Dedicated counters monitor specific performance events; for example, proprietary counters might monitor the number of CPU instructions. General-purpose counters can monitor various performance events. In another possible implementation, the performance acquisition module and the one or more counters can be set relatively independently, and the performance acquisition module and the one or more counters can communicate with each other. Figure 4 The example given is a performance acquisition module including counters; however, the actual configuration of the performance acquisition module and one or more counters is not limited. Regardless of the configuration, the performance acquisition module can read the counting results of one or more counters.

[0075] Hardware includes CPUs, etc. A CPU may include one or more CPU cores, which may also be called the CPU core, CPU physical core, or physical core, etc., without specific limitations on the name. Figure 4 This example uses a CPU with a single CPU core, but the actual number of cores in a CPU is not limited. Each CPU core includes a controller and an arithmetic logic unit (ALU). Optionally, a CPU core may also include a performance monitoring unit (PMU).

[0076] The controller is the control center of the entire computing device. It coordinates the work of various parts of the device, ensuring that it operates and processes data according to pre-defined goals and procedures. The arithmetic logic unit (ALU) can be implemented using digital logic circuits. The ALU performs arithmetic or bitwise operations on binary numbers. A CPU core may contain one or more ALUs. The ALU includes an arithmetic logic unit, an accumulator (such as an accumulator register), a status register, and a general-purpose register set. The arithmetic logic unit performs arithmetic and logical operations. The accumulator stores the calculation results. The status register retains various status information generated by the ALU. The general-purpose registers store operation data and various address information. The performance monitoring unit (PMU) is a built-in performance monitoring module of the CPU. The PMU can control the performance monitor counter (PMC) to count performance events through registers.

[0077] Please refer to Figure 5 This is a schematic diagram of the architecture of a computing device provided in an embodiment of this application. Compared to Figure 4 , Figure 5 The kernel-mode performance acquisition module of the computing device in the middle does not have a counter set. Figure 5 The computing devices involved are, for example, Figure 3 The computing devices involved.

[0078] like Figure 5 As shown, computing devices can be divided into three parts: user mode, kernel mode, and hardware. The content of user mode can be found in the previous text. Figure 4 The content discussed in the user-mode section will not be repeated here. User-mode can interact with kernel-mode through one or more interfaces. Figure 5 The performance acquisition module does not include a counter; the computing device determines the performance event count by reading the counter in the CPU core. In addition, Figure 5 All other kernel-mode content shown can be referenced. Figure 4 The kernel state content discussed will not be listed here.

[0079] Hardware includes CPUs, etc. A CPU may include one or more CPU cores, which may also be called the CPU core, CPU physical core, or physical core, etc., without specific limitations on the name. Figure 5 The example given is a CPU with CPU core 1, CPU core 2, CPU core 3, and CPU core 4; however, the actual number of cores a CPU can have is not limited. Each CPU core includes a controller, an ALU, and a PMU.

[0080] The contents of the controller and ALU can be found in the previous text. Figure 4 This section discusses the controller and ALU. The PMU (Power Management Unit) is a performance monitoring module built into the CPU, which controls the counting of performance events through registers. The performance acquisition module in kernel mode can interface with the PMU to obtain the performance event count results.

[0081] The PMU includes one or more counters. Figure 5 The counter shown can be a software and / or hardware implemented counter. Figure 5 The example provided uses a PMU with three counters, but the actual number of counters is not limited. Optionally, the performance acquisition module in kernel mode can interface with the counters to obtain the counter count results for performance events. Optionally, any one of these one or more counters can be a PMC, or an integrated circuit with counting functionality set in the PMU. Figure 5 The example given uses a PMU (Power Management Unit) with one or more counters located within the CPU core. However, these counters can also be set up independently of the PMU within the CPU core; the specific configuration method is not limited. Optionally, the PMU may also include one or more memories. These memories can be set up separately within the one or more counters, or they can be set up relatively independently of the one or more counters. These memories can store circuits, memory chips, or registers, etc.

[0082] Optionally, these one or more counters can be categorized into general-purpose counters and dedicated counters. Dedicated counters monitor specific performance events; for example, a dedicated counter might be used to monitor the number of CPU instructions. General-purpose counters can monitor a wide variety of performance events.

[0083] The architecture and scenarios described in this application are intended to more clearly illustrate the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0084] In Linux kernel operating systems, the `perf` tool is typically used for performance event monitoring. `perf` collects performance data in units of "events," creating a `perf` event for each performance event to be collected. `perf` events are divided into process events and CPU events. CPU events refer to events registered by the `perf` tool with the CPU, used to monitor the corresponding CPU performance events. These events are activated when the CPU core is online and paused when the CPU core is offline. For example, a CPU core in a powered-on state (e.g., active (C0), suspended, or sleeping) can be considered online. A CPU core in a powered-off state can be considered offline. Process events refer to events registered by the `perf` tool with processes, used to monitor the corresponding process performance events. These events are activated when the process is running and paused when the process is not running.

[0085] When monitoring performance events corresponding to a process, the process events are strongly correlated with the process. In cases such as process switching, it is necessary to read and save the context information of the process events so that when switching back to the process, the context information can be read and written again to continue monitoring the performance events. The context information of process events includes, for example, the program counter, registers, and memory pointers. Therefore, the context information of process events is quite extensive and the data structure is complex, resulting in a significant processing overhead for monitoring process performance events.

[0086] The following is combined Figure 6 The diagram illustrates a process for performance event monitoring based on the perf tool, and is presented as an example. Figure 6 This is an example of execution by a computing device.

[0087] S601. At time t1, the computing device starts process event 1, and process event 1 monitors the performance event a of process 1.

[0088] S602. At time t2, process 1 switches to process 2, the computing device reads and stores the context information of process event 1, and closes process event 1.

[0089] S603. At time t2, the computing device also starts process event 2, which monitors the performance event a of process 2.

[0090] S604. At time t3, process 2 switches to process 1, the computing device reads and stores the context information of process event 2, and closes process event 2.

[0091] S603. At time t3, the computing device also starts process event 1 based on the context information of process event 1.

[0092] As can be seen, computing devices frequently switch between process events, and consequently frequently read and store the context information of process events, resulting in a relatively large processing overhead for performance monitoring.

[0093] In view of this, embodiments of this application provide a performance event monitoring scheme. In this scheme, a counter (such as a first counter) is associated with a performance event (such as a first performance event). The first counter is not bound to any specific process. When switching from a first process to a second process, it is equivalent to starting the second process. The count result of the first counter is read and stored. When switching the running process from the second process to another process (such as a third process), the count result of the first counter is stored. Based on the two count results, the number of times the first performance event occurs in the second process is determined. There is no need to switch process events, and therefore no need to read and store the context information of the process event, thereby reducing the processing overhead of monitoring performance events. Furthermore, when monitoring performance events, the control reads the counter's count result without having to read or load the context information of the process event, which helps to reduce the complexity of monitoring performance events.

[0094] The performance event monitoring scheme provided by the embodiments of this application is described below with reference to the accompanying drawings. In the accompanying drawings corresponding to the various embodiments of this application, all steps indicated by dashed lines are optional steps. Furthermore, the computing devices involved in the various embodiments of this application are, for example, [missing information - likely related to computing devices]. Figures 1 to 5 The computing devices involved, such as CPUs, are Figures 3 to 5 Any CPU involved in the process, such as a CPU core. Figure 4 or Figure 5 For any CPU core involved, the first interface or the second interface is, for example, Figure 4 or Figure 5 The interfaces involved, the first process, the second process, the third process, and the fourth process can be... Figure 4 or Figure 5 For any process involved, the first counter, the second counter, or the third counter can be Figure 4 or Figure 5 For any of the counters involved, the scheduling module is, for example, Figure 4 or Figure 5 The scheduling module and performance acquisition module involved are, for example, Figure 4 or Figure 5 The performance acquisition module involved may have a memory that can be... Figures 3 to 5 Any of the mentioned memory locations.

[0095] Figure 7 This application illustrates a performance event monitoring method provided by an embodiment of the present application. The following section details... Figure 7 The steps involved will be described.

[0096] S701, when switching from the first process to the second process, the computing device reads the first counting result of the first counter stored in the memory. The first counter is used to accumulate the number of times the first performance event occurs. The first process and the second process are different. In this embodiment, the process runs in a CPU core. In this embodiment, switching from process A to process B refers to the process switching involved in the same CPU core, where process A and process B are two different processes. Furthermore, switching from process A to process B can be understood as the process running on a certain CPU core switching from process A to process B, or the computing device scheduling the process running on the CPU core to switch from process A to process B.

[0097] Before performing performance event monitoring, computing devices need to determine the objects to be monitored and which performance events of those objects will be monitored. Objects may include processes, CPUs, or containers (or process groups). The following describes how computing devices determine the objects to be monitored and their performance events.

[0098] Method 1: The computing device obtains first monitoring information and / or second monitoring information from the user.

[0099] For example, the computing device provides a first interface to a user, through which the user can configure or set first monitoring information and / or second monitoring information. Alternatively, the computing device provides a first interface to a user device, through which the user can configure or set the first monitoring information and / or second monitoring information. Optionally, the computing device can also determine whether the format of the first monitoring information and / or the format of the second monitoring information is correct. If the format of the first monitoring information and / or the format of the second monitoring information is incorrect, the computing device outputs a prompt message prompting the user to re-enter the monitoring information in the correct format. If the format of the first monitoring information and / or the format of the second monitoring information is correct, the computing device continues with subsequent steps. This ensures that the format of the first monitoring information and / or the second monitoring information is correct.

[0100] Both the first and second monitoring information are used to indicate the performance events of the object to be monitored. For example, both the first and second monitoring information include information about the object that the user wants to monitor, and which performance events the object to be monitored are.

[0101] In this embodiment, the example uses first monitoring information to indicate a first performance event of a second process. For instance, the first monitoring information includes information about the second process, such as the identifier of the second process, and the first performance event corresponding to the second process, such as the identifier (or index or number) of the first performance event. For example, the first monitoring information includes: 0111, where "01" is the identifier of the second process and "11" is the identifier of the first performance event. The first performance event can be a software event, such as a process-related event, specifically such as context switching, page faults, or CPU core migration. The content of context switching, page faults, and CPU core migration can be referred to the previously discussed content on context switching, page faults, and CPU core migration, and will not be listed here.

[0102] In this embodiment, the second monitoring information is used to indicate a first performance event of the monitored container. For example, the second monitoring information includes container information, such as the container's identifier or the identifiers of the processes included in the container, and the first performance event corresponding to the container. In this embodiment, the container includes a second process and a third process, but the number of processes included in the container is not actually limited. For example, the second monitoring information includes: 1011, where "10" is the container's identifier and "11" represents the first performance event.

[0103] Thus, the computing device can obtain first monitoring information and / or second monitoring information through the first interface.

[0104] Optionally, the first monitoring information and / or the second monitoring information may also include time information, which indicates a monitoring time period. The monitoring time period refers to the time during which performance events are monitored on the object. The time information may indicate at least two of the following: the start time, the end time, or the duration of performance event monitoring on the object. At least two of the start time, the end time, or the duration are used to determine the monitoring time period. Optionally, the time information may also include a monitoring cycle. The monitoring cycle refers to the time interval between two adjacent monitoring time periods, such as the time interval between the end time of the previous monitoring time period and the start time of the next monitoring time period.

[0105] In one possible design, the first monitoring information also instructs the monitoring of other performance events of the second process, and / or the second monitoring information also instructs the monitoring of other performance events of the container. Other performance events refer to one or more performance events besides the first performance event, such as a second performance event. The second performance event differs from the first performance event. The second performance event can be a software event, such as a process-related event. For example, the first performance event might be a context switch, and the second performance event might be a page fault. Or, for instance, the first performance event might be a page fault, and the second performance event might also be a page fault, etc.

[0106] Method 2: The computing device is pre-configured with first monitoring information and / or second monitoring information. Alternatively, it can be described that the computing device monitors the first performance event of the second process by default, and / or monitors the first performance event of the container by default. The content of the first and second monitoring information can refer to the content of the first and second monitoring information discussed above, and will not be listed here.

[0107] Method 3: The computing device may be pre-configured with a portion of the first monitoring information and obtain another portion of the first monitoring information from the user. And / or, the computing device may be pre-configured with a portion of the second monitoring information and obtain another portion of the second monitoring information from the user. For example, the computing device may by default monitor a second process and obtain performance events related to monitoring the second process from the user, such as the first performance event.

[0108] Optionally, the computing device obtains third monitoring information from the user, or is pre-configured with third monitoring information. The third monitoring information indicates the monitoring of third performance events of the CPU core. The third performance event differs from both the first and second performance events. The third performance event can be a hardware event, such as a CPU-related event, specifically such as the number of CPU instructions or CPU cycles. The content of the number of CPU instructions and CPU cycles can be found in the previous discussion of the content of the number of CPU instructions and CPU cycles, and will not be listed here again.

[0109] The computing device can acquire different monitoring information in different ways. For example, the computing device can acquire the first monitoring information from the user, or the computing device can be pre-configured with the second monitoring information. There are no specific limitations on this.

[0110] Regardless of which method from Method 1 to Method 3 is used, the computing device can determine the object to be monitored and the performance events of the object to be monitored based on the acquired monitoring information (such as first monitoring information and / or second monitoring information, and may also include third monitoring information).

[0111] The computing device can control the start of the counter based on the content of the first monitoring information and / or the second monitoring information, as illustrated below.

[0112] When the computing device acquires the first monitoring information, it can control the first counter to accumulate the number of times the first performance event occurs, or in other words, control the first counter to accumulate the number of times the first performance event occurs. This can be understood as the first counter being used to accumulate the number of times the first performance event occurs, which can be interpreted as the first counter being bound, associated, or related to the first performance event.

[0113] Optionally, the computing device can also bind the first counter to a CPU core. For example, if the first counter resides in kernel mode, the computing device can control the first counter to accumulate first performance events occurring in processes running on the CPU core, so that the first counter counts according to the CPU core's operating status. Alternatively, the first counter can be pre-bound to the CPU core. Or, if the first counter resides in the CPU core, the computing device can directly start the first counter.

[0114] If the first monitoring information also indicates that a second performance event of the second process should be monitored, then the computing device can also control the second counter to accumulate the number of times the second performance event occurs, or in other words, control the second counter to accumulate the number of times the second performance event occurs. This can be understood as the second counter being used to accumulate the number of times the second performance event occurs; this can be understood as the second counter being bound, associated, or related to the second performance event.

[0115] When the computing device acquires the second monitoring information, it controls the first counter to accumulate the first performance event. Optionally, the computing device can also bind the first counter to a CPU core. The method of binding the first counter to a CPU core can be referred to the previous discussion on binding the first counter to a CPU core, and will not be listed here. Alternatively, the first counter can be pre-bound to a CPU core.

[0116] If the computing device acquires third monitoring information, it can also control a third counter to accumulate third performance events. Optionally, the computing device can also bind the third counter to a CPU core. The method of binding the third counter to a CPU core can be referred to the previous discussion on binding the third counter to a CPU core, and will not be listed here. Alternatively, the third counter can be pre-bound to a CPU core. Or, if the third counter is located in the CPU core, the computing device can directly start the third counter.

[0117] The computing device starts the CPU core and schedules it to run an initial process, or it schedules the CPU core to switch from another business-related process (e.g., the first process) to a second process. For example, the computing device can schedule the CPU core to run a second process through a scheduling module, which is equivalent to the CPU core switching from the first process to the second process. The computing device can read and store the current counting result of the first counter, i.e., the first counting result. The first process may be the initial process or a business-related process, and this is not limited. For example, the performance acquisition module can obtain the first counting result from the first counter. The counting result involved in the embodiments of this application can also be called a counting value, for example, the first counting result can also be called the first counting value. For example, the computing device can store the first counting result in the computing device's memory, such as in RAM.

[0118] If the computing device switches from the first process (e.g., the initial process) to the second process, the first count result of the first counter can be the initial value, such as 0. If the computing device schedules the CPU core to switch from the first process to the second process, the first count result of the first counter may be the initial value or a non-initial value. For example, if the first counter has not accumulated the number of occurrences of the first performance event before the second process starts running, or if the first counter has accumulated the number of occurrences of the first performance event before the second process starts running, but the number of occurrences of the first performance event is 0, then the first count result can be the initial value. Alternatively, if the first counter has accumulated the number of occurrences of the first performance event before the second process starts running, and the first performance event has occurred at least once, then the first count result can be a non-initial value. In short, the specific value of the first count result can have multiple possibilities, and no specific limitation is made.

[0119] If the computing device starts up the CPU core, it means the CPU core has come online. If the computing device acquires third monitoring information, optionally, the computing device can also read and store the current counting result of the third counter, i.e., the sixth counting result. The sixth counting result can be the initial value.

[0120] In one possible implementation, if the first monitoring information also indicates monitoring of a second performance event of the second process, when the computing device begins scheduling the CPU core to run the second process, the computing device reads and stores the current counting result of the second counter, i.e., the fourth counting result. The fourth counting result can be an initial value or a non-initial value.

[0121] S702, when switching from the second process to the third process, the computing device reads the second count result of the first counter. The second process and the third process are different.

[0122] During the monitoring of the first performance event, each time the first performance event occurs, the computing device increments the first counter by 1, which is equivalent to accumulating the number of times the first performance event has occurred. For example, if the first performance event is a context switch, the computing device increments the first counter by 1 each time a context switch is detected. Similarly, if the first performance event is a page fault, the computing device increments the first counter by 1 each time a page fault is detected. If the first performance event is a CPU core migration, the computing device increments the first counter by 1 each time a CPU core migration is detected. This continues until a process switch occurs, such as switching the second process scheduled to run on the CPU core to a third process. In this case, the computing device can read the current count result of the first counter, which is the second count result. For example, the performance acquisition module can obtain the second count result from the first counter. It should be noted that while context switching occurs when switching processes, it can also occur in other situations, such as context anomalies in the computing device's memory. The specific causes of context switching are not limited.

[0123] In one possible implementation, if the first monitoring information also indicates monitoring for a second performance event of the second process, then during the monitoring of the second performance event, each occurrence of the second performance event is incremented by 1, equivalent to the second counter accumulating the number of occurrences of the second performance event. For example, if the second performance event is a page fault, the computing device increments the first counter by 1 each time a page fault is detected. This continues until a process switch occurs, such as switching the scheduled second process to a third process, which is equivalent to the CPU core switching from running the second process to running the third process. At this point, the computing device can read the current count result of the second counter, i.e., the fifth count result.

[0124] S703. The computing device determines the number of times the first performance event occurs in the second process based on the first counting result and the second counting result.

[0125] Since the first counter is used to accumulate the number of occurrences of the first performance event, and the CPU core only runs the second process during the period from switching from the first process to the second process until switching the second process to the third process, the computing device can determine the number of times the first performance event occurred in the second process, for example, by the difference between the second and first counts. This is equivalent to obtaining the number of times the second process experienced the first performance event during the period when the CPU core was running the second process. Optionally, the computing device can also provide feedback to the user on the number of times the second process experienced the first performance event through the second interface. If the first monitoring information also indicates a monitoring period, then by analogy, the computing device can accumulate the number of times the second process experienced the first performance event during the monitoring period and provide feedback to the user on the accumulated number of times the second process experienced the first performance event during the monitoring period.

[0126] Optionally, the computing device may also store the second counting result and delete the first counting result. For example, if the first counting result is stored in memory, the computing device can update the first counting result in memory with the second counting result. For instance, the computing device can write the second counting result in an overwrite manner, specifically by directly overwriting the storage location of the first counting result in memory with the second counting result. Alternatively, the computing device can write the second counting result in a clear write manner, for example, by first deleting the first counting result and then writing the second counting result into memory. This helps to reduce the storage space occupied by the counting results.

[0127] The following is combined Figure 8 The diagram illustrating the counter counting process serves as an example of the performance event monitoring involved in the embodiments of this application. For example... Figure 8 As shown, the computing device determines that at time t1, it switches from the first process to the second process, and reads and stores the first count result of the first counter as 0. The computing device detects a first performance event at time t2, and the first counter increments by 1, bringing the count result to 1. The computing device detects another first performance event at time t3, and the first counter increments by 1, bringing the count result to 2. The computing device detects another first performance event at time t4, and the first counter increments by 1, bringing the count result to 3. At time t5, the second process switches to the third process, and the computing device reads the second count result of the first counter, which is 3. Therefore, the computing device determines that between times t1 and t5, the number of times the second process experiences the first performance event is the difference between the second and first count results, which is 3.

[0128] In one possible implementation, if the first monitoring information also indicates monitoring of a second performance event of the second process, the computing device determines the number of times the second performance event occurs in the second process based on the fourth and fifth counting results. For example, the number of times the second performance event occurs in the second process is the difference between the fifth and fourth counting results. Optionally, the computing device can also provide feedback to the user on the number of times the second performance event occurs in the second process through a second interface. If the first monitoring information also indicates a monitoring period, the computing device can accumulate the number of times the second performance event occurs in the second process during the monitoring period and provide feedback to the user on the accumulated number of times the second performance event occurs in the second process during the monitoring period. Optionally, the computing device can also store the fifth counting result, and optionally, it can also delete the fourth counting result. For example, the computing device can update the fourth counting result in memory with the fifth counting result. The method of updating the fourth counting result with the fifth counting result can refer to the content of updating the first counting result with the second counting result discussed above, and will not be listed here.

[0129] Continue to refer to Figure 8 The computing device determines that the second process will begin running at time t1, and reads and stores the fourth count result of the second counter as 1. At time t4, the computing device detects a first performance event, and the second counter increments by 1, bringing its count to 2. At time t5, the second process switches to the third process, and the computing device reads the fifth count result of the second counter, which is also 2. Therefore, the computing device determines that between times t1 and t5, the number of times the second performance event occurs in the second process is the difference between the fifth and fourth count results, which is 1.

[0130] After the computing device schedules the CPU core to run the third process, and with the computing device acquiring the second monitoring information, the first counter is incremented by 1 for each occurrence of the first performance event. For example, if the first performance event is a context switch, the computing device increments the first counter by 1 each time a context switch is detected. This continues until the third process is switched to another process (such as the fourth process), at which point the current count of the first counter is read, i.e., the third count result. Since the first counter is used to accumulate the number of occurrences of the first performance event, and the CPU core only runs the third process during the period from switching from the second process to the third process until switching from the third process to the fourth process, the computing device can determine the number of times the first performance event occurred in the third process. The difference between the third count result and the second count result is equivalent to obtaining the number of times the first performance event occurred in the third process during the period when the CPU core was scheduled to run the third process. The fourth process is different from the third process. The fourth process and the first process may be the same or different; this is not limited.

[0131] Optionally, the computing device may also store a third counting result, and optionally, delete the second counting result. For example, the computing device updates the second counting result stored in memory with the third counting result. The method of updating the second counting result with the third counting result can refer to the content of updating the first counting result with the second counting result discussed above, and will not be listed here.

[0132] Furthermore, the computing device can determine the number of times the first performance event occurred in the container by summing the number of times the first performance event occurred in the second process and the number of times the first performance event occurred in the third process. Optionally, the computing device can also provide feedback to the user on the number of times the second performance event occurred in the container through a second interface.

[0133] Continue to refer to Figure 8 After the computing device schedules and runs the third process at time t5, it detects a first performance event at time t6, incrementing the first counter by 1, bringing the total count to 4. At time t7, it detects another first performance event, incrementing the first counter by 1, bringing the total count to 5. At time t8, the third process switches to the fourth process, and the computing device reads the third count from the first counter, which is 5. Therefore, the computing device determines that between times t1 and t5, the number of times the second process experiences the first performance event is the difference between the third and second counts, which is 2.

[0134] When the computing device acquires third monitoring information, after the CPU core comes online, the third counter increments by 1 for each occurrence of a third performance event, effectively accumulating the number of times the third performance event has occurred. For example, if the third performance event is a CPU instruction, the computing device increments the third counter by 1 each time it detects the CPU core executing an instruction. This continues until the CPU core goes offline, at which point the current count result of the third counter is read, i.e., the seventh count result. The computing device can then determine the number of times the third performance event has occurred for the CPU core based on the sixth and seventh count results. Optionally, if the CPU comprises multiple CPU cores, the computing device can add the counts of third performance events occurring for all CPU cores to obtain the total number of third performance events occurring for the CPU. Optionally, the computing device can also store the seventh count result, and optionally, it can also delete the sixth count result. For example, the computing device can update the sixth count result in memory to the seventh count result. The method for updating the sixth count result to the seventh count result is similar to the previously discussed method for updating the stored first count result to the second count result, and will not be listed here.

[0135] The following is combined Figure 9 The diagram shown illustrates the counting process of the third counter, and an example is provided to illustrate this process. For instance... Figure 9As shown, the computing device determines that the CPU core comes online at time t1, and reads and stores the sixth count result of the third counter as 1. The computing device detects a third performance event at time t2, increments the third counter by 1, and the count result of the third counter is now 2. The computing device detects another third performance event at time t3, increments the third counter by 1, and the count result of the third counter is now 3. The computing device detects that the CPU core goes offline at time t4, and reads the seventh count result of the third counter, which is 3. Therefore, the computing device determines that the number of times the CPU core experiences a third performance event between times t1 and t4 is the difference between the seventh and sixth count results, which is 2.

[0136] In one possible implementation, Figure 7 The steps shown can be executed in the kernel mode of the operating system in the computing device. For example, they can be executed by the performance acquisition module in the kernel mode. The process of the performance acquisition module executing the performance event monitoring method can be referred to the content of the computing device executing the performance event monitoring method above, and will not be listed one by one here.

[0137] In this embodiment, a counter can be used to count performance events without requiring scheduling switches. When the context of the scheduling process switches, the counter does not need to switch with the process, thus avoiding the overhead of switching. Furthermore, the solution provided in this embodiment can be applied to performance collection of all objects, including processes, containers, and CPU cores, achieving low-overhead and comprehensive performance event monitoring. Also, because the overhead of performance event monitoring in this embodiment is relatively small, it reduces the impact of performance event monitoring on processes executing business logic, reduces the resources consumed by performance event monitoring, and facilitates more accurate monitoring of performance events.

[0138] Based on the same inventive concept, embodiments of this application provide a performance event monitoring device. Please refer to... Figure 10 This is a schematic diagram of a performance event monitoring device provided in an embodiment of this application. The performance event monitoring device 1000 can be used to implement the functions of any of the aforementioned computing devices, and correspondingly, can also execute the steps performed by the aforementioned computing devices.

[0139] like Figure 10 As shown, the performance event monitoring device 1000 includes a processing unit 1001 and a storage unit 1003. The processing unit 1001 and the storage unit 1003 can be coupled together. Optionally, the performance event monitoring device 1000 also includes a communication unit 1002.

[0140] The processing unit 1001, communication unit 1002, and storage unit 1003 can all be implemented in software or in hardware. For example, the implementation of processing unit 1001 will be described below. Similarly, the implementation of communication unit 1002 and storage unit 1003 can refer to the implementation of processing unit 1001.

[0141] As an example of a software functional unit, the processing unit 1001 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, or a container. Further, there may be one or more computing instances. For example, the processing unit 1001 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0142] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0143] As an example of a hardware functional unit, the processing unit 1001 may include at least one computing device, such as a server. Alternatively, the processing unit 1001 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0144] The processing unit 1001 includes multiple computing devices that can be distributed in the same region or in different regions. Similarly, the processing unit 1001 includes multiple computing devices that can be distributed in the same Availability Zone (AZ) or in different AZs. Likewise, the processing unit 1001 includes multiple computing devices that can be distributed in the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0145] For example, the performance event monitoring device 1000 can perform actions such as Figure 7 The method embodiment shown illustrates a performance event monitoring method. For example, storage unit 1003 can execute the steps described in S701 above, and processing unit 1001 is used to execute steps S702 and S703, which will not be listed here. Communication unit 1002 can, for example, acquire monitoring information, such as first monitoring information and / or second monitoring information.

[0146] In one possible implementation, the processing unit 1001 may include, for example, the aforementioned... Figure 4 or Figure 5 The discussion covers the scheduling module and performance acquisition module, among others.

[0147] Based on the same inventive concept, embodiments of this application provide a performance event monitoring device, which may also be referred to as a computing device. Please refer to... Figure 11 This is a schematic diagram of the structure of a performance event monitoring device 1100 provided in an embodiment of this application. The performance event monitoring device 1100 can be used to implement the functions of any of the computing devices described above, and correspondingly, can also execute the steps performed by the computing devices described above. For example... Figure 11 As shown, the performance event monitoring device 1100 includes a processor 1101 and a memory 1102. Optionally, the performance event monitoring device 1100 also includes a communication interface 1103.

[0148] The processor 1101, memory 1102, and communication interface 1103 can communicate via a bus. The performance event monitoring device 1100 can be a server or a terminal device. It should be understood that the embodiments of this application do not limit the number of processors and memories in the performance event monitoring device 1100.

[0149] The bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be categorized as an address bus, data bus, control bus, etc. The bus can include pathways for transmitting information between various components of the performance event monitoring device 1100 (e.g., processor 1101, memory 1102, and communication interface 1103).

[0150] Processor 1101 may include any one or more of the following processors: central processing unit (CPU), graphics processing unit (GPU), microprocessor (MP), or digital signal processor (DSP).

[0151] Memory 1102 may include volatile memory, such as random access memory (RAM). Memory 1102 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0152] The memory 1102 stores executable program code, and the processor 1101 executes the executable program code to implement the aforementioned functions. Figure 10 The performance event monitoring device 1000 in the middle can perform the functions of any of the performance event monitoring methods mentioned above, such as... Figure 7 The performance event monitoring method shown in the method embodiment. That is, the memory 1102 stores instructions for executing any performance event monitoring method.

[0153] Alternatively, the memory 1102 may store executable code, which the processor 1101 executes to implement the functions of the aforementioned performance event monitoring devices, thereby implementing any of the performance event monitoring methods described above. That is, the memory 1102 may store instructions for executing any of the aforementioned performance event monitoring methods.

[0154] The communication interface 1103 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the performance event monitoring device 1100 and other devices or communication networks.

[0155] Based on the same inventive concept, embodiments of this application also provide a performance event monitoring device cluster. This performance event monitoring device cluster includes at least one performance event monitoring device. Each of the at least one performance event monitoring device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the performance event monitoring device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0156] In one possible implementation, the memory in each performance event monitoring device in the performance event monitoring device cluster may store the same instructions for executing any of the performance event monitoring methods described above.

[0157] In another possible implementation, the memory of at least one performance event monitoring device in the performance event monitoring device cluster may also store partial instructions for executing any of the aforementioned performance event monitoring methods. In other words, a combination of at least one performance event monitoring device can jointly execute the instructions for executing any of the aforementioned performance event monitoring methods.

[0158] Optionally, the memories of different performance event monitoring devices within a performance event monitoring device cluster can store different instructions, each used to execute a specific function of the performance event monitoring device. That is, the instructions stored in the memories of different performance event monitoring devices can implement... Figure 10 The function of one or more modules in the performance event monitoring device 1000.

[0159] In some possible implementations, at least one performance event monitoring device in the performance event monitoring device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Specifically, the device connects to the network through a communication interface on each performance event monitoring device. In this type of possible implementation, at least one performance event monitoring device in the performance event monitoring device cluster can jointly execute any of the performance event monitoring methods described above.

[0160] Based on the same inventive concept, embodiments of this application provide a chip system or chip, which includes a processor and an interface. The processor is used to call and execute instructions from the interface. When the processor executes the instructions, it implements any of the performance event monitoring methods described above, for example, it can implement... Figure 7 The performance event monitoring method shown in the method embodiment.

[0161] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium for storing computer programs or instructions that, when executed, implement any of the performance event monitoring methods described above. For example, it can implement... Figure 7 The method described in the embodiment illustrates a performance event monitoring method. The computer-readable storage medium can be any available medium that the performance event monitoring device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive).

[0162] Based on the same inventive concept, embodiments of this application provide a computer program product that, when run on a computer, implements any of the performance event monitoring methods described above, for example, it can implement... Figure 7 The method described in the embodiment illustrates a performance event monitoring method. The computer program product may be a software or program product containing instructions capable of running on a computing device or stored on any available medium.

[0163] The method steps in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory, flash memory, read-only memory, programmable read-only memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Alternatively, the ASIC can reside in a base station or terminal. Of course, the processor and storage medium can also exist as discrete components in the base station or terminal.

[0164] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this application are performed entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable device. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video optical disc; or it can be a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or non-volatile storage medium, or may include both types of storage media.

[0165] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions of different embodiments are consistent and can be referenced by each other. The technical features of different embodiments can be combined to form new embodiments according to their inherent logical relationship.

[0166] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. The order of the process numbers described above does not imply the order of execution; the execution order of each process should be determined by its function and internal logic.

Claims

1. A performance event monitoring method, characterized in that, The method includes: When switching from the first process to the second process, the first count result of the first counter is read and stored, wherein the first counter is used to accumulate the number of times the first performance event occurs; When the second process switches to the third process, read the second count result of the first counter; Based on the first counting result and the second counting result, determine the number of times the first performance event occurs in the second process.

2. The method according to claim 1, characterized in that, The second process runs in the central processing unit (CPU) core, where: The first counter is bound to the CPU core; or, The first counter is set in the CPU core.

3. The method according to claim 1 or 2, characterized in that, The first counting result is stored in memory; After determining the number of times the first performance event occurs in the second process, the method further includes: Update the first count result in the memory with the second count result.

4. The method according to any one of claims 1-3, characterized in that, Before storing the first count result of the first counter, the method further includes: obtaining first monitoring information set by the user through a first interface, wherein the first monitoring information indicates the first performance event of the second process being monitored; After determining the number of times the first performance event occurred in the second process, the method further includes: providing feedback to the user via a second interface on the number of times the first performance event occurred in the second process.

5. The method according to any one of claims 1-4, characterized in that, After determining the number of times the first performance event occurs in the second process, the method further includes: When the third process switches to the fourth process, the third count result of the first counter is read; Based on the third counting result and the second counting result, the number of times the first performance event occurred in the third process is determined.

6. The method according to claim 5, characterized in that, Before storing the first count result of the first counter, the method further includes: obtaining second monitoring information set by the user through a first interface, the second monitoring information indicating the first performance event of the monitoring container, the container including the second process and the third process; After determining the number of times the first performance event occurs in the second process, the method further includes: providing feedback to the user via a second interface on the number of times the first performance event occurs in the container, wherein the number of times the first performance event occurs in the container is the sum of the number of times the first performance event occurs in the second process and the number of times the first performance event occurs in the third process.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: When storing the first count result of the first counter, the fourth count result of the second counter is also stored. The second counter is used to accumulate the number of times the second performance event occurs, and the second performance event is different from the first performance event. When reading the second count result of the first counter, the fifth count result of the second counter is also read; Based on the fourth and fifth counting results, the number of times the second performance event occurred in the second process is determined.

8. The method according to any one of claims 1-7, characterized in that, The second process runs in the CPU core, and the method further includes: When the CPU core is online, the sixth count result of the third counter is stored. The third counter is used to accumulate the number of times the third performance event occurs. The third performance event is different from the first performance event. When the CPU core is offline, read the seventh count result of the third counter; Based on the sixth and seventh counting results, the number of times the third performance event occurs in the CPU core is determined.

9. The method according to any one of claims 1-8, characterized in that, The first performance event includes one of the following: Process context switching; Page fault error; or, CPU core migration.

10. A performance event monitoring device, characterized in that, Includes modules or units for performing the method according to any one of claims 1-9.

11. A performance event monitoring device, characterized in that, Includes a processor, wherein: the processor is configured to invoke computer instructions in memory to cause the performance event monitoring device to perform the method as described in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when invoked by the computer, perform the method as described in any one of claims 1-9.

13. A computer program product, characterized in that, It includes instructions that, when executed on a computer, cause the method as described in any one of claims 1-9 to be performed.

14. A chip, characterized in that, The chip is coupled to a memory for reading and executing program instructions stored in the memory to implement the method as described in any one of claims 1-9.

Images