Event identification device, task processing system, and program

Abstract

An event identification device (100) for identifying an event that wakes up a CPU core, comprising: an event acquisition unit (110) that acquires information regarding types of events which can cause the CPU core to wake up, and the times of occurrence thereof; a resting state acquisition unit (120) that acquires information regarding a point in time when a resting-state transition of the CPU core occurred; and an event / resting state integration unit (130) that identifies the type of event that caused the CPU core to wake up on the grounds of an event occurring at a time corresponding to the time when the CPU core woke up, on the basis of the information regarding the event types and the times of occurrence acquired from the event acquisition unit (110) and the information regarding the resting state and the time of transitioning thereto at the point in time when the resting-state transition occurred acquired from the resting state acquisition unit (120).

Description

Event identification device, task processing system, and program

[0001] The present invention relates to an event identification device, a task processing system, and a program.

[0002] Fig. 41 is a diagram for explaining a task management example of a task processing system. The task processing system shown in Fig. 41 includes a CPU (Central Processing Unit) 10 on hardware (HW), a task scheduler device 20 in an OS or the like, and a plurality of applications 1-1, 1-2, 1-3 (represented as L1APL, L2APL, L3APL in Fig. 41; and collectively referred to as APL1) in user space. The CPU 10 has CPU cores (CPUcore #0, CPUcore #1,...) 11. The task scheduler device 20 performs task management, prioritization, and task allocation. The task scheduler device 20, for example, allocates tasks of APL1 to a task queue 21 and assigns them from the task queue 21 to the CPU cores (CPUcore #0, CPUcore #1,...) 11.

[0003] [LPI (Low Power Idle) hardware control] The CPU 10 has a function to control the idle state of the CPU 10 by hardware control, which is called LPI. LPI is often referred to as CPUidle or C-state, and hereinafter, LPI will be described as C-state. When the CPU load decreases, C-state attempts to save power by turning off the power of a part of the circuit of the CPU 32 (Non-Patent Document 1).

[0004] Fig. 42 is a diagram showing an example of the state of C-state in a table. Since the state definition varies depending on the CPU hardware, Fig. 42 is merely a reference example. As shown in Fig. 42, there are grades C0 to C6 in the CPUidle state, and as the time without CPU 32 load becomes longer, it transitions to a deeper sleep state. Although the CPU power consumption is smaller in the deeper sleep state, on the other hand, the time required to resume increases accordingly, which may be a problem from the perspective of low latency.

[0005] The definition of C-states varies depending on the CPU hardware. For example, some models lack C4 and C5 states, while others have a state where C1 is followed by C1E. As the state deepens, the power saving effect increases, but the time required to recover from the idle state also increases.

[0006] Furthermore, the depth to which the CPUidle state transitions is controlled by the CPU hardware and is dependent on the CPU product (often not controllable by software such as the kernel).

[0007] Figure 43 is a table showing an example of the maximum values ​​for the transition time to a state (Residency) and the time required to return to the previous state (Wake-up lateny). Figure 43 represents the C-state information for the Intel Xeon CPU E5-26X0 v4 ("Intel" is a registered trademark).

[0008] Figures 44 and 45 are diagrams illustrating the C-state transitions of the CPU core used for calculations. Figure 44 shows the case where the idle time is short, and Figure 45 shows the case where the idle time is long. As shown in Figure 44, when the idle time is short, the CPU core is in a shallow sleep state, and the delay time from task occurrence to recovery is short. However, as shown in Figure 45, when the idle time is long, the CPU core is in a deep sleep state (CPUidle state: grade C6), and the delay time from task occurrence to recovery is prolonged. When the CPU falls into a deep idle state, it takes a long time to recover, which impairs real-time performance.

[0009] The above problem cannot be overlooked in systems where real-time performance is the top priority, such as the task processing system shown in Figure 41. Therefore, in task processing systems, measures are taken to disable C-states or to limit the transitions of idle states to a limited depth, such as C1. In other words, tuning is sometimes performed to prioritize real-time performance at the expense of power efficiency.

[0010] In conventional task processing systems, once a system dropped to a deep C-state, there was nothing to do but wait for it to recover. Therefore, measures were taken to prevent the system from dropping to such deep states, even at the expense of power efficiency.

[0011] [CPU Idle State Governor] The Linux kernel 4 ("Linux" is a registered trademark) provides two types of Governors to manage the CPU idle state (C-state). Neither of the two Governors' ladders and menus has a mechanism to pre-instruct the CPU idle state to wake up and prepare when a new task arrives. Therefore, when assigning a task while the CPU is in a deep state, there is a problem of a delay due to the time it takes to wake up.

[0012] Robert Schone, et.al., Wake-up latencies for processor idle states on current x86 processors, [online], Springer-Verlag Berlin Heidelberg 2024, [Retrieved October 1, 2024], Published online: 5 July 2024, Internet <URL: https: / / link.springer.com / article / 10.1007 / s00450-014-0270-z#citeas>

[0013] As mentioned above, CPUs have a hardware-controlled idle state called LPI, which attempts to conserve power by turning off the power to some of the CPU's circuits when the CPU load is low. In addition, especially on general-purpose servers, there are systems that distribute tasks across multiple CPU cores and pause the CPU cores when there are no tasks.

[0014] However, when an interrupt occurs to a CPU core in hibernation (C-state), power is wasted during the wake-up and hibernation delays. Existing technologies cannot identify the type of interrupt that occurred during hibernation, making it impossible to reduce power consumption. When an interrupt occurs during deep hibernation, a delay occurs between waking up from hibernation and hibernating again after the interrupt processing is complete. No processing can be done during these times, resulting in wasted power (Problem 1).

[0015] Furthermore, if a hardware interrupt occurs during application task processing, the relevant task processing is interrupted, and hardware interrupt processing is performed, resulting in a delay in task processing. This delay reduces application performance (latency and throughput). Existing technologies only provide information on the number of interrupts of each hardware interrupt type, not the timing of the interrupts. Therefore, it is not possible to identify the hardware interrupt type that is causing the interrupt during application task processing, making it impossible to take measures to improve performance (Problem 2).

[0016] The following describes in detail the problems of the conventional technology. (Problem 1) Problem 1 of the conventional technology will be explained with reference to Figures 46 and 47. Figure 46 is a diagram showing the wake-up and hibernation delay times when an interrupt occurs to a CPU core in a hibernation state (C-state), with time on the horizontal axis and the CPU core #1 execution state on the vertical axis. The CPU core #1 execution states are the startup state (C0) and the hibernation state (C6) (in the following explanation, notations such as (C0) represent the CPUidle state grades C0 to C6 shown in Figure 42).

[0017] As shown by the symbol aa in Figure 46, when a hardware interrupt occurs in a non-hibernating state, CPU core #1 performs hardware interrupt processing (shaded area in Figure 46; bidirectional arrow bb in Figure 46). Since CPU core #1 is in the active state (C0), there is no delay time for waking up or hibernating.

[0018] However, as shown by the symbol cc in Figure 46, if a hardware interrupt occurs in the hibernation state (C6), CPU core #1 first wakes up from the hibernation state (C6), and then performs hardware interrupt processing (shaded area in Figure 46; bidirectional arrow dd in Figure 46). After the hardware interrupt processing is completed, CPU core #1 returns to the hibernation state (C6). A wake-up delay (bidirectional arrow ee in Figure 46) occurs between waking up from the hibernation state (C6) and transitioning to the active state (C0), and a hibernation delay (bidirectional arrow ff in Figure 46) occurs between transitioning from the active state (C0) to the hibernation state (C6). Thus, when a hardware interrupt occurs in the hibernation state, delay time and wasted power (hatched area in Figure 46) occur for waking up and hibernating.

[0019] Figure 47 is a table showing the number of interrupts for each hardware interrupt type for the CPU core. As shown in Figure 47, the task scheduler (not shown) saves the number of interrupts for CPU core #1 for each hardware interrupt type IRQ1, IRQ2, and IRQ3 as "10", "30", and "30". However, with existing technology, although the number of interrupts for each hardware interrupt type is known, the actual interrupt timing (code aa, code cc in Figure 46) is unknown. For this reason, the hardware interrupt types that raised an interrupt in the wake-up state (C0) and the hibernation state (C6) (hereinafter, "raised an interrupt" means that the Kernel interrupt handler called by the occurrence of a processing request from the NIC generates an interrupt) are both unknown. When a hardware interrupt occurs in a non-hibernation state, there is no delay time for waking up and hibernation, so the unknown hardware interrupt type is not a problem; the problem lies in the unknown hardware interrupt type that raised an interrupt in the hibernation state (C6).

[0020] Existing technologies only provide information on the number of interrupts for each hardware interrupt type, not the timing of the interrupts. Therefore, it is impossible to identify the hardware interrupt type that is causing the system to enter a sleep state, making it impossible to take measures to reduce power consumption.

[0021] (Problem 2) Referring to Figure 48, problem 2 of the conventional technology will be explained. Figure 48 is a diagram showing the delay time for waking up or hibernating when an interrupt occurs to a CPU core during task processing, with time on the horizontal axis and the CPU core #1 execution state on the vertical axis. The CPU core #1 execution states are the startup state (C0) and the hibernation state (C6). As shown by the symbols gg and hh in Figure 48, when a hardware interrupt occurs during task processing, the task processing is interrupted by hardware interrupt processing (shaded area in Figure 48; bidirectional arrows ii and jj in Figure 48). As a result, the task processing completion time is extended from the completion time without an interrupt (arrow kk in Figure 48) to the completion time with an interrupt (arrow ll in Figure 48). An extension of the task processing completion time leads to a decrease in application performance.

[0022] In existing technologies, as shown in Figure 47, only the number of interrupts of each HW interrupt type is known, and the interrupt timing (codes gg and hh in Figure 48) is unknown. Therefore, it is not possible to identify which HW interrupt triggered the interrupt during the non-hibernation state, and thus it is not possible to take measures to improve performance.

[0023] In light of this background, the present invention was made, and its objective is to identify interrupts that wake up the CPU core and cause an increase in power consumption, as well as interrupts that hinder task processing.

[0024] To solve the aforementioned problems, an event identification device is provided that identifies an event that wakes up a CPU core, comprising: an event acquisition unit that acquires information on the type of event that can cause the CPU core to wake up and the time of its occurrence; a dormant state acquisition unit that acquires information on the time when the CPU core transitions to a dormant state; and an integration unit that identifies the type of event that woke up the CPU core based on the event that occurred at the time the CPU core woke up, using the event that occurred at the time corresponding to the time the CPU core woke up, based on the event that occurred at the time corresponding to the time the CPU core woke up.

[0025] According to the present invention, it is possible to identify interrupts that wake up the CPU core and cause an increase in power consumption, as well as interrupts that hinder task processing.

[0026] This is a schematic diagram of a task processing system equipped with an event identification device according to the first embodiment of the present invention. This diagram shows a comparison of the interrupt status of the CPU core and the transition of the CPU core's hibernation state in the event identification device according to the first embodiment of the present invention. This diagram shows a table of the number of interrupts for each HW interrupt type and the number of interrupts for each hibernation state (C-state) in the event identification device according to the first embodiment of the present invention. This diagram shows a comparison of the interrupt status of the CPU core and the transition of the CPU core's hibernation state in the event identification device according to the first embodiment of the present invention. This is a flowchart showing the operation of the event identification method in the event identification device according to the first embodiment of the present invention. This diagram is for explaining the processing of each step in the flowchart of the event identification device according to the first embodiment of the present invention. This diagram explains the flow of HW interrupt processing and post-interrupt data processing in the event identification device according to the second embodiment of the present invention. This diagram explains the (1) "HW interrupt type and occurrence time recording" and (2) "Hibernation state and transition time recording" operations of the event identification device according to the second embodiment of the present invention. This figure shows the interrupt status of CPU core #1 in the upper part of Figure 8, the sleep state transitions of CPU core #1 in the lower part of Figure 8, and the startup state (C0), sleep state (C1), and sleep state (C6) together. This is a flowchart showing the interrupt / sleep state integration operation of the event / sleep state integration unit (Figure 1) of the event identification device according to the second embodiment of the present invention. This figure shows the processing steps of stages I to III of the flowchart of the event identification device according to the second embodiment of the present invention. This figure shows the interrupt information [I] used in stage I of the flowchart shown in Figure 10 of the event identification device according to the second embodiment of the present invention in table form. This figure shows the sleep state information [II] used in stage II of the flowchart of the event identification device according to the second embodiment of the present invention in table form. This figure shows the interrupt / sleep state integration information [III] used in stage III of the flowchart of the event identification device according to the second embodiment of the present invention in table form. This figure shows the interrupt status and sleep state of CPU core #1 of the event identification device according to the second embodiment of the present invention together. This is a schematic configuration diagram of a task processing system equipped with the event identification device according to the third embodiment of the present invention.This figure shows a table of the number of interrupts for each HW interrupt type and the number of interrupts for each hibernation state (C-state) of the event identification device according to the third embodiment of the present invention. This is a flowchart of the interrupt identification process with a large power impact in the interrupt identification section of the event identification device according to the third embodiment of the present invention. This is a flowchart of the processing of the interrupt identification logic 1 with a large power impact in the event identification device according to the third embodiment of the present invention. This figure shows a table of the pre-interrupt hibernation state counter used in the flowchart of Figure 19. This figure explains the processing of the flowchart of Figure 19. This is a flowchart of the processing of the interrupt identification logic 2 with a large power impact in the event identification device according to the third embodiment of the present invention. This figure shows a table of the pre-interrupt hibernation state duration used in the flowchart of Figure 22. This figure explains the processing of the flowchart of Figure 22. This is a flowchart of the processing of the interrupt identification logic 3 with a large power impact in the event identification device according to the third embodiment of the present invention. This figure shows a table of the post-interrupt hibernation state counter used in the flowchart of Figure 25. This figure explains the processing of the flowchart of Figure 25. This figure shows the number of interrupts for each HW interrupt type of the CPU core of the event identification device according to the fourth embodiment of the present invention, and the number of interrupts for each CPU core in each hibernation state (C-state). This flowchart shows the processing of interrupt identification logic 1, which has a significant performance impact, of the event identification device according to the fourth embodiment of the present invention. This figure illustrates the operation of interrupt identification logic 1, which has a significant performance impact, of the event identification device according to the fourth embodiment of the present invention. This figure shows power impact interrupt type information of the event identification device according to the fourth embodiment of the present invention in table format. This flowchart shows the processing of interrupt identification logic 2, which has a significant performance impact, of the event identification device according to the fourth embodiment of the present invention. This figure shows the task processing of a high-utilization CPU core of the event identification device according to the fifth embodiment of the present invention. This figure shows the degree of interrupt impact in the task processing of the CPU core of the event identification device according to the fifth embodiment of the present invention.This is an explanatory diagram illustrating how, when the interrupt impact of the event identification device according to the fifth embodiment of the present invention is calculated, CPU core #1, which has a low interrupt tolerance, and CPU core #2, which has a high CPU utilization, are excluded from the interrupt destinations and added to CPU core #3, which has a low interrupt impact. This is a diagram showing the interrupt destination CPU mask when changing the CPU core of the event identification device according to the fifth embodiment of the present invention. This is a flowchart showing the interrupt destination change process of the interrupt destination change section of the event identification device according to the fifth embodiment of the present invention. This is a flowchart showing the process of selecting interrupts to be removed from the mask of the event identification device according to the fifth embodiment of the present invention. This is a diagram illustrating the operation of selecting interrupts to be removed from the mask of the event identification device according to the fifth embodiment of the present invention. This is a hardware configuration diagram showing an example of a computer that realizes the functions of the event identification device of the task processing system according to the embodiment of the present invention. This is a diagram illustrating an example of task management for wireless access processing at a base station. This is a diagram showing an example of C-state states in a table. This is a diagram showing an example of the maximum values ​​of the time to transition to a state (Residency) and the time required to return (Wake-up lateny) in a table. This is an image diagram of the C-state transition of the CPU core used for calculations. This is an image diagram of the C-state transition of the CPU core used for calculations. This figure shows the delay time for waking up and going to sleep when an interrupt occurs to a CPU core in a hibernating state (C-state). This figure shows the number of interrupts for each type of hardware interrupt to a CPU core in a table. This figure shows the delay time for waking up and going to sleep when an interrupt occurs to a CPU core that is processing a task.

[0027] The following describes a task processing system and the like in an embodiment of the present invention (hereinafter referred to as "this embodiment") with reference to the drawings. [Summary] The present invention relates to a device and method for identifying interrupts that cause an increase in power consumption by waking up the CPU core, and interrupts that hinder task processing, in a task processing system.

[0028] An interrupt is an event that modifies the instruction being executed by the CPU. This embodiment is an example of applying an interrupt identification device as an event identification device in a task processing system. In this embodiment, asynchronous interrupts generated by hardware devices are particularly assumed. This includes inter-processor interrupts (IPI). On the other hand, synchronous interrupts (exceptional events such as division by zero) detected by the CPU during instruction execution can also modify the instructions executed by the CPU. The present invention may also be applied to such synchronous interrupts.

[0029] (First Embodiment) Figure 1 is a schematic diagram of a task processing system equipped with an event identification device according to the first embodiment of the present invention. The first embodiment is an example of identifying the wake-up factors caused by events that can wake up a CPU core.

[0030] As shown in Figure 1, the task processing system 1000 comprises hardware (HW) 50, devices 51 on the hardware 50, an OS / driver 60, an application (APL) 70, and an event identification device 100. Device 51 is, for example, a processor, an accelerator (ACC), or a NIC (Network Interface Card). The processor consists of a CPU. The CPU has a group of CPU cores, for example, the CPU cores shown in Figure 41 (CPUcore #0, CPUcore #1, ...). In addition to the CPU, there are also processors such as a GPU (Graphic Processing Unit), FPGA (Field Programmable Gate Array), ASIC (Application Specific Integrated Circuit), and DPU (Data Processing Unit). The term "CPU core" in the claim can be read as "processor." Here, if a processor other than a CPU has an idle state function, it can be similarly applied.

[0031] The OS / driver 60 is, for example, Linux (registered trademark). The Linux kernel provides a CPU idle governor (CPU idle driver 63) to manage the CPU idle state (C-state). The C-state state of each CPU core is managed by the OS / driver 60, and the CPU idle driver 63 specifies the destination of the C-state transition when dropping a CPU core to the idle state.

[0032] The OS / driver 60 includes a Kernel (not shown), an interrupt handler 61, a scheduler 62, and a CPU idle driver 63. The Kernel is a core function of the OS and manages hardware monitoring and program execution status on a process basis. The Kernel receives notification of packet arrival from the NIC via a hardware interrupt (hardIRQ) and schedules a software interrupt (softIRQ) for packet processing.

[0033] The interrupt handler 61 is a handler hardIRQ that is called when a processing request occurs on the NIC and executes the requested processing (hardware interrupt). When an interrupt occurs, the interrupt handler 61 outputs the CPU core to which the interrupt occurred, the interrupt type, and the time of occurrence (the CPU core to which the interrupt occurred, the interrupt type, and the time of occurrence are referred to as "interrupt information").

[0034] When a context switch occurs, the scheduler 62 outputs the CPU core, the process ID after the switch, and the time of occurrence (the CPU core, process ID after the switch, and time of occurrence are referred to as "context switch information"). The scheduler 62 assigns APL tasks (for example, wireless signal processing tasks) to the task queue and then assigns them from the task queue to the CPU cores (CPUcore #0, CPUcore #1, ...).

[0035] The CPU idle driver 63 acquires the CPU core, the current state after the transition, and the transition time (the CPU core, current state after the transition, and transition time are referred to as "hibernation information") when the system transitions to a hibernation state. The task processing system 1000 distributes tasks across multiple CPU cores for processing, and suspends the CPU cores when there are no tasks.

[0036] [Event Identification Device 100] In a task processing system that distributes tasks across multiple CPU cores for processing and pauses the CPU cores when there are no tasks, the event identification device 100 identifies events that cause an increase in power consumption by waking up the CPU cores, or events that hinder task processing.

[0037] The event identification device 100 comprises an event acquisition unit 110, a hibernation state acquisition unit 120, an event / hibernation state integration unit 130 (integration unit), an interrupt identification unit 140, and an interrupt target change unit 150. As an example of the arrangement of each unit, the event acquisition unit 110 and the hibernation state acquisition unit 120 are located on the OS / driver 60, while the event / hibernation state integration unit 130, the interrupt identification unit 140, and the interrupt target change unit 150 are located on the application 70.

[0038] <Event Acquisition Unit 110> The event acquisition unit 110 acquires information on the type and time of occurrence of an event that can cause the CPU core to wake up. One of the events that can cause the CPU core to wake up is an interrupt. In this case, the event acquisition unit 110 acquires information on the interrupt type and time of occurrence.

[0039] Specifically, the event acquisition unit 110 acquires ("interrupt information") from the interrupt handler 61 when an interrupt occurs. The event acquisition unit 110 also acquires the CPU core, the process ID after the switch, and the time of occurrence ("context switch information") from the scheduler 62 when a context switch occurs.

[0040] <Hibernation State Acquisition Unit 120> The hibernation state acquisition unit 120 acquires information at the time when a hibernation state transition occurs for the CPU core. In this embodiment, the hibernation state acquisition unit 120 acquires information on the hibernation state and transition time at the time when a hibernation state transition occurs for the CPU core. The hibernation state acquisition unit 120 acquires the CPU core, the hibernation state after the transition, and the transition time ("hibernation state information") from the CPU idle driver 63 when a hibernation state transition occurs. In this embodiment, the hibernation state acquisition unit 120 acquires information on the hibernation state after the transition, but for the acquisition part of the hibernation state transition, information on the hibernation state before the transition may be used. That is, the information of the next hibernation state before the transition can be used as the information on the hibernation state after the transition.

[0041] <Event / Hibernation Integration Unit 130> Based on the event type and occurrence time information obtained from the event acquisition unit 110, and the hibernation state at the time of the hibernation transition and the transition time information, the event / hibernation integration unit 130 identifies the type of event that woke the CPU core, based on the event that occurred at the time corresponding to the time the CPU core woke up. Here, when the event / hibernation integration unit 130 identifies the event that woke the CPU core, it is necessary to check whether it transitioned to active, so it is necessary to use the information of the hibernation state after the transition.

[0042] Specifically, the event / hibernation integration unit 130 acquires interrupt information and context switch information from the event acquisition unit 110, and also acquires hibernation information from the hibernation acquisition unit 120. Furthermore, the event / hibernation integration unit 130 combines the interrupt information and context switch information from the event acquisition unit 110 with the hibernation information acquired from the hibernation acquisition unit 120 to extract hibernation information (referred to as "event / hibernation integration information") for each CPU core at the time the interrupt occurred.

[0043] The event / hibernation state integration unit 130 acquires the interrupt destination CPU core C, occurrence time T1, and interrupt type I (C, T1, and I are "interrupt information") from the event acquisition unit 110 for interrupts that occurred within a certain period.

[0044] The event and sleep state integration unit 130 acquires, from the sleep state acquisition unit 120, the CPU core C in which a context switch has occurred, the occurrence time T1, and the post-switch process ID (C, T1, PID are "context switch information") for the context switches that have occurred within a predetermined period.

[0045] The event and sleep state integration unit 130 acquires, from the sleep state acquisition unit 120, the CPU core C, the transition time T2, and the post-transition sleep state S (C, T2, S are "sleep transition information") for the C-state transitions that have occurred within a certain period.

[0046] <Interrupt identification unit 140> The interrupt identification unit 140 evaluates the power impact of an interrupt using any one of the number of interrupts for a deep sleep state, the duration of the immediately preceding sleep state, or the subsequent sleep state transition ratio, and evaluates the performance impact of the interrupt using the number of interrupts for a non-sleep state or the total interrupt processing time obtained by summing each interrupt.

[0047] The interrupt identification unit 140 acquires event and sleep state integration information (Figure 9 described later) from the event and sleep state integration unit 130, and for each CPU core, identifies the interrupt type ( "power impact interrupt type information") that increases the number of interrupts for a deep sleep state and affects the power. (See the third embodiment described later.) Also, the interrupt identification unit 140 identifies, for each CPU core, the interrupt type ( "performance impact interrupt type information") that increases the number of interrupts for a non-sleep state and affects the performance of the application. (See the fourth embodiment described later.)

[0048] <Interrupt destination change unit 150> The interrupt destination change unit 150 calculates the interrupt impact degree of an application due to an interrupt based on the CPU usage rate of the CPU core, and excludes a CPU core with an interrupt impact degree of a predetermined value or more from the interrupt destination, or adds a CPU core with an interrupt impact degree of a predetermined value or less to the interrupt destination. (See the fifth embodiment described later.)

[0049] Specifically, the interrupt target change unit 150 obtains CPU usage information from the OS / driver 60. The interrupt target change unit 150 also obtains interrupt tolerance from the operator. The interrupt target change unit 150 combines the CPU usage information obtained from the OS / driver 60 and the interrupt tolerance obtained from the operator to determine the interrupt impact of each CPU core. For example, the interrupt target change unit 150 changes the interrupt target from a CPU core with high interrupt impact to a CPU core with low interrupt impact.

[0050] The operation of the event identification device 100 configured as described above will be explained below. (Explanation of principle) First, the basic concept of the present invention will be explained. As shown in Figure 46, when an interrupt occurs in a CPU core in a hibernation state (C-state), power is wasted during the wake-up or hibernation delay time. However, existing technologies cannot identify the type of interrupt that occurred in the hibernation state, and therefore cannot take measures to reduce power consumption.

[0051] This invention acquires information on the type of hardware interrupt and its occurrence time (first information), and information on the state of hibernation and the transition time (second information). By combining the first and second information, it identifies hardware interrupt types that frequently generate interrupts in deep hibernation states (e.g., C6).

[0052] The method for identifying the type of hardware interrupt according to the present invention will be explained with reference to Figures 2 and 3. Figure 2 is a diagram comparing the interrupt status of a CPU core and the transition of the CPU core's hibernation state. The horizontal axis in the upper part of Figure 2 shows the time for representing the hardware interrupt type and interrupt occurrence time of CPU core #1, and the horizontal axis in the lower part of Figure 2 shows the time for representing the transition hibernation state and transition time of CPU core #1. The scale (granularity) of the time in the upper part of Figure 2 and the time in the lower part of Figure 2 are the same.

[0053] As shown in the interrupt status of CPU core #1 in the upper part of Figure 2, an interrupt of type IRQ1 occurs at time t1 (IRQ1, t1), an interrupt of type IRQ2 occurs at time t2 (IRQ2, t2), and an interrupt of type IRQ3 occurs at time t3 (IRQ3, t3) (the same notation will be used hereafter).

[0054] As shown in the lower part of Figure 2, the transition of CPU core #1 to the hibernation state, the upward arrows (thick solid arrows in Figure 2) represent the combinations of the wake state (C) and time (T) when transitioning from the hibernation state to the wake state (C0, T1), (C0, T3), (C0, T5), and the downward arrows (thick dashed arrows in Figure 2) represent the combinations of the hibernation state (C) and time (T) when transitioning from the wake state to the hibernation state (C1, T2), (C6, T4), (C6, T6) (the same notation will be used hereafter). As shown in Figure 2, the wake state is (C0), but the hibernation state varies depending on the state of C-state, such as (C1), (C6), etc. Here, we are focusing only on the transition to the hibernation state.

[0055] Since the time scales in the upper and lower parts of Figure 2 are the same, by combining "HW interrupt type, occurrence time" and "transition / dormancy state, transition time," it is possible to identify the HW interrupt type that frequently generates interrupts in deep dormancy states (C6). In Figure 2, when (IRQ2, t2) and (IRQ3, t3) are shown in the upper part of Figure 2, deep dormancy states (C6, T4) and (C6, T6) shown in the lower part of Figure 2 occur frequently. In this example, HW interrupt types (IRQ2) and (IRQ3) are generating interrupts in dormancy states (C6). The present invention identifies the HW interrupt type that interrupted into a dormancy state by recording not only the number of interrupts for each HW interrupt type, but also what kind of dormancy or startup state the interrupt occurred in.

[0056] Figure 3 is a table showing the number of interrupts for each hardware interrupt type for the CPU core, and the number of interrupts for each hibernation state (C-state). Figure 3 is a table showing the number of interrupts for CPU core #1. The table in Figure 3 is created and recorded by combining the "HW interrupt type, occurrence time" shown in the upper part of Figure 2 and the "transition hibernation state, transition time" shown in the lower part of Figure 2. In Figure 3, the number of interrupts, the number of C0 interrupts, the number of C1 interrupts, and the number of C6 interrupts are recorded for each hardware interrupt type IRQ1, IRQ2, and IRQ3 of CPU core #1. The number of interrupts shown in Figure 3 is the sum of the number of C0 interrupts, the number of C1 interrupts, and the number of C6 interrupts. As shown in Figure 3, hardware interrupt type IRQ3 has a C6 interrupt count of "20" in the deep hibernation state (C6). It can be seen that hardware interrupt type IRQ3 is a hardware interrupt type that generates many interrupts in the deep hibernation state (C6). Based on the table in Figure 3, the type of hardware interrupt that triggered the shutdown state can be identified. Identifying the hardware interrupt type allows for measures to reduce power consumption and improve performance (see below).

[0057] [Basic Operation] The event identification device 100 according to the first embodiment records information on the type and time of occurrence of an event that may cause the CPU core to wake up, and information on the state of the CPU core at the time of the transition to a dormant state and the time of the transition. The event identification device 100 then identifies the type of event that woke up the CPU core from events that occurred at the same time as the CPU core woke up.

[0058] The event identification device 100 (Figure 1) performs the following operations (1)-(3). (1) Event acquisition The event acquisition unit 110 (Figure 1) records the type of event and the time of occurrence of an event that can wake up a CPU core. Specifically, events include "interrupt occurrence" and "context switch occurrence". To handle these two events, the event acquisition unit 110 acquires and records the CPU core to which the interrupt occurred, the interrupt type, and the time of occurrence (interrupt information) from the interrupt handler 61 when an interrupt occurs. In addition, the event acquisition unit 110 acquires and records the CPU core, the process ID after the switch, and the time of occurrence (context switch information) from the scheduler 62 when a context switch occurs.

[0059] (2) CPU Core Hibernation State Acquisition The hibernation state acquisition unit 120 (Figure 1) records the hibernation state and transition time at the time when the CPU core transitions to a hibernation state. Specifically, the hibernation state acquisition unit 120 acquires the CPU core, the hibernation state after the transition, and the transition time (hibernation state information) from the CPU idle driver 63 when a hibernation state transition occurs.

[0060] (3) Interrupt / Hibernation Integration Event / Hibernation Integration Unit 130 (Figure 1) combines (1) event acquisition and (2) acquisition of the hibernation state of the CPU core to identify the type of event that woke up the CPU core from events occurring at the same time as the CPU core's wake-up. Specifically, the Event / Hibernation Integration Unit 130 combines interrupt information and context switch information from the Event Acquisition Unit 110 with hibernation information acquired from the Hibernation Acquisition Unit 120 to extract hibernation information ("Event / Hibernation Integration Information") (Figure 9 below) for each CPU core at the time the interrupt occurred.

[0061] Figure 4 is a diagram illustrating the basic operation of the event identification device 100. Figure 4 shows a comparison of the interrupt status of the CPU core and the transition of the CPU core to a dormant state. The horizontal axis in the upper part of Figure 4 shows the time for representing the HW interrupt type and interrupt occurrence time of CPU core #1, and the horizontal axis in the lower part of Figure 4 shows the time for representing the transition dormant state and transition time of CPU core #1 (same notation as in Figure 2).

[0062] As shown in the interrupt status of CPU core #1 in the upper part of Figure 4, an interrupt of type IRQ1 occurs at time t1 (IRQ1, t1), a context switch (CS2) (indicated as a in Figure 4) occurs at time t2 (CS2, t2), and an interrupt of type IRQ3 occurs at time t3 (IRQ3, t3).

[0063] As shown in the lower part of Figure 4, the hibernation state transitions of CPU core #1, the upward arrows (thick solid arrows in Figure 4) represent the combinations of the wake state (C) and time (T) when transitioning from hibernation to wake state (C0, T1), (C0, T3), (C0, T5), and the downward arrows (thick dashed arrows in Figure 4) represent the combinations of the hibernation state (C) and time (T) when transitioning from wake state to hibernation (C1, T2), (C6, T4), (C6, T6).

[0064] The difference between Figure 4 and Figure 2 is that the wake-up of CPU core #1 at time t2 is not due to an interrupt but to a context switch (CS2) (CS2, t2). That is, as shown in the dashed-dot box b in Figure 4, it was a context switch (CS2) that woke up CPU core #1. Also, as shown in the dashed-dot box b in Figure 4, it was a hardware interrupt type (IRQ3) interrupt (IRQ3, t3) that woke up CPU core #1.

[0065] The event / hibernation state integration unit 130 (Figure 1) combines the events of CPU core #1 shown in the upper part of Figure 4 (context switch (CS2, t2) and interrupt of hardware interrupt type (IRQ3) (IRQ3, t3)) and the hibernation state transitions of CPU core #1 shown in the lower part of Figure 4 ((C0, T3) and (C0, T5)) to identify the type of event that woke up CPU core #1 from events that occurred at the same time as CPU core #1 woke up.

[0066] [Flowchart] Figure 5 is a flowchart showing the operation of the event identification method of the event identification device 100. Figure 6 is a diagram illustrating the processing of each step in the flowchart shown in Figure 5. Figure 6 shows the events of CPU core #1 (context switch (CS2) and HW interrupt type interrupt (IRQ1)) together with the startup state (C0), hibernation state (C1), and hibernation state (C6).

[0067] In step S11, the event / hibernation state integration unit 130 obtains the interrupt destination CPU core C, occurrence time T1, and interrupt type I (interrupt information) from the event acquisition unit 110 for interrupts that occurred within a predetermined period. Interrupts can be obtained by tracepoint within the interrupt handler call process of the kernel of the OS / driver 60 (Figure 1) (Figure 7 below).

[0068] In step S12, the event / hibernation integration unit 130 obtains the following information from the hibernation acquisition unit 120 regarding context switches that occurred within a predetermined period: the CPU core C where the context switch occurred, the time of occurrence T1, and the process ID after the switch (indicated as PID in Figure 6) (context switch information). Context switches can be obtained from the tracepoint in the kernel scheduler of the OS / driver 60.

[0069] In step S13, the event / hibernation state integration unit 130 acquires the CPU core C, transition time T2, and post-transition hibernation state S (hibernation transition information) from the hibernation state acquisition unit 120 for C-state transitions that occurred within a predetermined period. C-state transitions can be acquired by tracepoint in the CPU idle driver 63 (Figure 1).

[0070] In step S14, the event / hibernation state integration unit 130 focuses on the CPU core C and wake-up time T. In step S15, the event / hibernation state integration unit 130 determines whether the acquired hardware interrupt type and occurrence time, and the acquired hibernation state and transition time, are interrupts that occurred simultaneously.

[0071] If the above interrupts occurred simultaneously (S15: Yes), in step S16, the event / hibernation state integration unit 130 identifies the type of interrupt that caused the CPU core C to wake up from the simultaneously occurring interrupt information (indicated by d in Figure 6: HW interrupt type IRQ1) and terminates the processing of this flow.

[0072] If the interrupts did not occur simultaneously as described above (S15: No), in step S17 the event / hibernation state integration unit 130 identifies the process ID (indicated as PID in Figure 6) that caused the CPU core C to wake up from the simultaneously occurring context switch information (indicated as e in Figure 6: context switch (CS2)) and terminates the processing of this flow.

[0073] (Second Embodiment) The second embodiment is an example of creating combination information of a certain period of a pause state and interrupts using event / pause state integration information (Figure 9 below) recorded by the event / pause state integration unit 130. First, we will describe the accuracy of each time recording and methods for reducing the amount of processing when recording the time of occurrence of a hardware interrupt and the pause state and transition time at the time a pause state transition occurs.

[0074] <Accuracy and Processing Load Reduction for Recording Hardware Interrupt Type and Occurrence Time / Hibernation State and Transition Time> When recording the hardware interrupt type and occurrence time when a hardware interrupt occurs to a CPU core, and when recording the hibernation state and transition time when a hibernation state transition occurs for the relevant CPU core, the following measures will be taken to improve accuracy and reduce processing load.

[0075] Figure 7 is a diagram illustrating the flow of HW interrupt processing and post-interrupt data processing. The hardware 200 shown in Figure 7 corresponds to the hardware (HW) 50 in Figure 1. The common processing [Linux kernel] 210, interrupt handler call 220, softirq processing [Linux kernel] 230, and interrupt / hibernation state integrated eBPF frontend 240 shown in Figure 7 correspond to the OS / driver 60. The OS is Linux®, and the kernel implements the Linux kernel. The interrupt handler call 220 has a tracepoint, an interrupt handler (ISR1) 221, and an interrupt handler (ISR2) 222.

[0076] Hardware 200 detects the interrupt and switches to the interrupt context. Common processing [Linux kernel] 210 performs minimal processing to provide an immediate response to hardware 200. Specifically, common processing [Linux kernel] 210 sets a traceable point (tracepoint) immediately before the interrupt handler call (see below).

[0077] The interrupt handler call 220 starts the interrupt handler (ISR1) 221 and the interrupt handler (ISR2) 222. At this point, the common processing [Linux kernel] 210 is completed, and the process moves on to the softirq processing [Linux kernel] 230.

[0078] The softirq process [Linux kernel] 230 processes delayable operations at a different time. This completes the hardware interrupt processing.

[0079] Next, the process moves to data processing after the interrupt. The interrupt / hibernation state integrated eBPF frontend 240 associates the interrupt with the C-state from each event data, based on the interrupt information 260 acquired by the interrupt acquisition eBPF program 250 and the hibernation state information 280 acquired by the hibernation state acquisition eBPF program 270.

[0080] Returning to the explanation of the common process [Linux kernel] 210 above, the common process [Linux kernel] 210 executes the interrupt acquisition eBPF program 250 or the hibernation state acquisition eBPF program 270, specifying a traceable point (tracepoint) immediately before the interrupt handler call.

[0081] The interrupt acquisition eBPF program 250 executes an interrupt start function within the Linux kernel when an event occurs at the tracepoint, and obtains the time relative to the monotonic clock. The information obtained by executing the function is stored as interrupt information 260 in a storage unit (not shown).

[0082] The interrupt start function is as follows: interrupt_start_function() { start_time = kernel_function() that obtains the time using a monotonic clock;}

[0083] The sleep state acquisition eBPF program 270 acquires sleep state transition information in the same way as the interrupt acquisition eBPF program 250, and stores it as sleep state information 280 in a storage unit (not shown).

[0084] The above process can be summarized as follows: • By setting a point within the kernel where the occurrence of a specific event can be tracked, the exact time of the event is obtained. For example, the tracepoint immediately before the interrupt handler is used.

[0085] - By implementing a program in the kernel space that records minimal information such as the time when the above events occur, performance overhead is reduced. Data processing and aggregation are performed by user programs. For example, functions are executed in the kernel space using eBPF, and data processing is performed by the eBPF frontend.

[0086] - For time stamping, a monotonic clock that does not drift or go backward due to settings is used as the basis to maintain the chronological order of various events and correctly correlate them. For example, the time is obtained based on CLOCK_MONOTONIC, CLOCK_BOOTTIME, etc. The above describes methods for improving the accuracy of each time recording and reducing processing load.

[0087] [Creating information linking interrupt type and hibernation state change] In the second embodiment, the event identification device 100 limits the events that can cause the CPU core to wake up to interrupts, and records information on the interrupt type and occurrence time. By combining interrupt events over a certain period with the occurrence time of the CPU core's hibernation state transition, it creates information linking the interrupt type and hibernation state change on the relevant CPU core.

[0088] Specifically, in the event identification device 100 according to the second embodiment, the event acquisition unit 110 acquires information on the interrupt type and occurrence time, and the event / hibernation state integration unit 130 combines the interrupts acquired from the event acquisition unit 110 and the hibernation state and transition time acquired from the hibernation state acquisition unit 120 for a predetermined period to create event / hibernation state integration information that associates the interrupt type and hibernation state changes on the CPU core.

[0089] The second embodiment uses the function for recording the occurrence of a specific event as described in the first embodiment (recording in the event / hibernation state integration unit 130) to (1) record the type of hardware interrupt and the time of occurrence when a hardware interrupt occurs to the CPU core (Figure 8). It also (2) records the hibernation state and the time of transition when a hibernation state transition occurs to the CPU core (Figure 8). Then, the information from (1) and (2) above is combined to create information that associates the interrupt type and the hibernation state change on the CPU core (3) (Figure 9). The operations of (1) "recording hardware interrupt type and time of occurrence", (2) "recording hibernation state and transition time", and (3) "creation of association information" will be explained below with reference to Figures 8 and 9.

[0090] Figure 8 is a diagram illustrating the operation of (1) "HW interrupt type and occurrence time recording" and (2) "Hibernation state and transition time recording". Figure 8 shows a comparison of the interrupt status of the CPU core and the hibernation state transition of the CPU core. The horizontal axis in the upper part of Figure 8 shows the time for representing the HW interrupt type and interrupt occurrence time of CPU core #1, and the horizontal axis in the lower part of Figure 8 shows the time for representing the transition hibernation state and transition time of CPU core #1 (notation is the same as in Figure 4).

[0091] <1. CPU Core #1 Interrupt Information> As shown in the upper part of Figure 8, the interrupt status of CPU Core #1 is as follows: an interrupt of HW interrupt type IRQ1 occurs at time t1 (IRQ1, t1), an interrupt of HW interrupt type IRQ2 occurs at time t2 (IRQ2, t2), and an interrupt of HW interrupt type IRQ3 occurs at time t3 (IRQ3, t3). The "1. CPU Core #1 Interrupt Information" shown in the upper part of Figure 8 is recorded by the above (1) "HW Interrupt Type and Occurrence Time Recording" operation.

[0092] <2. CPU Core #1 Hibernation Information> As shown in the hibernation state transition of CPU Core #1 in the lower part of Figure 8, the upward arrows (thick solid arrows in Figure 8) represent the combinations of the startup state (C) and time (T) when transitioning from hibernation to startup (C0, T1), (C0, T3), (C0, T5), and the downward arrows (thick dashed arrows in Figure 8) represent the combinations of the hibernation state (C) and time (T) when transitioning from startup to hibernation (C1, T2), (C6, T4), (C6, T6). The "2. CPU Core #1 Hibernation Information" shown in the lower part of Figure 8 is recorded by the operation of (2) "Hibernation State and Transition Time Recording" described above. Here, the temporal relationship between the interrupt status of CPU Core #1 in the upper part of Figure 8 and the hibernation state transition of CPU Core #1 in the lower part of Figure 8 is shown by the dashed line in Figure 8 connecting the top and bottom.

[0093] As can be seen from the corresponding dashed lines in Figure 8, CPU core #1 was woken up by an interrupt of hardware interrupt type (IRQ2) (IRQ2,t2) and an interrupt of hardware interrupt type (IRQ3) (IRQ3,t3).

[0094] The event / hibernation state integration unit 130 (Figure 1) combines the interrupts of hardware interrupt type (IRQ2) (IRQ2,t2) and hardware interrupt type (IRQ3) (IRQ3,t3) of CPU core #1 shown in the upper part of Figure 8, with the hibernation state transitions of CPU core #1 ((C0,T3) and (C0,T5)) shown in the lower part of Figure 4, to identify the type of event that woke up CPU core #1 from events that occurred at the same time as CPU core #1 woke up.

[0095] <3. Integrated CPU Core #1 Event and Hibernation Information> Figure 9 is a diagram that shows the interrupt status of CPU Core #1 in the upper part of Figure 8, the hibernation state transitions of CPU Core #1 in the lower part of Figure 8, and the active state (C0), hibernation state (C1), and hibernation state (C6) together (using the same notation as in Figure 6). The "3. Integrated CPU Core #1 Event and Hibernation Information" shown in Figure 9 is created by the above (3) "Association Information Creation" operation. Due to the transition from hibernation state to active state (C0, T1) in "2. CPU Core #1 Hibernation Information" in the lower part of Figure 8, CPU Core #1 is in the active state (C0) at the start shown in Figure 9 (Figure 9, code f).

[0096] Even if a hardware interrupt of type IRQ1 occurs at time T1 (IRQ1, T1) (Figure 9, code g) while in the startup state (C0), CPU core #1 maintains the startup state (C0). After a certain period of time has elapsed since the completion of task processing, CPU core #1 transitions to a hibernation state (C1, T2) and returns to the hibernation state (C1) (Figure 9, code h).

[0097] When CPU core #1 is in a hibernation state (C1), it receives an interrupt (IRQ2,T2) of the hardware interrupt type (IRQ2) shown in the upper part of Figure 8 (Figure 9, code i), transitions from the hibernation state (C1) to the wake-up state (C0), and becomes the wake-up state (C0) (Figure 9, code j).

[0098] CPU core #1 transitions to a deeper hibernation state (C6, T4) by fulfilling the specified C-state conditions, and enters the deeper hibernation state (C6) (Figure 9, code k). When CPU core #1 is in the deep hibernation state (C6), it receives an interrupt (IRQ3, T5) of the HW interrupt type (IRQ3) shown in the upper part of Figure 8 (Figure 9, code l), and transitions from the deep hibernation state (C6) to the wake state (C0), and enters the wake state (C0) (Figure 9, code m).

[0099] CPU core #1, by fulfilling the specified C-state conditions, transitions back to a deep hibernation state (C6, T6), and then to an even deeper hibernation state (C6) (Figure 9, code n).

[0100] In this embodiment, the interrupt information of CPU core #1, namely interrupts of HW interrupt type IRQ1 (IRQ1, T1) (Figure 9, code g), interrupts of HW interrupt type IRQ1 (IRQ2, T2) (Figure 9, code i), and interrupts of (IRQ3) (IRQ3, T5) (Figure 9, code l), and the hibernation state of CPU core #1, namely the wake-up state (C0), hibernation state (C1), and hibernation state (C6), are combined by viewing the intersection points of these two sets of information on the time axis. Figure 9 shows the integrated event and hibernation state information of CPU core #1. In this embodiment, the relationship between interrupts and hibernation state changes is clarified for CPU core #1. The above explanation has been given using CPU core #1 as a representative example of the CPU cores, but the relationship between interrupts and hibernation state changes can be clarified for CPU core #n (where n is any natural number) using a similar method.

[0101] [Examples of Interrupt / Hibernation State Integration Application] Examples of interrupt / hibernation state integration application of the event identification device 100 will be described with reference to Figures 10 to 15. Figure 10 is a flowchart showing the operation of interrupt / hibernation state integration of the event / hibernation state integration unit 130 (Figure 1). Figure 11 is a diagram showing the processing steps (records) of each step (stages I to III) of the flowchart shown in Figure 10. Figure 12 is a diagram showing the interrupt information [I] used in step S21 (stage I) of the flowchart shown in Figure 10 in a table format. Figure 13 is a diagram showing the hibernation state information [II] used in step S22 (stage II) of the flowchart shown in Figure 10 in a table format. Figure 14 is a diagram showing the interrupt / hibernation state integration information [III] used in step S23 (stage III) of the flowchart shown in Figure 10 in a table format. Figure 15 is a diagram visualizing the processing steps shown in Figure 10. Figure 15 is a diagram that shows the interrupt status and hibernation state of CPU core #1 together, similar to Figure 9.

[0102] <Stage I> In step S21 of Figure 10, the event / hibernation state integration unit 130 acquires the interrupt destination CPU core C, occurrence time T1, and interrupt type I (interrupt information) from the event acquisition unit 110 (Figure 1) for interrupts that occurred within a predetermined period (Stage I). Figure 12 shows the interrupt information [I] acquired from the event acquisition unit 110. In Figure 12, the occurrence time T1 and interrupt type I are shown for each ID of CPU core #1, and so on, recording CPU core #2, etc. in the same manner.

[0103] The CPU core C that receives the interrupt, the time of occurrence T1, and the interrupt type I (C, T1, I are "interrupt information") are shown in (C, T1, I) of the interrupt information [I] in Figure 11. For example, (C, T1, I) = (1, 50, 1) of the interrupt information [I] in Figure 11 indicates that in the startup state (C0), the CPU core is CPU core #1, the time of occurrence T1 is 50 (unit is, for example, μs) (see Figure 15), and the interrupt type I is HW interrupt type IRQ1.

[0104] Similarly, interrupt information [I] (1,120, 2) in Figure 11 indicates that in hibernation state (C1), the CPU core is CPU core #1, the occurrence time T1 is 120 (see Figure 15), and the interrupt type I is HW interrupt type IRQ2. Also, interrupt information [I] (1,120, 3) in Figure 11 indicates that in hibernation state (C6), the CPU core is CPU core #1, the occurrence time T1 is 120 (see Figure 15), and the interrupt type I is HW interrupt type IRQ3. Furthermore, interrupt information [I] (2,50, 4) in Figure 11 indicates that in hibernation state (C1), the CPU core is CPU core #2, the occurrence time T1 is 50, and the interrupt type I is HW interrupt type IRQ4. Note that Figure 15 does not show the event / hibernation state integrated information for CPU core #2, but the situation for CPU core #2 is the same as in Figure 15.

[0105] Returning to the flow in Figure 10, the acquired interrupt information [I] (C, T1, I) is passed to the process in step S23 (stage III) and integrated as interrupt / hibernation status unification information [III]. Looking at this process in the processing steps of Figure 11, it is represented by the passing of the interrupt information [I] (1, 50, 1) in Figure 11 to the interrupt / hibernation status unification information [III] (dashed arrow o in Figure 11). Similarly, (1,120, 2) of the interrupt information [I] in Figure 11 is passed to the interrupt / hibernation status control information [III] (dashed arrow p in Figure 11), (1,200, 3) of the interrupt information [I] in Figure 11 is passed to the interrupt / hibernation status control information [III] (dashed arrow q in Figure 11), and (2,50, 4) of the interrupt information [I] in Figure 11 is passed to the interrupt / hibernation status control information [III] (dashed arrow r in Figure 11).

[0106] <Stage II> In step S22 of Figure 10, the event / hibernation state integration unit 130 acquires the CPU core C, transition time T2, and post-transition hibernation state S (C, T2, S are "hibernation transition information") from the hibernation state acquisition unit for C-state transitions that occurred within a predetermined period (Stage II). Figure 13 shows the hibernation state information [II] acquired from the hibernation state acquisition unit 120. In Figure 13, the transition time T2 and post-transition hibernation state S are shown for each ID of CPU core #1, and similarly for CPU core #2, etc.

[0107] The interrupt recipient CPU core C, transition time T2, and post-transition hibernation state S (interrupt information) are indicated by (C, T2, S) in the hibernation state information [II] of Figure 11. For example, (C, T2, S) = (1, 0, 0) in the hibernation state information [II] of Figure 11 indicates that in the startup state (C0), the CPU core is CPU core #1, the transition time T2 is 0 (see Figure 15), and the post-transition hibernation state S is 0 (i.e., startup state (C0)).

[0108] Similarly, (1,100, 1) in the hibernation information [II] of Figure 11 means that in the startup state (C0), the CPU core is CPU core #1, the transition time T2 is 100 (see Figure 15), and the post-transition hibernation state S is 1 (i.e., hibernation state (C1)). (1,120, 0) in the hibernation information [II] of Figure 11 means that in the hibernation state (C1), the CPU core is CPU core #1, the transition time T2 is 120 (see Figure 15), and the post-transition hibernation state S is 0 (i.e., startup state (C0)). (1,140, ​​6) in the hibernation information [II] of Figure 11 means that in the startup state (C0), the CPU core is CPU core #1, the transition time T2 is 140 (see Figure 15), and the post-transition hibernation state S is 6 (i.e., hibernation state (C6)). In the hibernation information [II] of Figure 11, (1,200, 0) indicates that in hibernation state (C6), the CPU core is CPU core #1, the transition time T2 is 200 (see Figure 15), and the post-transition hibernation state S is 0 (i.e., the startup state (C0)). In the hibernation information [II] of Figure 11, (1,220, 6) indicates that in the startup state (C0), the CPU core is CPU core #1, the transition time T2 is 220 (see Figure 15), and the post-transition hibernation state S is 6 (i.e., hibernation state (C6)). In the hibernation information [II] of Figure 11, (2, 0, 0) indicates that in the startup state (C0), the CPU core is CPU core #2, the transition time T2 is 0, and the post-transition hibernation state S is 0 (i.e., the startup state (C0)).

[0109] Returning to the flow in Figure 10, the acquired hibernation information [II] (C, T2, S) is passed to the process in step S23 (stage III) and integrated as interrupt / hibernation unified information [III]. Looking at this process in the processing steps of Figure 11, it is represented by the passing of the hibernation information [II] (1,0,0) in Figure 11 to the interrupt / hibernation unified information [III] (double-dotted arrow s in Figure 11).

[0110] Similarly, (1,100, 1) from the hibernation information [II] in Figure 11 is passed to the interrupt / hibernation information [III] (dotted arrow t in Figure 11), (1,120, 0) from the hibernation information [II] in Figure 11 is passed to the interrupt / hibernation information [III] (dotted arrow u in Figure 11), and (1,140, ​​6) from the hibernation information [II] in Figure 11 is passed to the interrupt / hibernation information [III] (dashed arrow v in Figure 11). Furthermore, (1,200, 0) from the hibernation information [II] in Figure 11 is passed to the interrupt / hibernation information [III] (double-dotted arrow w in Figure 11), (1,220, 6) from the hibernation information [II] in Figure 11 is passed to the interrupt / hibernation information [III] (double-dotted arrow x in Figure 11), and (2,0, 0) from the hibernation information [II] in Figure 11 is passed to the interrupt / hibernation information [III] (double-dotted arrow y in Figure 11).

[0111] <Stage III> In step S23 of Figure 10, the event / hibernation state integration unit 130 combines interrupt information and hibernation state information for interrupts and C-state transitions that occurred within a predetermined period, rearranges them based on their respective transition times, and creates the interrupt destination CPU core C, time T, interrupt type I, and post-transition hibernation state S ((C, T, I, S) are "event / hibernation state integration information"), and then terminates the processing of this flow (Stage III).

[0112] Figure 14 is a diagram showing the event / hibernation state integration unit 130 combining the interrupt information [I] (Figure 12) acquired from the event acquisition unit 110 and the hibernation state information [II] (Figure 13) acquired from the hibernation state acquisition unit 120, rearranging them based on their respective transition times, and displaying the interrupt destination CPU core C, time T, interrupt type I, and post-transition hibernation state S ("event / hibernation state integration information") in a table. In Figure 14, "null" for "interrupt type" indicates the case where only a c-state transition occurs, and "0" for "post-transition hibernation state" indicates the case where only an interrupt occurs. Also, in Figure 14, if the occurrence time T1 (Figure 12) and transition time T2 (Figure 13) are close and the post-transition hibernation state is C0, it is determined that the system was woken up by an interrupt and the "time T" is displayed as a single value.

[0113] Returning to the flow in Figure 10, in step S23 (stage III), the event / hibernation state integration unit 130 combines (C, T1, I) of the interrupt information [I] acquired in step S21 and (C, T2, S) acquired in step S22 to create event / hibernation state integration information (C, T, I, S) (III in Figure 11). For example, as shown in Figure 15, the event / hibernation state integration unit 130 combines (1,120, 2) of the interrupt information [I] in Figure 11 (dashed arrow q in Figure 11) and (1,120, 0) of the hibernation state information [II] in Figure 11 (double-dotted arrow u in Figure 11), where the occurrence time T1 and transition time T2 are the same time 120, to create event / hibernation state integration information (C, T, I, S) = (1,120, 2, 0).

[0114] As described above, if only a C-state transition occurs, the interrupt type I is set to null (1, 100, null, 1). Also, if only an interrupt occurs, the post-transition hibernation state S is set to C0 (1, 50, 1, 0). Furthermore, if T1 and T2 are close together and the post-transition hibernation state is C0, it is determined that the system woke up due to an interrupt, and the two records are combined into one (1, 120, 2, 0).

[0115] Based on Figure 15, the flow in Figure 10 shows the interrupt and hibernation state integration processing, and Figure 11 shows the processing steps (records) of each step (stages I to III) of the flowchart shown in Figure 10. Figures 12 to 14 are the recording information used in the flow in Figure 10. Incidentally, as described in the first embodiment, in Figure 15, the event and hibernation state integration unit 130 combines the interrupt information and context switch information from the event acquisition unit 110 with the hibernation state information acquired from the hibernation state acquisition unit 120, and extracts and records the hibernation state information (event and hibernation state integration information) (Figure 9) at the time the interrupt occurred for each CPU core.

[0116] (Third Embodiment) In the third embodiment, the number of times the CPU core was woken from hibernation for each interrupt type is calculated from the information obtained in the second embodiment, and the interrupt types with a large power impact are identified.

[0117] Figure 16 is a schematic diagram of a task processing system 1000 equipped with an event identification device 100 according to a third embodiment of the present invention. Figure 16 has the same configuration as Figure 1, but the relevant functional unit of interest is highlighted with a thick border. In the event identification device 100 according to the third embodiment, the event / hibernation state integration unit 130 calculates the number of times the CPU core has been woken from hibernation for each interrupt type based on the event / hibernation state integration information it has created, and identifies interrupt types whose power impact of the interrupt is greater than a predetermined amount. The interrupt identification unit 140 evaluates the power impact of the interrupt using one of the following: the number of interrupts to a deep hibernation state, the duration of the previous hibernation state, or the subsequent hibernation state transition ratio.

[0118] In Figure 16, the interrupt identification unit 140 of the event identification device 100 according to the third embodiment acquires event / hibernation state integration information from the event / hibernation state integration unit 130 and identifies, for each CPU core, the interrupt type (power-influencing interrupt type information) that increases interrupts and affects power during deep hibernation. The interrupt destination change unit 150 acquires CPU usage status from the OS. The interrupt destination change unit 150 also acquires interrupt tolerance from the operator. The interrupt destination change unit 150 combines this information to determine the interrupt impact of the CPU core. The interrupt destination change unit 150 changes the interrupt destination from a CPU core with high interrupt impact to a CPU core with low interrupt impact.

[0119] The operation of the event identification device 100 configured as described above will be explained below. [Power-Impact Interrupt Type Identification Operation] The interrupt identification unit 140 shown in Figure 16 calculates the number of times the CPU core was woken from hibernation for each interrupt type from the information obtained in the second embodiment that associates the interrupt type and hibernation state change on the CPU core, and identifies the interrupt type with a large power impact. The power impact of an interrupt can be evaluated, for example, using the number of interrupts for a deep hibernation state, the duration of the previous hibernation state, and the subsequent hibernation state transition rate.

[0120] Figure 17 is a table showing the number of interrupts for each hardware interrupt type for the CPU core and the number of interrupts for each hibernation state (C-state). The table shown in Figure 17 is recorded in the CPU core #1 pre-interrupt hibernation counter. The table shown in Figure 17 (CPU core #1 pre-interrupt hibernation counter) is created based on "3. CPU core #1 event / hibernation integrated information" shown in Figure 9. As indicated by the white arrow z in Figure 17, hardware interrupt type IRQ3 has a C6 interrupt count of "20" in deep hibernation (C6). It can be seen that hardware interrupt type IRQ3 is a hardware interrupt type that raises many interrupts in deep hibernation (C6). The interrupt identification unit 140 identifies the hardware interrupt type that raised an interrupt in hibernation (here, it identifies hardware interrupt type IRQ3 with a C6 interrupt count of "20" in deep hibernation (C6)). The interrupt identification unit 140 identifies the type of hardware interrupt, and for interrupts that have a large power impact, for example, it prevents the system from entering a deep sleep state (C6) in order to reduce power consumption.

[0121] Examples of specific algorithms for hardware interrupt types are as follows: • The number of interrupts for deep hibernation states exceeds a certain limit. • The duration of the preceding hibernation state is below a certain limit. • The transition ratio to subsequent deep hibernation states is below a certain limit.

[0122] [Flowchart] Figure 18 is a flowchart showing the interrupt identification process of the interrupt identification unit 140, which has a large power impact. In step S31, the interrupt identification unit 140 obtains event / hibernation state integration information (Figure 9) from the event / hibernation state integration unit 130.

[0123] In step S32, the interrupt identification unit 140 increments the CPU counter C by +1 (C++) (C=CPU#1, C≦CPU#MAX, C++) in order to repeatedly execute the processes of steps S33 to S39 for each CPU core from CPU core #1 to CPU core #1MAX.

[0124] In step S33, the interrupt identification unit 140 increments the time counter T by +1 (T++) (T=t1, T≦tmax, T++) in order to repeatedly execute the processes in steps S33 to S37 from time t1 to time tmax for time T. In step S34, the interrupt identification unit 140 determines whether or not an interrupt type is set in the interrupt type I.

[0125] If the interrupt type I contains an interrupt type (S34: Yes), in step S35 the interrupt identification unit 140 obtains the post-transition pause state Sb at T(n-1) and increments the pre-interrupt pause state counter corresponding to (I, Sb) by +1.

[0126] In step S36, the interrupt identification unit 140 calculates the duration Δ of the corresponding pause state by going back to the time when the system transitioned to the same pause state as the pause state after transition T(n-1), and increases the duration of the pause state before the interrupt corresponding to (I, Sb) by +Δ.

[0127] In step S37, the interrupt identification unit 140 looks ahead to the time when the next pause state other than C0 was reached, increments the post-interrupt pause state counter corresponding to the post-interrupt pause state Sa by +1, and returns to step S33. In other words, the interrupt identification unit 140 increments the post-interrupt pause state counter corresponding to the post-interrupt pause state Sa by looking ahead to the time when the next pause state other than C0 was reached.

[0128] Furthermore, if no interrupt type is entered in interrupt type I in step S34 (S34: No), steps S35 to S37 are skipped and the process returns to step S33. In step S33, when processing for time T is completed, the time counter T is incremented by +1 (T++) (T=t1, T≦tmax, T++).

[0129] In step S38, the interrupt identification unit 140 divides the duration of the pre-interrupt pause state corresponding to (I, Sb) by the pre-interrupt pause state counter and calculates the average value. In step S39, the interrupt identification unit 140 performs the [interrupt identification process].

[0130] Once processing is complete for all of the above CPU cores, this program terminates. The [interrupt identification process] in step S39 is executed by calling a subroutine in one of the following: "Subroutine for interrupt identification logic 1 with a large power impact" (Figure 19) and its explanatory diagram (Figures 20, 21), "Subroutine for interrupt identification logic 2 with a large power impact" (Figure 22) and its explanatory diagram (Figures 23, 24), or "Subroutine for interrupt identification logic 3 with a large power impact" (Figure 25) and its explanatory diagram (Figures 26, 27). These will be explained in order below.

[0131] <Power-Impacting Interrupt Identification Logic 1> Power-impacting interrupt identification logics 1 to 3 identify interrupts that frequently wake up deep sleep states (C6) as power-impacting interrupts. Power-impacting interrupt identification logic 1 enables efficient operation by pre-determining which interrupt types are allowed and excluding them from interrupt identification.

[0132] Figure 19 is a flowchart showing the processing of interrupt identification logic 1, which has a large power impact, and is the subroutine for [interrupt identification processing] in step S39 of Figure 18. Figure 20 is a table showing the pre-interrupt pause state counter used in the flow of Figure 19. Figure 21 is a diagram explaining the processing of the flow of Figure 19.

[0133] In step S101 of Figure 19, the interrupt identification unit 140 sets the post-transition pause state Sb to the target pause state (C6) (Sb = target pause state (C6)).

[0134] In step S102, the interrupt identification unit 140 increments the interrupt type count I by +1 (I++) (I=IRQ#1, I≦IRQ#MAX, I++).

[0135] In step S103, the interrupt identification unit 140 determines whether interrupt type I is subject to exclusion from interrupt identification for CPU core C. Depending on the CPU core, it may be possible to enable efficient operation by raising interrupts to the same core. Therefore, for each CPU core, the interrupt types that are allowed to interrupt are determined and excluded from interrupt identification.

[0136] If interrupt type I is not subject to interrupt exclusion by CPU core C (S103: No), in step S104 the interrupt identification unit 140 determines whether the pre-interrupt hibernation state counter (C, I, Sb) (Figure 20) is above a predetermined threshold ((C, I, Sb) ≥ threshold). The pre-interrupt hibernation state counter (C, I, Sb) shown in Figure 20 records the number of times the post-transition hibernation state S is in the active state (C0), hibernation state (C1), and hibernation state (C6) for each interrupt type IRQ.

[0137] Note that the pre-interrupt pause state counter (C, I, Sb) in Figure 20 is a count value indicating the number of times the post-transition pause state S occurs for each interrupt type IRQ, and the pre-interrupt pause state duration (C, I, Sb) in Figure 23 below is the duration of the post-transition pause state Sb for each interrupt type IRQ. (C, I, Sb) are the same, but they are distinguished by the number of occurrences ("counter count value" will be referred to as "counter" below) and the duration.

[0138] If the pre-interrupt pause state counter (C, I, Sb) is above a predetermined threshold, in step S105 the interrupt identification unit 140 flags interrupt type I as an interrupt with performance impact and returns to step S102.

[0139] If, in step S103, interrupt type I is an interrupt exclusion target for CPU core C (S103: Yes), or if, in step S104, the pre-interrupt pause state counter (C, I, Sb) is smaller than a predetermined threshold (S104: No), the interrupt identification unit 140 does nothing and returns to step S103. Once processing for all interrupts is complete, the processing of this program ends.

[0140] Figure 21 illustrates the operation of "Power-Impacted Interrupt Identification Logic 1". Depending on the CPU core, efficient operation may be possible by raising interrupts to the same core. Therefore, the interrupt types that are allowed to interrupt are determined for each CPU core and excluded from interrupt identification. As shown in Figure 21, when in a deep hibernation state (C6), the HW interrupt (shaded b1 in Figure 21) that has caused the hibernation state (C6) to be awakened the most times by a HW interrupt (a1 in Figure 21) is identified. Here, as shown in the table of pre-interrupt hibernation state counters (C, I, Sb) in Figure 20, the interrupt with interrupt type I that causes the deep hibernation state (C6) (Sb = target hibernation state (C6)) the most is the interrupt with interrupt type I, IRQ3. For this reason, the HW interrupt IRQ3 that has caused the hibernation state (C6) to be awakened the most times is excluded from the list of interrupt types that are allowed to interrupt and is excluded from interrupt identification.

[0141] <Interrupt Identification Logic 2 for High Power Consumption> When an interrupt occurs during a short deep hibernation state (C6), not only is the benefit of transitioning to the hibernation state (C6) not negated, but the system wakes up from hibernation, and then enters hibernation again after the interrupt processing is complete. This delay time is unusable and generates wasted power. Interrupt Identification Logic 2 for High Power Consumption enables efficient operation by identifying interrupts that wake the system up immediately after entering the deep hibernation state (C6) as interrupts with high power consumption.

[0142] Figure 22 is a flowchart showing the processing of interrupt identification logic 2, which has a large power impact, and is the subroutine for [interrupt identification processing] in step S39 of Figure 18. Figure 23 is a table showing the duration of the pre-interrupt pause state used in the flow of Figure 22. Figure 24 is a diagram explaining the processing of the flow of Figure 22.

[0143] In step S101 of Figure 22, the interrupt identification unit 140 sets the post-transition pause state Sb to the target pause state (C6) (Sb = target pause state (C6)). In step S102, the interrupt identification unit 140 increments the interrupt type count I by +1 (I++) (I=IRQ#1, I≦IRQ#MAX, I++) in order to repeatedly execute the processes of steps S103 to S105 for interrupt type I from IRQ#1 to IRQ#MAX.

[0144] In step S103, the interrupt identification unit 140 determines whether interrupt type I is subject to exclusion for CPU core C's interrupt identification. If interrupt type I is not subject to exclusion for CPU core C's interrupt identification (S103: No), the process proceeds to step S107.

[0145] In step S107, the interrupt identification unit 140 determines whether the pre-interrupt dormancy state duration (C, I, Sb) (Figure 23) is less than a predetermined threshold (i.e., (C, I, Sb) < threshold). The pre-interrupt dormancy state duration (C, I, Sb) shown in Figure 23 records the duration for each interrupt type IRQ when the post-transition dormancy state Sb is in the active state (C0), dormant state (C1), and dormant state (C6).

[0146] If the duration of the pre-interrupt pause state (C, I, Sb) is less than a predetermined threshold (S107: Yes), in step S105 the interrupt identification unit 140 flags interrupt type I as an interrupt with performance impact and returns to step S102.

[0147] If, in step S103, interrupt type I is an interrupt exclusion target for CPU core C (S103: Yes), or if, in step S107, the pre-interrupt pause state duration (C, I, Sb) is greater than or equal to a predetermined threshold (S107: No), the interrupt identification unit 140 does nothing and returns to step S103. Once processing for all interrupts is complete, the processing of this program is terminated.

[0148] Figure 24 is a diagram illustrating the operation of "Interrupt Identification Logic 2 with a Large Power Impact". As shown in Figure 24, if a hardware interrupt (code c1 in Figure 24) occurs during the duration of a deep hibernation state (C6), the system wakes up from the hibernation state (C6) and enters the active state (C0) (shaded d1 in Figure 24). When the duration of the deep hibernation state (C6) (bidirectional arrow e1 in Figure 24) is short (when the pre-interrupt hibernation state duration (C, I, Sb) in step S107 of Figure 22 is smaller than a predetermined threshold), the impact of the wake-up delay from the hibernation state (C6) to the active state (C0) is greater than when the duration of the deep hibernation state (C6) is long. In other words, if an interrupt occurs during a short deep hibernation state (C6), not only is there no benefit from transitioning to the hibernation state (C6), but a delay time is created for waking up from the hibernation state and then hibernating again after the interrupt processing is completed. No processing can be done during this delay time, resulting in wasted power. Therefore, if the duration of the deep hibernation state (C6) is short, in other words, if the interrupt is triggered immediately after entering the deep hibernation state (C6), interrupt type I will be flagged as an interrupt with performance impact.

[0149] <Power-Identifying Interrupt Logic 3> Power-Identifying Interrupt Logic 3 enables efficient operation by identifying interrupts that are less likely to cause a deep sleep state after the interrupt as power-impacting interrupts.

[0150] Figure 25 is a flowchart showing the processing of the interrupt identification logic 3, which has a large power impact, and is the subroutine for [interrupt identification processing] in step S39 of Figure 18. Figure 26 is a table showing the post-interrupt hibernation state counter used in the flow of Figure 25. Figure 27 is a diagram explaining the processing of the flow of Figure 25.

[0151] In step S101 of Figure 25, the interrupt identification unit 140 sets the post-transition pause state Sb to the target pause state (C6) (Sb = target pause state (C6)). In step S102, the interrupt identification unit 140 increments the interrupt type count I by +1 (I++) (I=IRQ#1, I≦IRQ#MAX, I++) in order to repeatedly execute the processes of steps S103 to S105 for interrupt type I from IRQ#1 to IRQ#MAX.

[0152] In step S103, the interrupt identification unit 140 determines whether interrupt type I is subject to exclusion for CPU core C's interrupt identification. If interrupt type I is not subject to exclusion for CPU core C's interrupt identification (S103: No), the process proceeds to step S108.

[0153] In step S108, the interrupt identification unit 140 determines whether the value obtained by dividing the post-interrupt pause state counter (C, I, Sa) by the pre-interrupt pause state counter (C, I, Sb) is less than a predetermined threshold (i.e., post-interrupt pause state counter (C, I, Sa) / pre-interrupt pause state counter (C, I, Sb) < threshold).

[0154] The interrupt-post-hibernation state counter (C, I, Sa) shown in Figure 26 records whether the post-transition hibernation state S was a hibernation state (C1) or a deep hibernation state (C6) for each interrupt type IRQ. In Figure 26, the counter counts whether the post-transition hibernation state S was a hibernation state (C1) or a deep hibernation state (C6), but it is also possible to record and use other hibernation states.

[0155] If the value obtained by dividing the post-interrupt pause state counter (C, I, Sa) by the pre-interrupt pause state counter (C, I, Sb) is smaller than a predetermined threshold (S107: Yes), in step S105 the interrupt identification unit 140 flags interrupt type I as an interrupt with performance impact and returns to step S102.

[0156] If, in step S103, interrupt type I is excluded from interrupt identification for CPU core C (S103: Yes), or if, in step S108, the value obtained by dividing the post-interrupt hibernation counter (C, I, Sa) by the pre-interrupt hibernation counter (C, I, Sb) is greater than or equal to a predetermined threshold (S108: No), the interrupt identification unit 140 does nothing and returns to step S103. Once processing for all interrupts is complete, the processing of this program ends.

[0157] Figure 27 illustrates the operation of "Power-Impacting Interrupt Identification Logic 3". As shown in Figure 27, if a hardware interrupt (symbol f1 in Figure 27) occurs during the duration of a deep hibernation state (C6), the system wakes up from hibernation (C6) and enters the active state (C0) (shaded g1 in Figure 27). If the value obtained by dividing the post-interrupt hibernation counter (C, I, Sa) by the pre-interrupt hibernation counter (C, I, Sb) is smaller than a predetermined threshold, the system is identified as an interrupt that is unlikely to enter a deep hibernation state (C6) after the hardware interrupt, and is therefore identified as a power-impacting interrupt. In Figure 27, the transition from the active state (C0) remains in the hibernation state (C1) (it does not transition to the hibernation state (C6)) (symbol h1 in Figure 27). By identifying interrupts that are unlikely to enter a deep hibernation state as interrupts that have little power-saving effect, efficient operation such as reducing the task allocation to the CPU core for interrupts that are unlikely to enter a deep hibernation state becomes possible.

[0158] (Fourth Embodiment) In the fourth embodiment, the number of times an interrupt was triggered on a CPU core in a non-hibernating state is calculated from the information obtained in the second embodiment, and the interrupt types that have a significant impact on performance are identified.

[0159] The schematic configuration of the event identification device 100 according to the fourth embodiment of the present invention is the same as that shown in Figure 16. The interrupt identification unit 140 of the event identification device 100 according to the fourth embodiment calculates the number of times the event / hibernation state integration unit 130 has interrupted a CPU core in a non-hibernation state, and identifies interrupt types whose interrupt performance impact is greater than or equal to a predetermined level. Specifically, the interrupt identification unit 140 calculates the interrupt impact on the application based on the CPU usage rate of the CPU cores, and excludes CPU cores with an interrupt impact greater than or equal to a predetermined level from the interrupt destinations, or adds CPU cores with an interrupt impact less than or equal to a predetermined level to the interrupt destinations.

[0160] In Figure 16, the interrupt identification unit 140 of the event identification device 100 according to the fourth embodiment identifies, for each CPU core, the interrupt type that generates many interrupts in the non-hibernating state and is affecting the performance of the application ("performance-impacting interrupt type information"). The interrupt destination change unit 150 obtains the CPU usage status from the OS. The interrupt destination change unit 150 also obtains the interrupt tolerance from the operator. The interrupt destination change unit 150 combines this information to determine the interrupt impact of the CPU core. The interrupt destination change unit 150 changes the interrupt destination from a CPU core with a high interrupt impact to a CPU core with a low interrupt impact.

[0161] The operation of the event identification device 100 configured as described above will be explained below. [Performance-impacting interrupt type identification operation] The interrupt identification unit 140 shown in Figure 16 calculates the number of times the CPU core was woken from hibernation for each interrupt type from the information obtained in the second embodiment that associates the interrupt type and hibernation state change on the CPU core, and identifies the interrupt types with a large power impact. The power impact of an interrupt can be evaluated, for example, using the number of interrupts for a deep hibernation state, the duration of the previous hibernation state, and the subsequent hibernation state transition rate.

[0162] Figure 28 is a table showing the CPU core #1 pre-interrupt hibernation counter. Figure 28 shows the number of interrupts for each hardware interrupt type for the CPU core, and the number of interrupts for each hibernation state (C-state). Figure 28 shows that the CPU core #1 pre-interrupt hibernation counter is created based on "3. CPU core #1 event / hibernation state integrated information" shown in Figure 9.

[0163] As shown by the white arrow h1 in Figure 28, the HW interrupt type IRQ2 indicates that the number of times an interrupt has been triggered on a CPU core in a non-hibernating state is "10". Since the number of times an interrupt has been triggered on a CPU core in a non-hibernating state is high for HW interrupt type IRQ2, transitioning to a hibernation state would have a significant impact on performance (keeping the CPU core running in a non-hibernating state helps maintain performance). By identifying the HW interrupt type, the interrupt identification unit 140 can take measures to reduce power consumption, such as distributing tasks to other CPU cores for interrupt types that have a large power impact.

[0164] Examples of specific algorithms for hardware interrupt types are as follows: • The number of interrupts for non-hibernation states exceeds a certain limit. • The total interrupt processing time exceeds a certain limit.

[0165] [Flowchart] <Interrupt Identification Logic 1 with a High Performance Impact> Interrupt identification logics 1 and 2 with a high performance impact calculate the number of times interrupts are triggered on CPU cores in a non-hibernating state and identify the types of interrupts with a high performance impact. Interrupt identification logic 1 with a high performance impact identifies interrupts that occur frequently during the non-hibernating state (C0) as interrupts with a high performance impact.

[0166] Figure 29 is a flowchart showing the processing of interrupt identification logic 1, which has a significant impact on performance, and is the subroutine for [interrupt identification processing] in step S39 of Figure 18. Figure 30 is a diagram illustrating the processing of the flow in Figure 29.

[0167] In step S101 of Figure 29, the interrupt identification unit 140 sets the post-transition pause state Sb to the target pause state (C6) (Sb = target pause state (C6)). In step S102, the interrupt identification unit 140 increments the interrupt type count I by +1 (I++) (I=IRQ#1, I≦IRQ#MAX, I++) in order to repeatedly execute the processes of steps S103 to S105 for interrupt type I from IRQ#1 to IRQ#MAX.

[0168] In step S103, the interrupt identification unit 140 determines whether interrupt type I is subject to exclusion for CPU core C's interrupt identification. If interrupt type I is not subject to exclusion for CPU core C's interrupt identification (S103: No), in step S109, the interrupt identification unit 140 determines whether the pre-interrupt pause state counter (C, I, Sb) (Figure 20) is above a predetermined threshold ((C, I, Sb) ≥ threshold).

[0169] The pre-interrupt hibernation counter (C, I, Sb) shown in Figure 20 records the number of times the post-transition hibernation state S is in the active state (C0), hibernation state (C1), and hibernation state (C6) for each interrupt type IRQ.

[0170] If the pre-interrupt pause state counter (C, I, Sb) is greater than or equal to a predetermined threshold (S109: Yes), in step S105 the interrupt identification unit 140 flags interrupt type I as an interrupt with performance impact and returns to step S102.

[0171] If, in step S103, interrupt type I is an interrupt exclusion target for CPU core C (S103: Yes), or if, in step S109, the pre-interrupt pause state counter (C, I, Sb) is smaller than a predetermined threshold (S109: No), the interrupt identification unit 140 does nothing and returns to step S103. Once processing for all interrupts is complete, the processing of this program ends.

[0172] Figure 30 illustrates the operation of "Interrupt Identification Logic 1 for High Performance Impact". As shown in Figure 30, for hardware interrupts (symbol i1 in Figure 30) to a CPU core in a non-hibernation state (start-up state (C0)), if the number of interrupts in the start-up state (C0) is high (above a certain level) (symbol j1 in Figure 30; shaded in Figure 30), it is identified as an interrupt with a high performance impact. Depending on the CPU core, efficient operation may be possible by raising interrupts to the same CPU core. Interrupt Identification Logic 1 for High Performance Impact determines which interrupt types are allowed for each CPU core and excludes them from interrupt identification.

[0173] Figure 31 is a table showing power-impact interrupt type information, recording the magnitude of power impact and performance impact for each interrupt type. As shown in Figure 31, HW interrupt type IRQ1 has a power impact of "0 (low power impact)" and a performance impact of "1 (high performance impact)". HW interrupt type IRQ2 has a power impact of "0 (low power impact)" and a performance impact of "0 (low performance impact)". HW interrupt type IRQ3 has a power impact of "1 (high power impact)" and a performance impact of "0 (low performance impact)".

[0174] The interrupt identification unit 140 (Figure 16) can identify whether an interrupt is a power-impact interrupt or an interrupt with a large performance impact, based on the power-impact interrupt type information in Figure 31. For example, in the case of HW interrupt type IRQ2, the interrupt identification unit 140 identifies that both the power impact "0 (low power impact)" and the performance impact "0 (low performance impact)" are low. The interrupt destination change unit 150 (Figure 16) does not perform any control corresponding to the power impact and performance impact for HW interrupt type IRQ2.

[0175] On the other hand, in the case of hardware interrupt type IRQ3, the power impact is "1 (high power impact)" and the performance impact is "0 (low performance impact)". Therefore, the interrupt target change unit 150 determines that there is a power impact and changes the interrupt target from a CPU core with a high interrupt impact to a CPU core with a low interrupt impact, as described in the third embodiment. Also, in the case of hardware interrupt type IRQ1, the power impact is "0 (low power impact)" and the performance impact is "1 (high performance impact)". Therefore, the interrupt target change unit 150 determines that there is a performance impact and changes the interrupt target from a CPU core with a high interrupt impact to a CPU core with a low interrupt impact.

[0176] <Interrupt Identification Logic 2 for High Performance Impact> Interrupt identification logic 2 for high performance impact identifies interrupts with long total interrupt processing times as interrupts with high performance impact.

[0177] Figure 32 is a flowchart showing the processing of the interrupt identification logic 2, which has a significant impact on performance, and is the subroutine for the [interrupt identification processing] in step S39 of Figure 18. In step S101 of Figure 32, the interrupt identification unit 140 sets the post-transition pause state Sb to the target pause state (C6) (Sb = target pause state (C6)).

[0178] In step S102, the interrupt identification unit 140 increments the interrupt type count I by +1 (I++) (I=IRQ#1, I≦IRQ#MAX, I++).

[0179] In step S103, the interrupt identification unit 140 determines whether interrupt type I is subject to exclusion for interrupt identification by CPU core C.

[0180] If interrupt type I is not subject to interrupt exclusion by CPU core C (S103: No), in step S110 the interrupt identification unit 140 determines whether the result of multiplying the pre-interrupt pause state counter (C, I, Sb) by the average interrupt processing time is greater than or equal to a predetermined threshold (pre-interrupt pause state counter (C, I, Sb) × average interrupt processing time ≥ threshold).

[0181] The average interrupt processing time is obtained as follows: • The interrupt processing time is obtained as one of the interrupt information items and calculated by dividing it by the total number of interrupts. • Past measured values ​​of interrupt processing time are referenced.

[0182] If the result of multiplying the pre-interrupt pause state counter (C, I, Sb) by the average interrupt processing time is greater than or equal to a predetermined threshold, the interrupt identification unit 140 flags interrupt type I as an interrupt with performance impact and returns to step S102.

[0183] If, in step S103, interrupt type I is excluded from interrupt identification for CPU core C (S103: Yes), or if, in step S110, the interrupt identification unit 140 finds that the result of multiplying the pre-interrupt pause state counter (C, I, Sb) by the average interrupt processing time is less than a predetermined threshold (S110: No), the interrupt identification unit 140 does nothing and returns to step S103. Once processing for all interrupts is complete, the program terminates.

[0184] (Fifth Embodiment) In the first to fourth embodiments, information on the type and time of occurrence of an event that may cause the CPU core to wake up, and information on the hibernation state and transition time at the time the CPU core transitioned to a hibernation state are recorded, and the type of event that woke up the CPU core is identified from the events that occurred at the same time as the time the CPU core woke up.

[0185] The schematic configuration of the event identification device 100 according to the fifth embodiment of the present invention is the same as in Figure 1. The interrupt destination change unit 150 calculates the degree of performance impact of interrupts on applications (interrupt impact) for each CPU core using the CPU usage rate. The CPU usage rate is determined by the interrupt destination change unit 150 periodically referring to the CPU usage rate information held by the OS (OS / driver 60).

[0186] The event identification device 100 according to the fifth embodiment calculates the degree of impact of interrupts on application performance (interrupt impact) for each CPU core using the CPU usage rate. CPU cores with a high interrupt impact are excluded from the interrupt destination, or CPU cores with a low interrupt impact are added to the interrupt destination.

[0187] Specifically, the interrupt target change unit 150 obtains CPU usage information from the OS / driver 60. The interrupt target change unit 150 also obtains interrupt tolerance from the operator. The interrupt target change unit 150 combines the CPU usage information obtained from the OS / driver 60 and the interrupt tolerance obtained from the operator to determine the interrupt impact of each CPU core. Then, the interrupt target change unit 150 changes the interrupt target from a CPU core with high interrupt impact to a CPU core with low interrupt impact.

[0188] For example, the interrupt target modification unit 150 determines the interrupt target so that more interrupts are sent to CPU cores with a low CPU usage ratio. For example, the interrupt target modification unit 150 sorts the interrupt types in descending order of the number of interrupts, assigns the interrupt type with the most interrupts to the core with the lowest CPU usage, and then assigns the interrupt type with the next most interrupts to the core with the next lowest CPU usage, and so on. The interrupt target modification unit 150 also removes CPU cores with a high interrupt impact from the interrupt targets. Alternatively, the interrupt target modification unit 150 adds CPU cores with a low interrupt impact to the interrupt targets. The interrupt impact can be evaluated using, for example, CPU usage, interrupt tolerance obtained from the operator, or performance values ​​obtained from the application 70 (Figures 1 and 16).

[0189] Figure 33 shows task processing on a high-utilization CPU core. Higher CPU utilization increases the likelihood of hardware interrupts (indicated as l1 in Figure 33) occurring during task processing (indicated as k1 in Figure 33), thus having a greater impact on the performance of application 70. Furthermore, even with the same CPU utilization, some applications 70 have strict latency requirements and cannot tolerate even small interrupts, resulting in a lower interrupt tolerance for the CPU core to which the application is assigned.

[0190] Figure 34 shows the impact of interrupts on task processing in CPU cores. Figure 34 records the interrupt impact, CPU usage, and interrupt tolerance for each CPU core. For example, CPU core #1 has a high interrupt impact because its interrupt tolerance is low. CPU core #2 has a high interrupt impact because its CPU usage is high.

[0191] In the fifth embodiment, the degree to which interrupts affect application performance (interrupt impact) is calculated for each CPU core using CPU usage. CPU cores with a high interrupt impact are excluded from the interrupt destinations. Alternatively, CPU cores with a low interrupt impact are added to the interrupt destinations.

[0192] Figure 35 is an explanatory diagram illustrating how, when the interrupt impact shown in Figure 34 is calculated, CPU core #1 (which has a low interrupt tolerance and high interrupt impact) and CPU core #2 (which has high CPU usage and high interrupt impact) are excluded from the interrupt destination and added to CPU core #3 (which has a low interrupt impact). As shown in Figure 35, the interrupt destination for IRQ#3 is changed from CPU cores #1 and #2 (indicated as m1 in Figure 33), which have a high interrupt impact, to CPU core #3 (indicated as n1 in Figure 33), which has a low interrupt impact.

[0193] Figure 36 shows the interrupt destination CPU mask when the interrupt destination change unit 150 performs the CPU core change shown in Figure 35. As shown by the thick border o1 in Figure 36, the interrupt destination for IRQ#3 is changed to CPU core #3 by masking CPU cores #1 and #2.

[0194] Changing the interrupt target can be achieved by changing the CPU mask of the interrupt target managed by the OS. The CPU mask can be changed as follows: # cat / proc / irq / 60 / smp_affinity 0001 # The original CPU mask for IRQ60 is 1 (core 0) # echo 3 > / proc / irq / 60 / smp_affinity # Change the CPU mask to 3 # cat / proc / irq / 60 / smp_affinity 0003 # The CPU mask for IRQ60 is 3 (core 0, 1)

[0195] [Flowchart] Figure 37 is a flowchart showing the interrupt destination change process of the interrupt destination change unit 150. In step S201, the interrupt destination change unit 150 obtains the CPU usage status for each CPU core from the OS / driver 60.

[0196] In step S202, the interrupt destination change unit 150 obtains the interrupt tolerance for each CPU core from the operator. In step S203, the interrupt destination change unit 150 increments the CPU counter C by +1 (C++) (C=CPU#1, C≦CPU#MAX, C++) in order to repeatedly execute the processes in steps S204 to S212 for each CPU core, from CPU core #1 to CPU core #1MAX.

[0197] In step S204, the interrupt destination change unit 150 determines whether the CPU usage is greater than or equal to the mask removal threshold (CPU usage ≥ mask removal threshold). If the CPU usage is greater than or equal to the mask removal threshold (S204: Yes), in step S205, the interrupt destination change unit 150 determines whether the interrupt tolerance is less than the mask removal threshold (interrupt tolerance < mask removal threshold).

[0198] If the interrupt tolerance is less than the mask removal threshold (S205: Yes), in step S206, the interrupt destination change unit 150 selects the interrupt to be masked. The interrupt to be masked can be determined by, for example, the following methods: - Specify the interrupt with the smallest performance impact using the method described in the fourth embodiment. - Specify the interrupt that causes the fewest interrupts to CPU core C.

[0199] In step S207, the interrupt destination change unit 150 removes the interrupt destination CPU mask (I, C1) (interrupt destination CPU mask (I, C1) = 0 (mask removed)) and returns to step S204.

[0200] On the other hand, if the CPU usage rate in step S204 is less than the mask removal threshold (S204: No), in step S208 the interrupt destination change unit 150 determines whether the CPU usage rate is less than the mask addition threshold (CPU usage rate < mask addition threshold).

[0201] If the CPU usage is less than the mask addition threshold (S208: Yes), in step S209 the interrupt destination change unit 150 determines whether the interrupt tolerance is greater than or equal to the mask addition threshold (interrupt tolerance ≥ mask addition threshold).

[0202] If, in step S205, the interrupt tolerance is greater than or equal to the mask removal threshold (S205: No), if, in step S208, the CPU usage is greater than or equal to the mask addition threshold (S208: No), or if, in step S209, the interrupt tolerance is less than the mask addition threshold (S209: No), the process returns to step S204.

[0203] If, in step S209 above, the interrupt tolerance is greater than or equal to the mask addition threshold (S209: Yes), then in step S210, the interrupt destination change unit 150 selects the interrupt to be masked. The interrupt to be masked can be determined, for example, by the following methods: - Specify the interrupt with a large performance impact using the method described in the fourth embodiment. - Specify the interrupt that causes the most interrupts to CPU core C.

[0204] In step S211, the interrupt target change unit 150 performs interrupt target CPU mask (I, C1)=1 (add mask) and returns to step S204. Once processing for all interrupts is complete, the program terminates.

[0205] Figure 38 is a flowchart showing the process of selecting interrupts to be removed from the mask, and is the subroutine for the [Selection of Interrupts to Remove from Masks] in step S206 or step S210 of Figure 37.

[0206] The process starts with a subroutine call in step S206 or step S210 of Figure 37, and in step S301, the interrupt target change unit 150 obtains the CPU usage status for each CPU core from the OS / driver 60.

[0207] In step S302, the interrupt target change unit 150 obtains the number of interrupts for each interrupt type from the OS / driver 60.

[0208] In step S302, the interrupt destination change unit 150 determines the interrupt destination so that more interrupts are sent to the CPU core with the lowest CPU usage ratio, and returns to step S206 or step S210 in Figure 37. A specific example of the interrupt destination determination described above is as follows: The interrupt destination change unit 150 sorts the interrupt types in descending order of the number of interrupts, assigns the interrupt type with the most interrupts to the core with the lowest CPU usage ratio, assigns the next most interrupts to the core with the next lowest CPU usage ratio, and so on.

[0209] Figure 39 illustrates the operation of selecting interrupts to be removed from the mask. Similar to Figure 35, Figure 39 is an explanatory diagram that, when the interrupt impact shown in Figure 34 is calculated, CPU cores with low interrupt tolerance are excluded from the interrupt destinations, and CPU cores with low interrupt impact are added, and the interrupt destinations are changed according to the number of interrupts and CPU usage. As shown by the symbol p1 in Figure 39, the interrupt destination of IRQ#1, which has a high number of interrupts (100 times per second), is added (changed) to CPU core #3, which has a low CPU usage ratio (CPU usage 20%). As shown by the symbol q1 in Figure 39, the interrupt destination of IRQ#2, which has a moderate number of interrupts (40 times per second), remains unchanged at CPU core #2, which has a moderate CPU usage ratio (CPU usage 60%). As shown by the symbol r1 in Figure 39, the interrupt destination of IRQ#3, which has a low number of interrupts (20 times per second), is changed to CPU core #1, which has a high CPU usage ratio (CPU usage 80%).

[0210] [Hardware Configuration] The event identification device 100 (Figures 1 and 16) according to each of the above embodiments is configured with a server such as the task processing system 1000 shown in Figures 1 and 16. When the event identification device 100 is configured with a server, the server is realized by a computer 900 configured as shown in Figure 40, for example. Figure 40 is a hardware configuration diagram showing an example of a computer 900 that realizes the functions of the event identification device 100 (Figures 1 and 16). The computer 900 has a CPU 901, ROM 902, RAM 903, HDD 904, communication interface (I / F: Interface) 906, input / output interface (I / F) 905, and media interface (I / F) 907.

[0211] The CPU 901 operates based on programs stored in the ROM 902 or HDD 904 and controls each part of the event identification device 100 (Figures 1 and 16). The ROM 902 stores boot programs executed by the CPU 901 when the computer 900 starts up, as well as programs that depend on the computer 900's hardware.

[0212] The CPU 901 controls input devices 910 such as a mouse or keyboard, and output devices 911 such as a display (display unit) (the "output unit" as described in the claim) via the input / output interface 905. The CPU 901 acquires data from the input devices 910 via the input / output interface 905 and outputs the generated data to the output devices 911. In addition to the CPU 901, a GPU (Graphics Processing Unit) or the like may be used as a processor.

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

[0214] The media interface 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 the program related to the desired processing from the recording medium 912 onto the RAM 903 via the media interface 907 and executes the loaded program. The recording medium 912 is an optical recording medium such as a DVD (Digital Versatile Disc) or PD (Phase change rewritable Disk), a magneto-optical recording medium such as an MO (Magneto Optical disk), a magnetic recording medium, a conductive memory tape medium, or a semiconductor memory.

[0215] For example, when computer 900 functions as an event identification device 100 (Figures 1 and 16) configured as one of the devices according to this embodiment, the CPU 901 of computer 900 realizes the functions of event identification devices 100 and 100A by executing a program loaded on RAM 903. The HDD 904 stores the data in RAM 903. CPU 901 reads and executes a program related to the desired processing from the recording medium 912. Alternatively, CPU 901 may read a program related to the desired processing from another device via a communication network (NW 922).

[0216] [Effect] As described above, the event identification device 100 (Figures 1 and 16) identifies events that wake up the CPU core, and comprises: an event acquisition unit 110 that acquires information on the type of event that can cause the CPU core to wake up and the time of its occurrence; a dormancy state acquisition unit 120 that acquires information on the time when the CPU core transitions to a dormant state; and an event / dormancy state integration unit 130 that identifies the type of event that woke up the CPU core based on the event that occurred at the time corresponding to the time the CPU core woke up, using the information on the type of event and its occurrence time acquired from the event acquisition unit 110 and the information on the dormant state at the time the dormancy state transition occurred and the time of the transition acquired from the dormancy state acquisition unit 120.

[0217] By doing so, the event identification device 100 can identify events that cause the CPU core to wake up and increase power consumption, as well as events that hinder task processing.

[0218] In the event identification device 100 (Figures 1 and 16), the event acquisition unit 110 acquires information on the interrupt type and occurrence time, and the event / hibernation state integration unit 130 combines the interrupts acquired from the event acquisition unit 110 and the hibernation states and their transition times acquired from the hibernation state acquisition unit 120 for a predetermined period to create event / hibernation state integration information that associates the interrupt type and hibernation state changes on the CPU core.

[0219] By doing so, the event identification device 100 limits the events that can cause the CPU core to wake up to interrupts and records information on the interrupt type and occurrence time. By combining interrupt events over a certain period with the occurrence times of CPU core hibernation state transitions, it is possible to create information that associates interrupt types and hibernation state changes on the CPU core.

[0220] In the event identification device 100 (Figures 1 and 16), the event / hibernation state integration unit 130 calculates the number of times the CPU core was woken from hibernation for each interrupt type based on the created event / hibernation state integration information, and identifies interrupt types whose power impact exceeds a predetermined level, or the interrupt identification unit 140 calculates the number of times an interrupt was applied to a CPU core in a non-hibernation state, and identifies interrupt types whose performance impact exceeds a predetermined level.

[0221] By doing so, the event identification device 100 can identify interrupt types that have a significant impact on power consumption, enabling measures to reduce power consumption and thus achieving power savings. Furthermore, the event identification device 100 can identify interrupts that hinder task processing, enabling measures to improve performance and thus achieving performance improvements.

[0222] In the event identification device 100 (Figures 1 and 16), the interrupt identification unit 140 is characterized by evaluating the power impact of the interrupt using one of the following: the number of interrupts relative to a deep sleep state, the duration of the preceding sleep state, or the ratio of subsequent sleep state transitions, and evaluating the performance impact of the interrupt using the number of interrupts relative to a non-sleep state, or the total interrupt processing time for each interrupt.

[0223] By doing so, the event identification device 100 can identify interrupt types that have a significant impact on performance.

[0224] The event identification device 100 (Figures 1 and 16) includes an interrupt destination modification unit 150 that calculates the interrupt impact of the interrupt-induced application 70 (Figures 1 and 16) based on the CPU usage rate of the CPU cores, and excludes CPU cores with an interrupt impact of a predetermined level or higher from the interrupt destinations, or adds CPU cores with an interrupt impact of a predetermined level or lower to the interrupt destinations.

[0225] By doing this, CPU cores with an interrupt impact of a certain level or higher are excluded from the interrupt destinations, and CPU cores with an interrupt impact of a certain level or lower are added to the interrupt destinations, thereby saving power while avoiding performance impacts.

[0226] In a task processing system 1000 (Figures 1 and 16) that distributes and processes tasks across multiple CPU cores and pauses the CPU cores when there are no tasks, an event identification device identifies events that cause an increase in power consumption by waking up the CPU cores, or events that hinder task processing. The event identification device comprises: an event acquisition unit 110 that acquires information on the type and time of occurrence of an event that can cause the CPU cores to wake up; a pause state acquisition unit 120 that acquires information on the pause state and the time of transition when the CPU cores transition to a pause state occurs; and an event / pause state integration unit 130 that identifies the type of event that woke up the CPU cores based on the event that occurred at the time corresponding to the time the CPU cores woke up, using the event type and time of occurrence information acquired from the event acquisition unit 110 and the pause state and transition time information acquired from the pause state acquisition unit 120.

[0227] In this way, the event identification device 100 can identify interrupts that cause increased power consumption by waking up CPU cores and interrupts that hinder task processing in a task processing system 1000 that distributes tasks across multiple CPU cores and pauses CPU cores when there are no tasks.

[0228] The task processing system 1000 (Figures 1 and 16) includes an output unit (output device 911) (Figure 40) that outputs event and hiatus integration information created by the event and hiatus integration unit 130.

[0229] In this way, if the output unit is a display unit, operators can visually confirm the integrated event and idle status information, and if the output unit is a communication function unit, the integrated event and idle status information can be effectively utilized as data.

[0230] Furthermore, among the processes described in the above embodiments, 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 by known methods. In addition, the processing procedures, control procedures, specific names, and information including various data and parameters shown in the above documents and drawings can be arbitrarily changed unless otherwise specified. Moreover, each component of each illustrated device is a functional concept and does not necessarily have to be physically configured as shown. In other words, the specific forms of distribution and integration of each device are not limited to those shown, and all or part of them can be functionally or physically distributed and integrated in any unit according to various loads and usage conditions.

[0231] Furthermore, each of the above configurations, functions, processing units, and processing means may be implemented in hardware, either partially or entirely, by designing them as integrated circuits, for example. Alternatively, each of the above configurations and functions may be implemented in software that allows the processor to interpret and execute programs that implement each function. Information such as programs, tables, and files that implement each function can be stored in memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC (Integrated Circuit) card, an SD (Secure Digital) card, or an optical disc.

[0232] 50 Hardware (HW) 51 Device (CPU core) 60 OS / Driver 70 Application (APL) 61 Interrupt handler 62 Scheduler 63 CPU idle driver 100 Event identification device 110 Event acquisition unit 120 Hibernation acquisition unit 130 Event / Hibernation integration unit (integration unit) 140 Interrupt identification unit 150 Interrupt destination change unit 1000 Task processing system 911 Output device ("Output unit" as described in the claim) CPUcore #0, CPUcore #1, ... CPU core

Claims

1. An event identification device for identifying an event that wakes up a CPU core, comprising: an event acquisition unit that acquires information on the type of event that can cause the CPU core to wake up and the time of its occurrence; a dormant state acquisition unit that acquires information on the dormant state at the time the CPU core transitions to a dormant state and the time of its occurrence; and an integration unit that identifies the type of event that woke up the CPU core based on the event that occurred at the time the CPU core woke up, using the event that occurred at the time the CPU core woke up, based on the event that occurred at the time the CPU core woke up, using the event that occurred at the time the CPU core woke up, based on the event that occurred at the time the CPU core woke up, using the event that occurred at the time the CPU core woke up.

2. The event identification device according to claim 1, characterized in that the event acquisition unit acquires information on the interrupt type and occurrence time, and the integration unit combines the interrupts acquired from the event acquisition unit and the sleep state and its transition time acquired from the sleep state acquisition unit during a predetermined period to create integrated event / sleep state information that associates the interrupt type and sleep state change on the CPU core.

3. The event identification device according to claim 2, further comprising an interrupt identification unit which, based on the integrated event and hibernation state information created by the integration unit, calculates the number of times the CPU core was woken from hibernation for each interrupt type and identifies interrupt types whose power impact exceeds a predetermined level, or calculates the number of times an interrupt was applied to a CPU core in a non-hibernation state and identifies interrupt types whose performance impact exceeds a predetermined level.

4. The event identification device according to claim 3, characterized in that the interrupt identification unit evaluates the power impact of the interrupt using one of the following: the number of interrupts relative to a deep sleep state, the duration of the preceding sleep state, or the ratio of subsequent sleep state transitions, and evaluates the performance impact of the interrupt using the number of interrupts relative to a non-sleep state, or the total interrupt processing time for each interrupt.

5. The event identification device according to claim 1, characterized in that it includes an interrupt destination modification unit that calculates the interrupt impact on an application due to an interrupt based on the CPU usage rate of the CPU cores, and excludes CPU cores whose interrupt impact is above a predetermined level from the interrupt destinations, or adds CPU cores whose interrupt impact is below a predetermined level to the interrupt destinations.

6. A task processing system that distributes and processes tasks across multiple CPU cores and pauses the CPU cores when there are no tasks, comprising an event identification device that identifies events that cause an increase in power consumption by waking up the CPU cores, or events that hinder task processing, wherein the event identification device comprises: an event acquisition unit that identifies events that cause the CPU cores to wake up; a pause state acquisition unit that acquires information about the time when the CPU cores transition to a pause state occurs; and an integration unit that identifies the type of event that woke up the CPU cores based on the event that occurred at the time the CPU cores woke up, using information about the type and time of occurrence of the event acquired from the event acquisition unit and information about the pause state at the time the pause state transition occurred and the time of that transition acquired from the pause state acquisition unit.

7. The task processing system according to claim 6, further comprising an output unit that outputs event and idle state integration information created by the integration unit.

8. A program for causing a computer to function as an event identification device according to any one of claims 1 to 5.

Images