Performance measurement device, performance measurement method, and program

Abstract

This performance measurement device (100) accesses performance counters (PMC 31) of a processor and acquires a performance index of the processor. The performance measurement device (100) comprises: a counter batch setting unit 110 that continuously sets, with respect to a plurality of performance counters (PMC 31) possessed by a logical core, values counted by each of the same; and a counter batch access unit (120) that continuously acquires count values from the plurality of performance counters (PMC 31) set by the counter batch setting unit (110). If the type of count value to be acquired is different from the current set value, the counter batch access unit (120) requests setting from the counter batch setting unit (110).

Description

Performance measurement device, performance measurement method, and program

[0001] The present invention relates to a performance measurement device, a performance measurement method, and a program.

[0002] vRAN (virtual Radio Access Network) and AI (Artificial Intelligence) inference technologies make heavy use of CPU calculations. For example, applications that perform signal and media processing on the CPU (e.g., vRAN L1 signal processing and Deep-Learning) make heavy use of the CPU's SIMD (Single Instruction Multiple Data) instruction set extensions (e.g., Intel SSE / AVX512) ("Intel" is a registered trademark) for high-throughput calculation processing.

[0003] A conventional technique is to ensure equality by allocating a fixed amount of CPU time to each process (Non-Patent Document 1).

[0004] [Instruction Conflicts in SMT Technology] SMT (Simultaneous Multi-Threading), such as Intel Hyper Threading, is a technology that allows logical cores to share the CPU's microinstruction processors, thereby increasing the utilization rate of the processors. However, depending on the type of instruction, the execution of microinstructions within a core can conflict, resulting in performance degradation (known as a "port contention event"). Specifically, vector operation microinstructions, which are frequently used in vRAN, have a small number of built-in arithmetic units within the core, making them prone to conflicts.

[0005] Instruction contention in SMT technology will be described with reference to Figures 9 to 12. Figure 9 is a diagram showing the configuration of a CPU equipped with an SIMD unit that executes microinstructions within a core. As shown in Figure 9, the CPU 1 is equipped with four physical cores (CPU cores) 11. In this specification, the physical core 11 is a single CPU core that executes two or more processes simultaneously.

[0006] As shown in the enlarged view of Figure 9, the physical core 11 includes a logical core 21 (logical core <1>) and a logical core 22 (logical core <2>) that execute two threads per core, a decoder 23 that converts machine language read from registers 21a and 22a of the logical cores 21 and 22 into microinstructions, and a plurality of ports Port0 to Port6, each of which is connected to an in-CPU arithmetic unit 25 (e.g., an ALU (Arithmetic Logic Unit), ALD / STA (static timing analysis), STD (numeric_std in VHDL)).

[0007] As mentioned above, vector operation microinstructions have a small number of built-in arithmetic units within the core, making them prone to contention. For example, the Skylake generation Xeon ("Xeon" is a registered trademark) has four arithmetic units for general-purpose operations, but SIMD has two add / (" / " means "or") and two mul / shift units, and one shift unit.

[0008] As shown in the dashed box a in the enlarged view of Figure 9, general-purpose instructions (Scalar) have many arithmetic units and a high degree of parallelism. Therefore, resource contention is unlikely. On the other hand, as shown in the dashed box b in the enlarged view of Figure 9, VECTOR instructions (SIMD) have few arithmetic units and a low degree of parallelism. Therefore, resource contention is likely to occur.

[0009] In this way, the SIMD calculations of the CPU, which are frequently used in vRAN / AI inference, can result in performance competition between the logical core 21 and the logical core 22 within the same physical core 11 in an SMT configuration.

[0010] FIG. 10 is a diagram showing the configuration of a CPU when the microinstruction in FIG. 9 is a general-purpose instruction (Scalar). The upper diagram of FIG. 10 explains the operation of the CPU arithmetic unit 25 that executes the general-purpose instruction, and the lower diagram of FIG. 10 shows the parallel execution of the logic cores 21 and 22 in the upper diagram of FIG. 10. The execution portion of the corresponding microinstruction is indicated by a bold frame (the same notation applies below). As shown in the upper diagram of FIG. 10, there are many CPU arithmetic units 25 that execute general-purpose instructions, so conflicts are unlikely to occur. Therefore, as shown in the lower diagram of FIG. 10, the logic cores 21 and 22 can execute the general-purpose instruction in parallel, resulting in little performance degradation.

[0011] FIG. 11 is a diagram showing the configuration of a CPU when the microinstruction in FIG. 9 is a SIMD operation. The upper diagram in FIG. 11 explains the operation of the CPU arithmetic unit 25 that executes the VECTOR instruction (SIMD), and the lower diagram in FIG. 11 shows the parallel execution of the logic cores 21 and 22 in the upper diagram in FIG. 11. As indicated by the symbol c in the upper diagram in FIG. 11, the VECTOR instruction (SIMD) has few CPU arithmetic units 25 that execute the SIMD instruction (only one, Port 5), making contention more likely to occur. For this reason, as shown in the lower diagram in FIG. 11, the logic cores 21 and 22 have difficulty executing in parallel, leading to performance degradation. To avoid this, consideration must be given to the combination of each process, but the only technology available is that of Non-Patent Document 1, which allocates a fixed amount of CPU time to each process.

[0012] The gap between existing technologies and the requirements will be explained using the example of Linux CFS (Completely Fair Scheduler) ("Linux" is a registered trademark) in Non-Patent Document 1. FIG. 12 is a diagram showing the core allocation status. The same components as in FIG. 9 are assigned the same reference numerals. Non-Patent Document 1 is a technology that ensures fairness by allocating a certain amount of CPU time to each process. Therefore, Non-Patent Document 1 does not consider the conflict of dedicated instructions between processes (reference numeral d in FIG. 12), and therefore does not satisfy "Requirement 1: Each process is allocated the CPU processing time it requires."

[0013] [CPU Core and Intra-Core Performance Counters (PMU / PMC)] An overview of CPU cores and in-core performance counters (PMU (Performance Monitoring Unit) / PMC (Performance Monitoring Counter)) will be described. FIG. 13 is a diagram illustrating an overview of CPU cores and in-core performance counters (PMU / PMC). FIG. 13 shows a CPU core, and the enlarged view of FIG. 13 shows an example of a performance counter installed in a logical core. The CPU 1 shown in FIG. 13 has four physical cores 11 ("four physical cores") (hereinafter referred to as the same physical core 11) and a pair of logical cores ("eight logical cores") (see circles in FIG. 13) that exist on the same physical core 11 using SMT (Simultaneous Multi-Threading; Intel Hyper Threading). For example, in CPU 1, logical cores 0 and 4 share the same physical core 11. In this case, of the pair of logical cores 0 and 4 that exist in the same physical core 11, logical core 0 is the "front core" of the same physical core 11, and logical core 4 is the "back core" of the same physical core 11. For example, logical cores 3 and 7 share the same physical core 1 (see the dashed-line box e in Figure 13).

[0014] Many CPUs are equipped with PMUs for the purpose of application optimization and performance measurement. For example, Intel CPUs have four to eight PMUs per logical core, allowing dynamic acquisition of CPU core performance indicators. The PMC can acquire a wide range of data, including internal core behavior (whether the core is computationally bottlenecked or memory access bottlenecked, and the usage rate of instructions within the core), CPU frequency, and uncore frequency. Some data items are used via the Linux perf command. Many data items are used for non-real-time tuning in analysis tools such as Intel Vtune.

[0015] Among CPU performance counters, PMCs that can dynamically change the acquired content are limited in the number they can be installed in each CPU core, and switching is required to acquire more metrics than the number installed. Acquisition also requires execution of instructions on the core being measured. Furthermore, acquiring metrics requires access from within the target core, and if more metrics than the number installed are to be acquired, the settings must be switched, which creates overhead during the process.

[0016] An overview of the PMC will be given below. As shown in the enlarged view of Fig. 13, the PMU 30, which is a performance counter within the CPU, is equipped with four PMCs 31 per logical core. The PMU has the following characteristics that affect performance:

[0017] <Feature 1 that affects performance> Access is required from within the target core. In other words, access is not possible from other cores. Therefore, intervention in program execution is required.

[0018] <Feature 2 that affects performance> The number of Generic Counters whose acquisition items change depending on the settings is finite (4-8). Therefore, when the finite number of Generic Counters is used up, the Generic Counters must be reset, resulting in switching overhead.

[0019] The PMU can acquire the following items set for each counter:

[0020] <Core behavior> ・Number of instructions executed ・Performance degradation rate in the FrontEnd (decomposition of instructions into uOps) ・Memory rebound rate ・Internal core instruction port utilization rate

[0021] <Frequency and other behavior-related> ・Uncore frequency ・Number of power saving mode transitions and time ・Etc. To be precise, the above Generic Counters are divided into Fixed Counters that can be obtained at any time, and Generic Counters that require pre-setting and are limited in number.

[0022] [Acquisition of Processor Performance Indicators in a Computer System] In a computer system, a processor on a computer (hereinafter referred to as a server) may be configured to process a task that requires real-time performance.

[0023] <Configuration and Prerequisites> 1. Server Machine (1) The server machine is equipped with a processor. (2) The processor has an internal performance counter. (3) The performance counter can acquire one or more indicators. 2. Task to be Measured (1) A task that runs on a machine and uses one or more cores.

[0024] <Requirements> ・Requirement 1: [Few interruptions] The number of interruptions of task execution running on the target core due to access to the processor performance counter must be kept to a minimum. ・Requirement 2: [Short interruption time] The interruption time of task execution running on the target core due to access to the processor performance counter must be kept to a minimum.

[0025] Linux CFS Scheduler, The Linux Kernel6.2.0, [online], [Retrieved February 1, 2020], Internet <URL: https: / / www.kernel.org / doc / html / latest / scheduler / sched-design-CFS.html>

[0026] As described above, the Linux perf application and perf driver described in Non-Patent Document 1 access the CPU performance counter (PMU) through an inter-core interrupt to acquire some performance indicators. In this case, the operating status of the application running on the core being measured is not taken into consideration, and an inter-core interrupt is generated for each indicator to be acquired, which poses a problem that the number of interruptions of task execution running on the target core is not minimized.

[0027] Furthermore, when there are many performance indicators to be acquired, the acquisition time per access becomes longer due to the PMC switching settings, which poses the problem that the interruption time of task execution running on the target core is not minimized.

[0028] The problems with the existing technology will be explained in detail. Fig. 14 is a schematic diagram showing the location of overhead, which is a problem with the existing technology. As an example of the existing technology, access to performance counters by Perf stat is taken. Fig. 15 shows the sequence when performance indicators are acquired by the Linux perf application and perf driver in Fig. 14. Figs. 14 and 15 show counter access from logical core <1> to logical core <2> by perf stat.

[0029] The Linux perf application and perf driver access the CPU performance counter (PMU) through inter-core interrupts to acquire some performance indicators. In Fig. 14, the "information acquisition application (perf)" 3 in the user space software uses a Perf driver 62 in the software (OS / driver / privilege) to generate inter-core interrupts for the number of items to be acquired to the Perf driver 61 in the software (OS / driver / privilege) of the "measurement target application" 2 (arrows f, g, h in Fig. 14). The Perf driver 61 used by the "measurement target application" 2 accesses the target PMC 31 among the PMCs 31 of the logical core <2> from which information is acquired. ２ ~PMC31 ４ For each inter-core interrupt that occurs, the PMC is accessed and the corresponding performance indicator is obtained.

[0030] In this case, the operating status of the application running on the core being measured is not taken into consideration, and an inter-core interrupt is generated for each indicator acquisition (arrow i in Figure 14). Since inter-core interrupts are generated for the number of acquisition items, requirement 1: [low number of interruptions] is not met.

[0031] Furthermore, if the number of acquired items is greater than the number of PMCs, PMCs are rotated (arrow j in FIG. 14). In other words, if there are many acquired performance indicators, PMC switching settings are performed, which lengthens the acquisition time per access, and does not satisfy requirement 2: [short interruption time].

[0032] The sequence in Figure 15 confirms that Requirement 1: [few interruptions] and Requirement 2: [short interruption duration] are not satisfied. As shown in Figure 15, the "information acquisition application (perf)" 3 (hereinafter referred to as the information acquisition source (logical core <1>)) of the information acquisition source (logical core <1>) accesses the PMC Special File in step S1. In response to this, in step S2, the Perf driver 62 (Figure 14) of the information acquisition source (logical core <1>) issues an interrupt (IPI) to the logical core <2> to acquire one index, and in step S3, an interrupt is issued to the information acquisition destination logical core <2>.

[0033] Meanwhile, the "measurement target application" 2 of the information source logical core <2> (hereinafter referred to as the information source logical core <2>) performs PMC setting (write) in advance in step S11. The information source logical core <2> receives an interrupt (step S3) from the information source (logical core <1>), performs PMC access 1 (read) in step S12 to read the corresponding item index 1, and sends the acquired information (item index 1) to the information source (logical core <1>) in step S4.

[0034] Here, if the number of acquired items is greater than the number of PMCs, the logical core <2> from which the information is acquired performs PMC setting (write) to rotate the PMC (step S13). Note that the interrupts associated with acquiring each item from the logical core <2> from which the information is acquired and the instruction execution for acquiring information from the logical core <2> from which the information is acquired due to these interrupts result in a decrease in performance of the application running on the logical core <2> from which the information is acquired, and are therefore indicated by a flaming mark j in FIG.

[0035] Similarly, in step S5, the information acquisition source (logic core <1>) issues an interrupt (IPI) to the logic core <2> to acquire index 2, and in step S6, issues an interrupt to the information acquisition destination logic core <2>. The information acquisition destination logic core <2> performs PMC access 2 (read) to read the corresponding item index 2 in step S14, and transmits the acquired information (item index 2) to the information acquisition source (logic core <1>) in step S8. Furthermore, in step S8, the information acquisition source (logic core <1>) issues an interrupt (IPI) to the logic core <2> to acquire index 3, and in step S9, issues an interrupt to the information acquisition destination logic core <2>. The information acquisition destination logic core <2> performs PMC access 3 (read) to read the corresponding item index 3 in step S15, and transmits the acquired information (item index 3) to the information acquisition source (logic core <1>) in step S10.

[0036] As mentioned above, the number of PMCs per CPU core is limited, and acquiring more metrics than the number of PMCs installed requires switching. Furthermore, acquisition requires instruction execution on the target core. Therefore, PMCs inherently cause performance degradation (e.g., 50 μs) in applications running on the target core due to the "PMC setting switch" and "interrupts associated with each item acquisition" required when acquiring an item. Existing technologies, as shown by symbol i in Figure 14 and symbol j in Figure 15, generate several inter-core interrupts for each acquired item. Since an inter-core interrupt is generated for each metric acquisition, they do not minimize the number of interruptions to task execution running on the target core.

[0037] 15, if the number of acquired items is greater than the number of PMCs, PMCs are rotated. Since PMC switching is performed, the acquisition time per access becomes longer, which poses a problem of not satisfying Requirement 2: [short interruption time].

[0038] The present invention has been made in view of the above background, and an object of the present invention is to reduce the number of interruptions of applications and the access time that accompany access to a processor's performance counter.

[0039] In order to solve the above-mentioned problems, a performance measurement device is provided that accesses the performance counters of a processor and acquires the processor's performance indicators, and is characterized by comprising: a counter batch setting unit that continuously sets the count values ​​for each of the multiple performance counters held by a logical core; and a counter batch access unit that continuously acquires count values ​​from the multiple performance counters set by the counter batch setting unit.

[0040] According to the present invention, it is possible to reduce the number of interruptions to an application and the access time associated with accessing a processor's performance counter.

[0041] 14 is a schematic configuration diagram of a computing system including a performance measurement device according to an embodiment of the present invention. FIG. 15 is a configuration diagram of a performance measurement device according to an embodiment of the present invention. FIG. 16 is a configuration diagram in which a performance measurement device according to an embodiment of the present invention is deployed in userland. FIG. 17 is a diagram explaining a dynamic scheduler function to which a performance measurement device according to an embodiment of the present invention is applied. FIG. 18 is a schematic diagram showing bulk access of a PMC of the performance measurement device according to an embodiment of the present invention. FIG. 19 is a sequence diagram when a performance index is acquired by bulk access of a PMC of the performance measurement device according to an embodiment of the present invention. FIG. 19 is a flowchart showing the operation of each part of the performance measurement device according to an embodiment of the present invention. FIG. 19 is a hardware configuration diagram showing an example of a computer that realizes the functions of the performance measurement device of the computing system according to an embodiment of the present invention. FIG. 19 is a diagram showing the configuration of a CPU including a SIMD unit that executes microinstructions in a core. FIG. 19 is a diagram showing the configuration of a CPU when the microinstruction in FIG. 9 is a general-purpose instruction (Scalar). FIG. 19 is a diagram showing the configuration of a CPU when the microinstruction in FIG. 9 is an SIMD operation. FIG. 19 is a diagram showing the allocation status of cores. FIG. 19 is a diagram explaining an overview of a CPU core and in-core performance counters (PMU / PMC). FIG. 19 is a schematic diagram showing the location of overhead, which is a problem in existing technology. FIG. 19 is a sequence diagram when a performance index is acquired by the Linux perf application and perf driver in FIG.

[0042] A performance measurement device and the like in an embodiment of the present invention (hereinafter referred to as "the present embodiment") will be described below with reference to the drawings. (Embodiment) [Overview] FIG. 1 is a schematic diagram of a computing system including a performance measurement device according to an embodiment of the present invention. Components identical to those in FIG. 12 are designated by the same reference numerals. The first embodiment is an example in which the computing system is applied to a CPU. In addition to CPUs, the present invention can also be applied to processors such as GPUs (Graphic Processing Units), FPGAs (Field Programmable Gate Arrays), and ASICs (Application Specific Integrated Circuits). As shown in FIG. 1, a computing system 1000 includes a performance measurement device 100 and physical cores 11 and 12 (physical core <1> and physical core <2>) (processors) on the CPU.

[0043] The information of the applications called by the performance measurement device 100 is as follows: The information of the applications (e.g., vRAN task group) is, for example, as follows: Pre-coding (Vector multiplication M division, Vector shift N division) Demap Logger process (general-purpose instruction 100%) QR-Decompression Phase Noise Estimation Eigen Beamforming Pre-Coding De-mapping

[0044] The computing system 1000 executes dedicated instructions specialized for specific operations, including, for example, SIMD instructions or dedicated instructions for encryption, and includes a performance measurement device 100 that allocates execution processes of the dedicated instructions to logical cores using hardware multithreading, which simulates one physical core as multiple logical cores.

[0045] The physical core 11 (physical core <1>) has a logical core 21 (logical core <1>) and a logical core 22 (logical core <2>) that execute two threads. The logical core 21 executes the pre-coding process, and the logical core 22 executes the de-mapping process.

[0046] The physical core 12 (physical core <2>) has a logical core 21 (logical core <1>) and a logical core 22 (logical core <2>) that execute two threads. The logical core 21 executes a pre-coding process, and the logical core 22 executes a logger process.

[0047] <PMC (Processor Performance Counter)> A CPU is equipped with four to eight PMCs 31 per logical core. In Fig. 1, the CPU is equipped with four PMCs <1> to <4> per logical core. Items that the PMC 31 can acquire include core internal behavior (core operation bottleneck, memory access bottleneck, in-core instruction type utilization rate, etc.), CPU frequency, uncore frequency, etc.

[0048] <Management of Application Information> The performance measurement device 100 manages the types and frequencies of instructions for each application in a table (described later).

[0049] <Management of CPU Hardware Information> The performance measurement device 100 manages information on the number and configuration of arithmetic units for each instruction type of the CPU in a table (not shown). During scheduling, each process is assigned to a logical core based on the management of the application information and the management of the CPU hardware information so that the processes to be executed do not conflict with each other.

[0050] The performance measurement device 100 is a core allocation scheduler that allocates the logical cores 21 and 22 to a combination that does not conflict, taking into account the execution rate of SIMD instructions (details will be described later). If a process that causes instruction conflicts is being executed, the performance measurement device 100 allocates it to another physical core (symbol aa in FIG. 1), and allocates a process that is less likely to cause instruction execution conflicts to the remaining logical core (symbol bb in FIG. 1).

[0051] [Configuration of the Performance Measurement Device] Fig. 2 is a configuration diagram of a performance measurement device according to an embodiment of the present invention. As shown in Fig. 2, the performance measurement device 100 is a core allocation scheduler within a server, and includes a CPU 50, which is hardware (HW), physical cores (physical core <1>, physical core <2>) 11 (processors) on the CPU 50, an OS / driver / privileged area 60, and a userland 70.

[0052] The performance measurement device 100 includes a counter batch setting unit 110, a counter batch access unit 120, an acquisition result asynchronous notification unit 130, a measurement target non-operating timing determination unit 140, and a performance counter acquisition request unit 150, which are arranged as software in the OS / driver / privileged area 60. The performance measurement device 100 includes a measurement target application (measurement target application) 2 and a measurement result acquisition application (information acquisition application) 3 in the userland 70.

[0053] 2, the information acquisition source (logical core <1>) includes, in software 60, a counter batch setting unit 110, a counter batch access unit 120, an acquisition result asynchronous notification unit 130, and a measurement target non-operating timing determination unit 140, and also includes a measurement target application 2 in userland 70. Furthermore, the information acquisition destination (logical core <2>) includes, in software 60, a performance counter acquisition request unit 150, and also includes a measurement result acquisition application 3 in userland 70.

[0054] Here, the performance measurement device 100 is only required to have the functional units of the counter batch setting unit 110, counter batch access unit 120, acquisition result asynchronous notification unit 130, measurement target non-operating timing determination unit 140, and performance counter acquisition request unit 150, and the only difference is that the functional units used (playing the role) for the information acquisition source (logical core <1>) and the information acquisition destination (logical core <2>) are different. Furthermore, the above functional units are not limited to being arranged on the software 60, as will be described later.

[0055] <CPU 50> The CPU 50 includes physical cores (physical core <1>, physical core <2>) 11 (however, only one physical core 11 is shown in FIG. 2). The physical core 11 includes a logical core <1> and a logical core <2> that execute two threads per physical core by using hyperthreading that makes one physical core appear as two.

[0056] <Counter batch setting unit 110> The counter batch setting unit 110 successively sets the count values ​​of the multiple performance counters of the logical core. The counter batch setting unit 110 sets the setting contents based on a request from the counter batch access unit 120.

[0057] If the requested performance index value is greater than the number of performance counters installed in the hardware, the counter batch setting unit 110 limits the number of performance index values ​​to be acquired to a value equal to or less than the number of performance counters installed in the hardware. Specifically, if the performance index value requested by the performance counter acquisition request unit 150 is greater than the number of performance counters installed in the hardware, the counter batch setting unit 110 performs setting and access so as to minimize the number of switching times.

[0058] <Counter batch access unit 120> The counter batch access unit 120 continuously acquires count values ​​from multiple performance counters set by the counter batch setting unit 110. Here, "continuously" means "acquiring multiple numerical values ​​from the counters without interruption, without the intervention of other processes." A typical example of other processes here is "responding to the results of each numerical value acquisition," and also includes "other processes generated by interrupts." The counter batch access unit 120 records the setting status of the values ​​counted by the performance counters of the target cores, and if the type of count value to be acquired differs from the currently set value, requests the counter batch setting unit 110 to set it.

[0059] <Acquisition Result Asynchronous Notification Unit 130> The acquisition result asynchronous notification unit 130 asynchronously notifies the performance counter acquisition request unit 150 of the performance count values ​​acquired by the counter batch access unit 120 by writing them into the shared memory 160 (FIG. 5).

[0060] <Measurement target non-operating timing determination unit 140> The measurement target non-operating timing determination unit 140 detects whether the measurement target application 2 is in a sleep state or an idle state (when the application is not running), and calls the counter batch access unit 120 at the appropriate timing. The measurement target non-operating timing determination unit 140 also periodically acquires the state of the OS task scheduler and sleep processing, detects whether any task is being executed, and calls the counter batch access unit 120 at the appropriate timing. Note that the measurement target non-operating timing determination unit 140 may actively call the counter batch access unit 120 from the application side, or may actively call the counter batch access unit 120 when entering sleep processing.

[0061] <Performance counter acquisition request unit 150> The performance counter acquisition request unit 150 requests the acquisition of performance indicators of the measurement target application 2. A request to acquire performance indicators includes multiple types of performance indicators. The performance counter acquisition request unit 150 has a function to cause (trigger) the acquisition of performance indicators. Triggers include periodic acquisition at fixed time intervals. The performance counter acquisition request unit 150 also acquires the results written by the acquisition result asynchronous notification unit 130 by periodic inquiries (polling).

[0062] [Application Example of Performance Measurement Device] FIG. 2 shows an example in which the performance measurement device 100 is entirely included in the software 60 allocated in the OS / kernel / privileged area, but the performance measurement device 100 does not have to be entirely included in the OS.

[0063] 3 is a configuration diagram in which a performance measurement device 100A is placed in userland 70. The same components as those in FIG. 2 are assigned the same reference numerals. The performance measurement device 100A includes a CPU 50, a physical core 11 (processor) on the CPU 50, and a counter batch setting unit 110, a counter batch access unit 120, an acquisition result asynchronous notification unit 130, a measurement target non-operating timing determination unit 140, and a performance counter acquisition request unit 150, which are placed in userland 70.

[0064] 3, the information acquisition source (logical core <1>) includes, in userland 70, a measurement target application 2, a counter batch setting unit 110, a counter batch access unit 120, an acquisition result asynchronous notification unit 130, and a measurement target non-operation timing determination unit 140. The information acquisition destination (logical core <2>) includes, in userland 70, a measurement result acquisition application 3 and a performance counter acquisition request unit 150.

[0065] The operation of the performance measurement devices 100 and 100A configured as described above will now be described. (Principle Description) First, the basic concept of the present invention will be described. <Dynamic Analysis and Core Allocation Using PMC> Figure 4 is a diagram illustrating the dynamic scheduler function to which the performance measurement device 100 is applied. Components identical to those in Figures 2 and 3 are designated by the same reference numerals. The CPU 1 (hardware) includes two physical cores 11 and 12. These physical cores 11 and 12 are single CPU cores that simultaneously execute two or more processes. The physical cores 11 and 12 each have a logical core 21 (logical core <1>) and a logical core 22 (logical core <2>) that execute two threads. Software applications include task 41 (task 1 (SIMD)) and task 42 (task 2 (changeable between SIMD and general-purpose)).

[0066] 4, the performance measurement device 100 acquires item information (e.g., the number of instruction executions, uncore frequency, etc.) set in each PMC 31 by accessing it from within the target core (here, the logical core 21) (symbol cc in FIG. 4). The dynamic scheduler function to which the performance measurement device 100 is applied performs dynamic core allocation control (symbol dd in FIG. 4) based on dynamic task characteristic detection using a PMC (in-CPU performance counter) (e.g., data acquisition taking into account the PMC acquisition timing, the number of interrupts, and the number of built-in counters).

[0067] For example, if task 41 (task 1 (SIMD)) is assigned to logical core 0 ("front core") of the pair of logical cores 0 and 2 that share the same physical core 11, then the task (SIMD) is not assigned to logical core 2 ("back core") to avoid SIMD operation contention. Instead, the task (SIMD) is assigned to logical core 1 ("front core") of the pair of logical cores 1 and 3 that share the same physical core 12. Logical core 3 ("back core") is free. In other words, task 1 (SIMD), which could not be assigned to logical core 2 ("back core") to avoid SIMD operation contention, is assigned to logical core 1 by using one more core.

[0068] When the dynamic scheduler function performs dynamic core allocation control based on dynamic task characteristic detection using the PMC (symbol dd in FIG. 4), for example, in the case of task 42 (task 2 (variable between SIMD and general-purpose)), the core allocation of task 2 (variable between SIMD and general-purpose) is changed from logical core 1 ("front core") of the same physical core 12 to logical core 2 ("back core") of the same physical core 11 (symbol ee in FIG. 4). As a result, as shown by the double dashed line and dashed circle in FIG. 4, core allocation is eliminated for logical cores 1 and 3 of the same physical core 12, and the number of cores can be reduced by one.

[0069] The dynamic scheduler function minimizes the impact on application performance through the above-mentioned "dynamic analysis and core allocation using PMC" and the "bulk access of PMC" described below, while expanding the effectiveness and scope of application by minimizing the number of cores that do not require pre-analysis and saving power.

[0070] <Bulk Access of PMC> Fig. 5 is a schematic diagram showing bulk access of the PMC of the performance measurement device 100. Fig. 6 shows the sequence when a performance index is acquired by bulk access of the PMC in Fig. 5. Fig. 5 corresponds to the schematic diagram showing the overhead location in Fig. 14, and Fig. 6 corresponds to the sequence when a performance index is acquired in Fig. 15. In Fig. 5, the same components as in Fig. 14 are assigned the same reference numerals. Figs. 5 and 6 show counter access from logical core <1> to logical core <2> by perf stat.

[0071] The Linux perf application and perf driver access the CPU performance counter (PMU) through inter-core interrupts to acquire some performance indicators. In Fig. 5, the "information acquisition application (perf)" 3 in the user space software uses the OS / driver / privileged driver 162 to asynchronously and collectively acquire the performance indicators (acquired data) written in the shared memory 160 (arrow ff in Fig. 5).

[0072] Here, the performance measurement device 100 (FIGS. 1 and 2) collectively sets the simultaneously acquired indicators for the driver 161 to which the present technology is applied. That is, the items to be simultaneously acquired from the PMC are set in the PMC so that they can be acquired collectively without rotation, taking into account the number of PMCs installed (arrow gg in FIG. 5).

[0073] Furthermore, the performance measurement device 100 acquires indicators synchronized with the behavior of the application. "Synchronization with the behavior of the application" means acquiring indicators when the application is not running, among other application behaviors. For example, indicators are acquired when the application on the logical core 22 (logical core <2>) is not running (the moment it goes into sleep, at a context switch, etc.). In the driver 161 of the present technology in FIG. 5, the indicators are acquired at a timing that does not affect the "application to be measured" 2. The driver 161 of the present technology in FIG. 5 acquires indicators synchronized with the behavior of the application, among the PMCs 31 of the logical core <2> from which information is acquired. ２ ~PMC31 ４ Access all at once and obtain the relevant performance indicators (obtained data).

[0074] In this way, the acquisition overhead is reduced by the [function to set simultaneous acquisition indicators in bulk] and [acquisition aggregation], while the performance impact is minimized by [acquisition synchronized with application behavior] and [asynchronization via shared memory] (described below).

[0075] Furthermore, PMC31 ２ ~PMC31 ４The performance indicators (acquired data) read by accessing the shared memory 160 in a batch are written to the shared memory 160 (arrow hh in FIG. 5). The logical core <1> that acquired the information then asynchronously acquires the performance indicators (acquired data) written to the shared memory 160 in accordance with its own acquisition timing (arrow ff in FIG. 5). By passing through the shared memory 160, the acquired data can be acquired asynchronously, realizing an interrupt-less system.

[0076] The object of this invention is to obtain the value of a performance counter inside a processor on a server while minimizing the degradation in performance of tasks running using the processor. To achieve this, the following requirements must be met: Requirement 1: [Few interruptions] The number of interruptions to task execution running on a target core due to access to the processor performance counter must be minimized. Requirement 2: [Short interruption time] The interruption time to task execution running on a target core due to access to the processor performance counter must be minimized.

[0077] The sequence in Figure 6 confirms whether the above requirement 1: [low number of interruptions] and requirement 2: [short interruption time] are satisfied. As shown in Figure 6, the "information acquisition application (perf)" 3 (hereinafter referred to as the information acquisition source (logical core <1>)) of the information acquisition source (logical core <1>) accesses the driver 162 with the present technology. In response to this, the driver 162 with the present technology issues an interrupt to the logical core <2> from which the information is acquired in order to acquire a performance index (step S21).

[0078] The "measurement target application" 2 of the information source logical core <2> (hereinafter referred to as information source logical core <2>) performs PMC setting (write) in step S22. The information source logical core <2> sets the simultaneous acquisition indicators in bulk and notifies the information source (logical core <1>) of the completion of the setting so that the information source logical core (logical core <1>) can acquire them in bulk (step S23). Here, the items to be acquired simultaneously from the PMC are set in the PMC so that they can be acquired in bulk without rotating, taking into account the number of PMCs installed.

[0079] In step S24, the performance measurement device 100 acquires performance indicators synchronized with application behavior. One example of application behavior is sleep detection for a CPU core. The performance indicators are acquired when the application on the logical core <2> from which the information is acquired is not running (such as when the application enters sleep mode or when a context switch occurs).

[0080] In step S25, the information source logical core <2> performs PMC access 1 (read) to read the corresponding item index 1, then performs PMC access 2 (read) to read the corresponding item index 2 in step S26, and then performs PMC access 3 (read) to read the corresponding item index 3 in step S27. As can be seen by comparing with the sequence of the conventional technology in FIG. 15 , in the conventional technology in FIG. 15 , three interrupts were issued to the information source logical core <2> to obtain the three indexes (S3, S6, and S9 in FIG. 15 ). In this embodiment, the obtained indexes are set in a batch and then sequentially read by PMC accesses 1 to 3. In addition, in the conventional technology in FIG. 15 , the read item indexes 1 to 3 were sequentially sent to the information source logical core (logical core <1>) (S4, S7, and S10 in FIG. 15 ). In this embodiment, the read data (item indexes 1 to 3) are written to the shared memory 160 ( FIG. 6 ) (step S28).

[0081] The logical core (logical core <1>) that acquires the information accesses the shared memory 160 (FIG. 5) at its own timing and reads the acquired data (item indexes 1 to 3) that have been written to the shared memory 160 (step S29). In this way, by using the shared memory 160, the logical core <2> that acquires the information only needs to write the acquired data that it has read to the shared memory 160, and the logical core <1> that acquires the information can acquire the acquired data asynchronously, realizing an interrupt-less system.

[0082] [Flowchart of the Performance Measurement Device] FIG. 7 is a flowchart showing the operation of each unit of the performance measurement device 100. Step S101 is a step executed by the performance acquisition request application operating core (see the dashed box in FIG. 7). In the configuration examples of FIGS. 1 and 2, the performance acquisition request application operating core is the information acquisition destination (logical core <2>). In step S101, the performance counter acquisition request unit 150 requests the acquisition of performance indicators of the measurement target application. The request for performance indicator acquisition includes multiple types of performance indicators. The performance counter acquisition request unit 150 has a function to trigger the acquisition of performance indicators, and triggers include periodic acquisition at regular time intervals. In addition, the performance counter acquisition request unit 150 may acquire the results written by the acquisition result asynchronous notification unit 130 by periodic inquiry (polling).

[0083] In step S102, the measurement target non-operating timing determination unit 140 detects whether the measurement target application is in a sleep state or an idle state, and calls the counter batch access unit 120 at the corresponding timing. For example, the measurement target non-operating timing determination unit 140 can periodically obtain the status of the OS task scheduler or sleep processing and detect whether any task is being executed. Note that the counter batch access unit 120 may also be actively called from the application side or when the application enters a sleep processing.

[0084] Steps S103 to S107 are steps executed by the measurement target application operating core (see the dashed box in FIG. 7). In the configuration examples of FIGS. 1 and 2, the measurement target application operating core is the logical core (logical core <1>) from which the information was acquired. Steps S103 to S106 are operation steps of the counter batch access unit 120.

[0085] In step S103, the counter batch access unit 120 continuously acquires count values ​​from the multiple performance counters set by the counter batch setting unit 110 and determines whether the current counter setting value has been set. If the current counter setting value has been set (S103: Yes), the process proceeds to step S105. If the current counter setting value has not been set (S103: No), the process proceeds to step S104. The counter batch access unit 120 records the setting status of the values ​​counted by the performance counters of the acquisition target core, and if the type of the count value to be acquired is different from the current setting value (if the current counter setting value has not been set), the counter batch setting unit 110 is requested to set the value (S103: No).

[0086] In step S104, the counter batch setting unit 110 successively sets the count values ​​for each of the multiple performance counters held by the logical core, and then the process proceeds to step S105. The setting contents are based on a request from the counter batch access unit 120. If the performance index values ​​requested by the performance counter acquisition request unit 150 are greater than the number of performance counters installed in the hardware, the counter batch setting unit 110 sets and accesses the counters so as to minimize the number of switching times.

[0087] In step S105, the counter batch access unit 120 continuously acquires count values ​​from the multiple performance counters set by the counter batch setting unit 110. As described above, "continuous" refers to acquiring multiple values ​​from the counters without interruption, without any other processing. In existing technology, acquiring multiple values ​​from the counters is performed separately each time through a response process. For example, when acquiring three values ​​from the counters, the process of "acquiring one value and responding with the result" is repeated three times. In contrast, in this embodiment, by continuously acquiring multiple values ​​from the counters (without any other processing), only one "continuous count value acquisition and result response" is required, thereby reducing the number of accesses and increasing speed.

[0088] In step S106, the counter bulk access unit 120 determines whether or not all of the counters requested by the performance counter acquisition request unit 150 have been acquired. If all of the requested counters have been acquired (S106: Yes), the process proceeds to step S107; if all of the requested counters have not been acquired (S106: No), the process returns to step S104.

[0089] In step S107, the acquisition result asynchronous notification unit 130 asynchronously notifies the performance counter acquisition request unit 150 of the performance count value acquired by the counter bulk access unit 120 by writing it to the shared memory 160 (Figure 5), and then ends the processing of this flow.

[0090] [Hardware Configuration] The performance measurement devices 100, 100A (FIGS. 2 and 3) according to the above embodiments are realized by a computer 900 having a configuration such as that shown in FIG. 8. FIG. 8 is a hardware configuration diagram showing an example of the computer 900 that realizes the functions of the performance measurement devices 100, 100A (FIGS. 2 and 3). The computer 900 has a CPU 901, a ROM 902, a RAM 903, a HDD 904, a communication interface (I / F) 906, an input / output interface (I / F) 905, and a media interface (I / F) 907.

[0091] The CPU 901 operates based on programs stored in the ROM 902 or HDD 904, and controls each part of the performance measurement device 100, 100A (FIGS. 2 and 3). The ROM 902 stores a boot program executed by the CPU 901 when the computer 900 is started, programs that depend on the hardware of the computer 900, and the like.

[0092] The CPU 901 controls an input device 910 such as a mouse or keyboard, and an output device 911 such as a display, via an input / output I / F 905. The CPU 901 acquires data from the input device 910 via the input / output I / F 905, and outputs generated data to the output device 911. Note that a GPU (Graphics Processing Unit) or the like may be used as a processor together with the CPU 901.

[0093] The HDD 904 stores programs executed by the CPU 901 and data used by the programs. The communication I / F 906 receives data from other devices via a communication network (e.g., NW (Network) 920) and outputs the data to the CPU 901, and also transmits data generated by the CPU 901 to other devices via the communication network.

[0094] The media I / F 907 reads a program or data stored in the recording medium 912 and outputs it to the CPU 901 via the RAM 903. The CPU 901 loads a program related to a target process from the recording medium 912 onto the RAM 903 via the media I / F 907, and executes the loaded program. The recording medium 912 is an optical recording medium such as a DVD (Digital Versatile Disc) or a PD (Phase Change Rewritable Disc), a magneto-optical recording medium such as an MO (Magneto Optical Disc), a magnetic recording medium, a conductive memory tape medium, a semiconductor memory, or the like.

[0095] For example, when the computer 900 functions as the performance measurement device 100, 100A (FIGS. 2 and 3) configured as one device according to this embodiment, the CPU 901 of the computer 900 realizes the functions of the performance measurement device 100, 100A by executing a program loaded onto the RAM 903. In addition, the HDD 904 stores data in the RAM 903. The CPU 901 reads and executes a program related to a target process from a recording medium 912. Alternatively, the CPU 901 may read a program related to a target process from another device via a communication network (NW 920).

[0096] [Effects] As described above, the performance measurement device 100 (FIGS. 2 and 3) is a performance measurement device that accesses the performance counters (PMC 31) of a processor and acquires performance indicators of the processor, and is characterized by comprising: a counter batch setting unit 110 that continuously sets the count values ​​of the multiple performance counters (PMC 31) that a logical core has; and a counter batch access unit 120 that continuously acquires count values ​​from the multiple performance counters (PMC 31) set by the counter batch setting unit 110.

[0097] In this way, "collective setting when acquiring multiple indicators" and "collective acquisition of multiple indicators" can reduce the number of application interruptions and access time associated with accessing processor performance counters. As a result, it becomes possible to access performance counters that minimize the number of interruptions and time of applications running on the target core.

[0098] The requirements to be met can be summarized as follows: Requirement 1: [Few interruptions] The number of interruptions of task execution running on the target core due to access to the processor performance counter is minimized. Requirement 2: [Short interruption duration] The interruption duration of task execution running on the target core due to access to the processor performance counter is minimized. The performance measurement devices 100 and 100A can meet the requirements 1 and 2 above.

[0099] As a result, the performance measurement device 100, 100A can acquire the value of the performance counter inside the processor on the server while minimizing the degradation in performance of tasks that run using the processor.

[0100] In the performance measurement device 100 (Figures 2 and 3), if the requested performance index value is greater than the number of performance counters (PMC31) installed in the hardware, the counter batch setting unit 110 limits the number of performance index values ​​obtained to less than or equal to the number of performance counters (PMC31) installed in the hardware.

[0101] As described in the problem to be solved, when there are many performance indicators to be acquired, the acquisition time per access becomes long due to the PMC switching setting, and requirement 2 [short interruption time] is not met. In this embodiment, by setting the number of setting switches when acquiring performance indicator values ​​to be small (preferably, setting the number of setting switches to be minimum), it is possible to reduce the interruption time of applications due to counter access.

[0102] In the performance measurement device 100, 100A (Figures 2 and 3), the counter batch access unit 120 records the setting status of the value counted by the performance counter (PMC31) of the core to be acquired, and if the type of count value to be acquired differs from the current setting value, requests the counter batch setting unit 110 to set it.

[0103] By doing this, the performance measurement device 100, 100A continuously acquires count values ​​from the multiple performance counters (PMC31) set by the counter batch setting unit 110 when the type of count value to be acquired is different from the current setting value. Therefore, when the type of count value to be acquired is the same as the current setting value, access to the processor's performance counter can be skipped, thereby reducing the overall number of accesses.

[0104] The performance measurement device 100, 100A (FIGS. 2 and 3) includes a measurement target non-operation timing determination unit 140 that detects when the measurement target application is not running (such as in a sleep state or an idle state, or at the moment of entering sleep or a context switch), and calls the counter batch access unit 120 at the timing of the non-execution.

[0105] In this way, the performance measurement device 100, 100A takes into consideration the execution timing of the application to be measured and triggers (triggers) the acquisition of performance indicators at times when the application is not running, thereby reducing the number of times the application is suspended.

[0106] The performance measurement devices 100 and 100A (FIGS. 2 and 3) include a performance counter acquisition request unit that requests the measurement target non-operating timing determination unit 140 to acquire the performance index of the measurement target application.

[0107] In this way, the performance measurement device 100 takes into consideration the timing of the performance measurement target and performs counter access at a timing when the measurement target application is not running, thereby reducing the number of interruptions of the application.

[0108] The performance measurement device 100, 100A (FIGS. 2 and 3) includes an acquisition result asynchronous notification unit 130 that asynchronously notifies the performance counter acquisition request unit 150 of the performance count value acquired by the counter bulk access unit 120 by writing the performance count value to a shared memory 160 (FIG. 5) mounted on the hardware.

[0109] In this way, the performance measurement devices 100 and 100A can asynchronously acquire data without interrupting the operation of the application to be measured by asynchronously notifying the performance counter acquisition request unit 150 via writing to the shared memory 160. In other words, an interrupt-less system can be realized, reducing the number of interruptions to the application.

[0110] Note that, among the processes described in the above embodiments and variations, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using known methods. Furthermore, the processing procedures, control procedures, specific names, and information including various data and parameters shown in the above documents and drawings can be changed as desired unless otherwise specified. Furthermore, the components of each device shown in the drawings are functionally conceptual and do not necessarily have to be physically configured as shown. In other words, the specific form of distribution and integration of each device is not limited to that shown in the drawings, and all or part of the devices can be functionally or physically distributed and integrated in any unit depending on various loads, usage conditions, etc.

[0111] Furthermore, the above-described configurations, functions, processing units, processing means, etc. may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. The above-described configurations, functions, etc. may also be implemented by software that causes a processor to interpret and execute programs that implement the respective functions. Information such as programs, tables, and files that implement the respective functions may be stored in a memory, a recording device such as a hard disk or a solid-state drive (SSD), or a recording medium such as an integrated circuit (IC) card, a secure digital (SD) card, or an optical disk.

[0112] 2 Measurement target application (measurement target application) 3 Measurement result acquisition application (information acquisition application) 11, 12 Physical core (processor) 21, 22 Logical core 30 PMU In-core performance counter (processor performance counter) 31 PMC, PMC31 １ ~PMC31 ４ CPU performance counter (processor performance counter) 50 CPU 60 OS / driver / privileged area 70 userland 100, 100A performance measurement device 110 counter batch setting unit 120 counter batch access unit 130 acquisition result asynchronous notification unit 140 measurement target non-operation timing determination unit 150 performance counter acquisition request unit 1000 computing system

Claims

1. A performance measurement device that accesses the performance counters of a processor and acquires the processor's performance indicators, comprising: a counter batch setting unit that continuously sets the count values ​​for each of the multiple performance counters held by a logical core; and a counter batch access unit that continuously acquires count values ​​from the multiple performance counters set by the counter batch setting unit.

2. The performance measurement device according to claim 1, characterized in that, if the requested performance index value is greater than the number of performance counters installed in the hardware, the counter batch setting unit limits the number of performance index values ​​acquired to less than or equal to the number of performance counters installed in the hardware.

3. The performance measurement device according to claim 1, characterized in that the counter batch access unit records the setting status of the value counted by the performance counter of the target core, and if the type of the count value to be acquired differs from the currently set value, requests the counter batch setting unit to set it.

4. The performance measurement device according to claim 1, further comprising a measurement target non-operation timing determination unit that detects when the application to be measured is not running and calls the counter batch access unit at the timing when the application is not running.

5. The performance measurement device according to claim 4, further comprising a performance counter acquisition request unit that requests the measurement target non-operating timing determination unit to acquire a performance index of the measurement target application.

6. The performance measurement device according to claim 5, further comprising an acquisition result asynchronous notification unit that asynchronously notifies the performance counter acquisition request unit of the performance count value acquired by the counter bulk access unit via writing to a shared memory mounted on hardware.

7. A performance measurement method for a performance measurement device that accesses performance counters of a processor and acquires performance indicators of the processor, wherein the performance measurement device executes a counter batch setting step of continuously setting count values ​​for each of the multiple performance counters of a logical core, and a counter batch access step of continuously acquiring count values ​​from the multiple performance counters set in the counter batch setting step.

8. A program for causing a computer to function as the performance measurement device according to any one of claims 1 to 6.

Images