Task scheduler device and program

Abstract

To provide a task scheduler device and a program performing a computation with low delay while realizing power saving.SOLUTION: Task scheduler devices 100, 100A are configured to allocate a task to a core group of a processor, in a computational system 1000 configured to reduce a power consumption through gradually decreasing an operational state of the processor according to a processing load. The task scheduler device includes: a task quantity / cycle prediction part 122 configured to acquire a service factor of a processor; and a task CPU allocation part 123 configured to allocate a task continuously to a core or a core group of a processor to be used at a frequency higher than a prescribed frequency, according to the service factor of the processor acquired at the task quantity / cycle prediction part 122.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a task scheduler device and a program. [Background technology]

[0002] This paper provides an overview of the wireless access system. FIG. 19 is a diagram for explaining an outline of a wireless access system. As shown in FIG. 19, the wireless access system includes a user terminal (UE: User Equipment), not shown, an antenna (base station antenna) 20, a base station (BBU: Base Band Unit) 30, and a core network .

[0003] The antenna 20 is an antenna and a transmitting / receiving unit that wirelessly communicates with the UE 10 (hereinafter, the term "antenna" collectively refers to the antenna, the transmitting / receiving unit, and its power supply unit). Transmitted and received data is connected to the base station 30 via, for example, a dedicated cable.

[0004] The base station 30 is a stationary radio station established on land that communicates with the UE 10. The base station (BBU: Broad Band Unit) 30 that performs radio signal processing is dedicated hardware (dedicated device) that performs radio signal processing. Alternatively, the base station 30 is a vRAN (virtual Radio Access Network) that performs radio signal processing in a signal processing aggregation system of LTE (Long Term Evolution) or 5G (five generation) using a general-purpose server. In a vRAN, a general-purpose server that is inexpensive and available in large quantities can be used as the hardware of the base station 30. The base station 30 includes hardware (HW) 31, a CPU (Central Processing Unit) 32 on the hardware, an OS etc. 33, L1, L2, and L3 protocol wireless signal processing applications 1-1, 1-2, and 1-3 (collectively referred to as APL1), and a task scheduler device 34.

[0005] The core network 40 is EPC (Evolved Packet Core) / (in the following description, " / " indicates "or") 5GC (5G Core Network) etc.

[0006] An example of a system that requires real-time performance is the base station unit (BBU) in the RAN. In a BBU that performs calculations using a CPU 32, calculations are often performed by a task scheduler device 34 allocating wireless signal processing tasks to a CPU core (Non-Patent Document 1).

[0007] Fig. 20 is a diagram for explaining an example of task management for wireless access processing in a base station. The same components as those in Fig. 19 are given the same reference numerals. The base station (BBU) 30 includes a task scheduler unit 34. The task scheduler unit 34 performs task management, prioritization, and task allocation. The task scheduler device 34 allocates the wireless signal processing task of APL1 to a task queue 37, and assigns it from the task queue 37 to the CPU cores (CPU core #0, CPU core #1, . . . ) 32.

[0008] [LPI (Low Power Idle) Hardware Control] The CPU 32 has a function for controlling the idle state of the CPU 32 through hardware control, which is called LPI. LPI is often called CPUidle or C-state, and hereinafter, LPI will be described as C-state. When the CPU load decreases, the C-state attempts to save power by turning off the power supply to a part of the circuitry of the CPU 32 (Non-Patent Document 2).

[0009] Fig. 21 is a table showing an example of the C-states. Note that since state definitions differ depending on the CPU hardware, Fig. 21 is merely a reference example. As shown in Fig. 21, there are grades C0 to C6 for the CPU idle state, and as the time when the CPU 32 is not loaded increases, it transitions to a deeper sleep state. A deeper sleep state consumes less CPU power, but on the other hand, it takes longer to return to normal, which can be an issue in terms of low latency.

[0010] C-states are defined differently depending on the CPU hardware. For example, there are models that do not have C4 or C5, and models where the next state after C1 is C1E. The deeper the state, the greater the power saving effect, but the longer it takes to return from the idle state.

[0011] In addition, the depth to which the CPUidle state transitions is controlled by the CPU hardware and is dependent on the CPU product (it is often not possible to control it from software such as the kernel).

[0012] Fig. 22 is a table showing an example of the maximum value of the time required to transition to a state (RESIDENCY) and the time required for recovery (WAKE-UP LATENCY). Fig. 22 shows C-state information for the Intel Xeon CPU E5-26X0 v4 (registered trademark).

[0013] [CPU idle state governor] Linux kernel 4 (registered trademark) provides two types of governors to manage the CPU idle state (C-state).

[0014] FIG. 23 is a diagram for explaining the CPU idle governor types. As shown in Figure 23, ladder is used for ticked systems and menu is used for tickless systems. For example, the menu used in tickless systems is a method that estimates the appropriate idle state depth for the next idle period based on the performance of the most recent idle period. The menu is effective for workloads with regular idle times, but its effectiveness is limited for irregular workloads.

[0015] FIG. 24 is a diagram for explaining an outline of the menu logic. As shown in the left diagram of Figure 24, menu records the most recent idle time. Then, as shown in the middle diagram of Figure 24, it estimates the next idle time. For example, based on the idle times shown in the left diagram of Figure 24, if the deviation is small, the average value T_avr is adopted as the next idle time. As shown in the right diagram of Figure 24, menu estimates an appropriate idle state depth based on the estimate of the next idle time. For example, if the next idle time estimate T_avr is equal to the exit latency, the recovery time from the idle state (Cx), it is determined that the state is too deep and a transition is made to the idle state Cx-1.

[0016] Returning to Figure 23, neither of the two types of governor ladder and menu governors has a mechanism to pre-wake up the CPU from idle state and return it to preparation when a new task arrives. Therefore, when a task is assigned while in a state transitioning to a deeper state, there is a problem that a delay for the return time occurs. [Prior art documents] [Non-patent literature]

[0017] [Non-Patent Document 1] New API (NAPI), [online], [Retrieved June 6, 2022], Internet <URL: https: / / www.kernel.org / doc / html / latest / admin-guide / pm / cpuidle.html> [Non-Patent Document 2] Daniel Molka & Michael Werner,Wake-up latencies for processor idle states on current x86 processors Robert Schone,[online],[Retrieved June 6, 2022],Internet 〈 URL :https: / / link.springer.com / article / 10.1007 / s00450-014-0270-z#citeas〉 Summary of the Invention [Problem to be solved by the invention]

[0018] As shown in Figure 21, there are different grades of CPU idle states, and as the time when the CPU is not loaded increases, it transitions to a deeper sleep state. A deeper sleep state consumes less CPU power, but on the other hand, it takes longer for the CPU to return to normal, which can be an issue in terms of low latency.

[0019] 25 and 26 are image diagrams of C-state transitions of a CPU core used for calculation. Fig. 25 shows a case where the task-free time is short, and Fig. 26 shows a case where the task-free time is long. As shown in Figure 25, when the time without tasks is short, the CPU core is in a shallow sleep state, and the delay before returning after a task is generated is short. However, as shown in Figure 26, when the time without tasks is long, the CPU core is in a deep sleep state (CPU idle state: grade C6), and the delay before returning after a task is generated is long. If the CPU falls into a deep CPU idle state, it takes a long time to return, which causes an issue of loss of real-time performance.

[0020] The above problem cannot be overlooked in a system in which real-time performance is given top priority, such as the base station (BBU) 30 shown in FIGS. For this reason, the base station (BBU) may take measures such as disabling the C-state or limiting the transition of the idle state to a limited depth such as C1. In other words, tuning may be performed to sacrifice power saving and to aim for real-time performance.

[0021] In conventional base stations (BBUs), if the base station falls into a deep C-state, the only thing to do is to wait until it recovers. For this reason, measures were taken to prevent the base station from falling into a deep C-state, sacrificing power saving.

[0022] The present invention has been made in view of the above background, and an object of the present invention is to perform calculations with low latency while achieving power saving. [Means for solving the problem]

[0023] In order to solve the above-mentioned problems, in a computing system which reduces power consumption by gradually reducing the operating state of a processor in accordance with a processing load, a task scheduler device which assigns tasks to a group of cores of the processor is provided, the task scheduler device comprising: a processor utilization rate acquisition unit which acquires a utilization rate of the processor; a task allocation unit which continuously assigns tasks to a core or group of cores of the processor which are used at a predetermined frequency or more based on the utilization rate of the processor acquired by the processor utilization rate acquisition unit; and an operating state setting unit which sets an upper limit for the core or group of cores of the processor which are used at a predetermined frequency or more so that the operating state of the processor cannot be transitioned to a deeper state. Effect of the Invention

[0024] According to the present invention, it is possible to perform calculations with low delay while achieving power saving. [Brief description of the drawings]

[0025] [Figure 1] 1 is a schematic configuration diagram of a computing system according to an embodiment of the present invention. [Diagram 2]1 is a configuration example in which a task scheduler device of a computing system according to an embodiment of the present invention is arranged in a user space. [Diagram 3] 1 is a configuration example in which a task scheduler device of a computing system according to an embodiment of the present invention is arranged in an OS. [Figure 4] 11 is a diagram illustrating, in the form of a table, a logic for estimating the required number of active CPU cores of the task scheduler device of the computing system according to the embodiment of the present invention. FIG. [Diagram 5] 5A and 5B are diagrams illustrating task amount threshold determination and CPU utilization rate threshold determination operations of a task scheduler device of a computing system according to an embodiment of the present invention. [Figure 6] FIG. 11 is a diagram illustrating an image of threshold determination according to a task inflow amount of a task scheduler device of a computing system according to an embodiment of the present invention. [Figure 7] 1 is a diagram illustrating an image of threshold determination according to a CPU utilization rate of a task scheduler device of a computing system according to an embodiment of the present invention. FIG. [Figure 8] FIG. 2 is a diagram illustrating a C-state upper limit setting of a task scheduler device of a computing system according to an embodiment of the present invention. [Figure 9] 1A and 1B are diagrams illustrating a case where a C-state upper limit is not set and a case where a C-state upper limit is set in a computing system according to an embodiment of the present invention. [Figure 10] 1 is a diagram illustrating pooling of highly available CPU cores in a task scheduler device of a computing system according to an embodiment of the present invention. FIG. [Figure 11] FIG. 2 is a diagram illustrating a pre-wake-up of a task scheduler device of a computing system according to an embodiment of the present invention. [Figure 12] FIG. 2 is a diagram illustrating a pre-wake-up of a task scheduler device of a computing system according to an embodiment of the present invention. [Figure 13] 5 is a flowchart showing a task scheduling process of a task scheduler device of a computing system according to an embodiment of the present invention. [Figure 14]1 is a hardware configuration diagram showing an example of a computer that realizes the functions of a task scheduler device of a computing system according to an embodiment of the present invention. [Figure 15] FIG. 1 is a diagram showing an example in which a computing system according to an embodiment of the present invention is applied to an interrupt model in a server virtualization environment having a generic Linux kernel (registered trademark) and a VM configuration. [Figure 16] FIG. 1 is a diagram illustrating an example in which a computing system according to an embodiment of the present invention is applied to an interrupt model in a server virtualization environment having a container configuration. [Figure 17] FIG. 1 is a diagram showing an example in which a computing system according to an embodiment of the present invention is applied to an interrupt model in a server virtualization environment having a generic Linux kernel (registered trademark) and a VM configuration. [Figure 18] FIG. 1 is a diagram illustrating an example in which a computing system according to an embodiment of the present invention is applied to an interrupt model in a server virtualization environment having a container configuration. [Figure 19] FIG. 1 is a diagram illustrating an overview of a wireless access system. [Figure 20] FIG. 10 is a diagram illustrating an example of task management for wireless access processing in a base station. [Figure 21] FIG. 11 is a table showing an example of the C-state. [Figure 22] 1 is a table showing an example of the maximum value of the time required for transition to a state (RESIDENCY) and the time required for recovery (WAKE-UP LATENCY). [Figure 23] FIG. 13 is a diagram for explaining CPU idle governor types. [Figure 24] This is a diagram explaining an overview of the menu logic. [Diagram 25] This is an image of the C-state transition of the CPU core used for calculation. [Figure 26] This is an image of the C-state transition of the CPU core used for calculation. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0026] Hereinafter, a computing system and the like in an embodiment for carrying out the present invention (hereinafter, referred to as "the present embodiment") will be described with reference to the drawings. [overview] Fig. 1 is a schematic diagram of a computing system according to an embodiment of the present invention. The same components as those in Fig. 20 are given the same reference numerals. This embodiment is an example of application to a CPU as a computing system. In addition to the CPU, the present invention can be similarly applied to processors such as GPUs (Graphic Processing Units), FPGAs (Field Programmable Gate Arrays), and ASICs (Application Specific Integrated Circuits) that have an idle state function.

[0027] As shown in FIG. 1, the computing system 1000 includes hardware (HW) 31, CPU cores (CPU core #0, CPU core #1, ...) 32 (processors) on the hardware 31, an OS 33, L1, L2, and L3 protocol wireless signal processing applications 1-1, 1-2, and 1-3 (collectively referred to as APL1), and a task scheduler device 100. The computing system 1000 is a computing system that reduces power consumption by gradually reducing the operating state of a processor according to a processing load. The computing system 1000 includes a processor having a plurality of core groups, and a task scheduler device 100 that assigns tasks to the core groups of the processor.

[0028] [Task scheduler device 100] The task scheduler device 100 includes a management unit 110, a task management unit 120, and a CPU idle state control unit .

[0029] <Management Department 110> The management unit 110 includes an operator setting unit 111 . The operator sets parameters related to the C-state in the operator setting unit 111. For example, the operator sets the C-state upper limit setting in advance in the operator setting unit 111, taking into consideration the time lag from when the C-state upper limit setting is set to when it is reflected.

[0030] <Task Management Section 120> The task management unit 120 includes a task priority setting unit 121, a task amount / cycle prediction unit 122 (processor utilization rate acquisition unit), and a task CPU allocation unit 123 (task allocation unit).

[0031] The task priority setting unit 121 sets task priorities as necessary for tasks sent from the APL 1. The task management unit 120 executes priority control of allocation to CPU cores according to these priorities.

[0032] Here, it is believed that the most accurate representation of the CPU state is the "CPU usage rate per unit time of the CPU core being used." The "CPU usage rate per unit time of the CPU core being used" can be estimated approximately from the amount of tasks. How busy the CPU is can be estimated from the amount of tasks, but it also depends on how many processes the CPU is not good at, which cannot be measured by the amount of tasks alone. Furthermore, if the processor is a GPU, FPGA, or ASIC other than a CPU, the processes that the processor is good at / not good at will also change. In this embodiment, the amount of tasks is used as a physical quantity related to the "CPU usage rate per unit time of the CPU core being used."

[0033] The task amount / cycle prediction unit 122 acquires the processor usage rate. Specifically, the task amount / cycle prediction unit 122 measures the task amount per unit time and the CPU usage rate according to the judgment logic shown in Fig. 4, and judges whether it is necessary to increase / decrease the number of CPU cores used for calculation. The task volume and period prediction unit 122 performs pre-wakeup for the newly used CPU core. When some processing is executed by the CPU core, in many CPU products, the C-state returns to C0. Therefore, there is a method of executing processing such as small operations or outputting a string to standard output on the corresponding CPU core.

[0034] Based on the processor usage rate obtained by the task CPU allocation unit 123 (processor usage rate acquisition unit) of the task volume and period prediction unit 122, for the core or core group of the processor that is used at a predetermined frequency or higher, tasks are continuously allocated. The task CPU allocation unit 123, for example, reduces the used CPU cores. As a method of reducing the CPU cores, determine the CPU cores that will not be used later, and prevent tasks from being allocated to the corresponding CPU cores later. The task CPU allocation unit 123 allocates the arrived tasks to the CPU cores (the allocation to the CPU cores may be a round-robin of the used CPU cores, or may be allocated to the CPU core with fewer remaining tasks in the task queue prepared for each CPU core), and schedules the tasks in the task queue prepared for each CPU core. At this time, according to the assigned priority, tasks with higher priority may be preferentially allocated to the idle CPU cores. Also, the task queues for each CPU core may be sorted according to the priority.

[0035] <CPU idle state control unit 130> The CPU idle state control unit 130 includes a CPU pre-wakeup unit 131 (pre-wakeup unit) and a C-state setting unit 132 (operation state setting unit). The CPU pre-wakeup unit 131 performs pre-wakeup to restore the operation state of the processor to the original state when allocating tasks to the newly used core or the core that is reused after not being used for a predetermined period (refer to the reference c in FIG. 1).

[0036] The C-state setting unit 132 sets an upper limit for a processor core or core group that is used at a predetermined frequency or more so that the processor operation state cannot be transitioned to a deeper state. Specifically, the C-state setting unit 132 applies a C-state upper limit setting to a CPU core that is newly used. The upper limit state is determined by the operator (see symbol b in FIG. 1). In addition, if there is a steady influx of tasks and tasks can be assigned continuously, the active CPU cores will not transition to deep C-states, so it may not be necessary to set an upper limit.

[0037] Instead of waking up in advance, you can set the C-state limit for the newly used CPU core before assigning tasks to it, and return it to a shallow state. In this case, you should set the C-state limit in advance, taking into account the time lag between setting the C-state limit and the effect of the setting. If a C-state upper limit has been set for a CPU core that has been determined not to be used, the C-state setting unit 132 cancels the upper limit setting. The C-state setting unit 132 sets the operating state of the processor for a core or core group to which the task CPU allocation unit 123 (task allocation unit) has not assigned a task so that the operating state of the processor can transition to a deeper state.

[0038] [Task scheduler device placement] 2 and 3 are diagrams for explaining the layout of the task scheduler apparatus 100 of FIG. Placement of the task scheduler device in user space FIG. 2 shows an example of a configuration in which the task scheduler device 100 of FIG. 1 is arranged in a user space. 2, the task scheduler device 100 is placed in a user space 60. The computation system 1000 executes a packet processing APL1 placed in the user space 60. The computation system 1000 executes the packet processing APL1 on a server having an OS.

[0039] The present invention can be applied to a case where there is a thread in user space 60, such as Intel DPDK (Intel Data Plane Development Kit) (DPDK) (registered trademark).

[0040] -Placing the task scheduler device in the OS FIG. 3 shows an example of a configuration in which the task scheduler device 100 of FIG. 3, a task scheduler device 100 is arranged in an OS 50. The computing system 1000 executes a packet processing APL1 on a server including the OS 50.

[0041] The present invention can be applied to a case where a thread exists inside a kernel, such as New API (NAPI) (registered trademark) (Non-Patent Document 1) or KBP (kernel-based virtual machine).

[0042] [Logic for estimating the required number of active CPU cores] The logic for estimating the required number of active CPU cores (see dashed box a in Figure 1) will now be explained. The inventors considered a method of continuously allocating tasks to the active CPU cores while transitioning the other CPU cores to a deeper C-state to reduce power consumption. To achieve this, when managing active CPU cores, it is necessary to calculate the number of CPU cores required based on factors such as the amount of incoming tasks.

[0043] FIG. 4 is a table showing the logic for estimating the required number of active CPU cores. As shown in Figure 4, the estimation logic judgments are classified into two types: "1. Judgment based on task arrival patterns" and "2. Judgment based on CPU usage," and judgments are made based on threshold judgment, periodicity, and machine learning, respectively. As shown in Fig. 4, the tasks to which each judgment logic can be applied differ, so select and use the appropriate logic by considering the applicability listed in the right column of the table in Fig. 4. In addition, multiple judgment logics may be used in combination.

[0044] The operation of the computing system 1000 configured as above will now be described. [Basic Concept of Task Scheduler Device 100 Operation] According to the present invention, in a computing system requiring real-time performance, a task scheduler that assigns tasks to a CPU core takes into account the C-state state of the CPU core when assigning tasks.

[0045] Features <1> :Continuation task assignment By reserving frequently used CPU cores and continuously allocating tasks to them, transitions to deep C-states can be prevented (Figures 5 to 7). As shown in the dashed box a in Figure 5, frequently used CPU cores (active CPU cores) are reserved according to the amount of tasks using the decision logic shown in Figure 4, and tasks are continuously assigned to the relevant CPU cores. This prevents transitions to deep C-states and reduces delays in returning from C-states. CPU cores other than the active ones can transition to deep C-states, resulting in power savings.

[0046] Features <2> :C-state upper limit setting As a countermeasure in the case where tasks cannot be continuously assigned, an upper limit on the C-state to which a transition can be made is set for frequently used CPU cores (Figures 8 to 10). As a response to the situation when tasks cannot be continuously assigned to active CPU cores, an upper limit on the C-state to which active CPU cores can transition is set, preventing transitions to deeper C-states and reducing recovery delays.

[0047] Features <3> :Pre-wake up By pre-waking up a CPU core that has transitioned to a deep state before assigning a task to it, the recovery time from the deep state can be reduced (Figures 11 to 12). By pre-waking up a newly used CPU core (a CPU core that has not been used for a long time) before assigning a task to it, the recovery time from a deep C-state is reduced. The following are the features: <1> ,Features <2> ,Features <3> We will explain these in order.

[0048] [Task volume threshold judgment and CPU usage threshold judgment] (Features <1> :Continuation task assignment) FIG. 5 is a diagram for explaining the task amount threshold determination and CPU utilization rate threshold determination operations of the task scheduler apparatus 100. In FIG.

[0049] <Task amount threshold judgment operation> First, the task amount threshold determination operation will be described. The task management unit 120 performs a task amount threshold determination operation. As indicated by the dashed arrow d in FIG. 5, the task priority setting unit 121 sets the priority of a task as necessary. The task amount / cycle prediction unit 122 measures the task amount per unit time and the CPU usage rate according to the decision logic shown in FIG. 4, and decides whether it is necessary to increase / decrease the number of CPU cores used for calculation.

[0050] FIG. 6 is a diagram showing an image of threshold determination according to the task inflow amount. The task management unit 120 manages the CPU cores according to the task inflow amount shown in FIG. In Fig. 6, the task inflow per unit time: W_input is associated with the number of CPU cores in use. For example, when W_input is "dd~ee", the number of CPU cores in use is "4", and the number of active CPU cores (see dashed box a in Fig. 5) is "4".

[0051] Returning to FIG. 5, the task CPU allocation unit 123 allocates the arrived tasks to the CPU cores and schedules the tasks in the task queues prepared for each CPU core. At this time, according to the assigned priority, the tasks with higher priority are preferentially allocated to the idle CPU cores. Also, the task queues for each CPU core are sorted according to the priority.

[0052] For tasks whose computation time is completed within a fixed time, the task management unit 120 designs the number of CPU cores required for the computation of the task inflow rate according to the threshold determination table in FIG. 6 for the task inflow rate per unit time. Also, when the task inflow rate exceeds the threshold (the threshold of W_input) in the threshold determination table in FIG. 6, it becomes possible to determine whether it is necessary to increase the number of CPU cores used. In FIG. 6, the state is dd < W_input < ee, and 4 CPU cores are being used. When the task inflow rate becomes W_input ≥ ee, the number of CPU cores is increased from 4 to 5.

[0053] <Example of calculating the required number of CPU cores> Next, an example of calculating the required number of CPU cores will be described. The task management unit 120 (FIG. 5) calculates the required number of CPU cores. When the computation time of the task is fixed (or has little variation), if the maximum waiting time Tw allowed by the service is defined, it becomes possible to calculate the number of CPU cores N required to satisfy the maximum waiting time using queuing theory. In Equation (3) of the following calculation formula, the return time from the C-state is not taken into account, but if the return time from the C-state can be made infinitely close to zero according to this embodiment, it becomes unnecessary to consider.

[0054] · Example of calculating the required number of CPU cores λ [tasks / s]: Task inflow rate (W_input) per unit time μ [tasks / s]: Number of tasks that the system can process per unit time Ts [s]: Time required for the system to process one task t_s [s]: Time required for one CPU core to perform one task computation Tw[s]: Maximum waiting time allowed in the service N[number]: Number of CPU cores in use ρ = λ / μ: Degree of congestion

[0055] μ = N / t_s Ts = 1 / μ = t_s / N

[0056] Tw = (ρ / (1 - ρ)) * Ts …(1)

[0057] When ρ and Ts are substituted into the above formula (1), it becomes formula (2). Tw = ((λ / μ) / (1 - (λ / μ)) * (t_s / N) …(2)

[0058] When μ is substituted into the above formula (2) and solved, formula (3) is obtained. N 2 -λ·t_s·N - λ·t_s 2 / Tw = 0 …(3) The smallest natural number that satisfies this equation is to be found.

[0059] <CPU Usage Threshold Judgment Operation> Next, the CPU usage threshold judgment operation will be described. Figure 7 is a diagram for explaining the threshold judgment image according to the CPU usage rate. The vertical axis is the average CPU usage rate of the CPU cores in use, and the horizontal axis is time. For 100% of the average CPU usage rate, two thresholds, Threshold_upper (upper limit) (refer to the dashed line e in Figure 7) and Threshold_base (lower limit) (refer to the dashed line f in Figure 7) are set. When the average CPU usage rate exceeds the upper limit, the task management unit 120 (Figure 5) increases the CPU cores to be used. Also, when the average CPU usage rate falls below the lower limit, the CPU cores to be used are decreased.

[0060] When the average CPU usage rate of the CPU cores in use exceeds Threshold_upper (upper limit), it is a sign that the available CPU cores are insufficient, and a decision can be made to increase the number of CPU cores. On the other hand, when the average CPU usage rate of the CPU cores in use is below Threshold_base (lower limit), it indicates that the CPU cores are excessive, and a decision can be made to downscale the CPU cores in use.

[0061] Here, when increasing the number of CPU cores, since the newly added CPU cores have not been used before, it is assumed that they are in a deep C-state. In particular, the method for calculating the recovery time when returning a CPU core in such a deep C-state has been described in the above <Example of calculating the required number of CPU cores>. The above describes the task volume threshold determination and the CPU usage rate threshold determination.

[0062] [C-state upper limit setting] (Feature <2>: C-state upper limit setting) <C-state upper limit setting operation> FIG. 8 is a diagram for explaining the C-state upper limit setting of the task scheduler device 100. The C-state setting unit 132 of the CPU idle state control unit 130 sets the upper limit of the C-state that can be transitioned for the group of frequently used CPU cores (see reference numeral b in FIG. 8).

[0063] For frequently used CPU cores, since tasks are likely to be assigned, even if they transition to a deep idle state, the residence time in the corresponding state is short, and the power saving effect cannot be fully enjoyed. Despite the inability to enjoy the power saving effect, there may be a drawback that an overhead in the recovery time from the idle state occurs.

[0064] In this embodiment, to address this issue, for frequently used CPU cores, an upper limit on the CPU idle state to which they can transition (for example, see C1 and C1E in FIG. 22) is set, and they are set so that they cannot transition to a state deeper than that state. This allows them to return from a shallower state when a task is assigned, reducing the return delay time.

[0065] The number of CPU cores to be used for setting / releasing the upper limit of the CPU idle state can be determined by using the determination logic shown in Fig. 4. The C-state setting unit 132 dynamically sets the upper limit of the CPU idle state using the determination logic shown in Fig. 4.

[0066] Also, when you add new CPU cores (after a long time), you can set the C-state upper limit to return the CPU cores to a shallow C-state before assigning tasks to them.

[0067] Fig. 9 is a diagram for explaining an image of setting a C-state upper limit. The upper diagram of Fig. 9 shows a case where there is no C-state upper limit setting, and the lower diagram of Fig. 9 shows a case where there is a C-state upper limit setting. As shown in the upper diagram of Figure 9, if there is no C-state upper limit setting, the CPU will fall to the CPUidle state (grade C2), and the delay until returning to C0 will be longer. In response to this, as shown in the lower diagram of Figure 9, by setting an upper C-state limit for frequently used CPU cores (see symbol g in the lower diagram of Figure 9), transition to a deeper state is prevented, and the recovery delay time when returning from a shallower state is reduced.

[0068] <Pooling of highly available CPU cores> Next, we will explain pooling of highly available CPU cores as an extension of the C-state upper limit setting. FIG. 10 is a diagram for explaining pooling of highly available CPU cores in the task scheduler apparatus 100. In FIG. As shown in Fig. 10, if future use is expected, a group of CPU cores (h enclosed by dashed lines in Fig. 10) that are set to fall only into a shallow idle state may be prepared. For example, the CPU cores (CPUcore #4, CPUcore #5) 32 shown in Fig. 10 are pooled as a group of CPU cores that can only transition up to C1.

[0069] When it is possible to predict which CPU cores are likely to be used in the future based on task trends, such as processing nighttime / daytime traffic fluctuations, set the group of CPU cores likely to be used (h in the dashed box in Figure 10) so that they can only transition to shallow idle states (e.g. up to C1, etc.). Then, prepare a pool of active-standby CPU cores so that they can be used immediately when needed. In this way, if future use is expected, a CPU core group that is configured so that it can only fall into a shallow idle state is prepared (for example, a CPU core group that can only transition to C1 is pooled). The above describes the C-state upper limit setting.

[0070] [Pre-wake up] (Features <3> :Pre-wake up) FIG. 11 is a diagram for explaining the advance wake-up of the task scheduler apparatus 100. As shown in FIG. The CPU pre-wake-up unit 131 pre-wakes up a CPU core that has fallen into a deep CPU idle state (C-state) when the CPU core is to be used (see symbol c in FIG. 11).

[0071] Fig. 12 is a diagram for explaining advance wake-up of the task scheduler apparatus 100. The upper diagram of Fig. 12 shows the case of the existing technology, and the lower diagram of Fig. 12 shows the case where advance wake-up of the task scheduler apparatus 100 is performed. As shown in the upper diagram of Figure 12, in the case of existing technology (without prior wake-up), there is a large delay from task allocation (symbol i in the upper diagram of Figure 12) to the start of calculation (symbol j in the upper diagram of Figure 12). In contrast, as shown in the lower diagram of Figure 12, when there is pre-wakeup, the pre-wakeup (symbol c in the lower diagram of Figure 12) results in low latency from task allocation to the start of calculation (symbol k in the lower diagram of Figure 12).

[0072] In this way, infrequently used CPU cores can be transitioned to a deeper C-state, reducing power consumption while also reducing the impact of latency associated with returning from a deeper C-state.

[0073] [Operation flow of the task scheduler device 100] FIG. 13 is a flowchart showing the task scheduling process of the task scheduler apparatus 100. In step S11, APL1 (FIG. 1) registers a task in task management unit 120 (FIG. 1).

[0074] In step S12, the task priority setting unit 121 (FIG. 1) sets priorities of tasks as necessary. The task CPU allocation unit 123 (FIG. 1) executes priority control of allocation to CPU cores according to the priorities.

[0075] In step S13, the task amount / cycle prediction unit 122 (FIG. 1) measures the task amount per unit time and the CPU usage rate in accordance with the decision logic shown in FIG. 4, and decides whether it is necessary to increase / decrease the number of CPU cores used for calculation (branching after the decision is performed in steps S14 and S15 below).

[0076] If it is determined in step S14 that the number of CPU cores needs to be reduced (S14: Yes), the process proceeds to step S17. If it is determined that the number of CPU cores does not need to be reduced (S14: No), the process proceeds to step S15.

[0077] If it is determined in step S15 that the number of CPU cores needs to be increased (S15: Yes), the process proceeds to step S19. If it is determined that the number of CPU cores does not need to be increased (S15: No), the process proceeds to step S16.

[0078] In step S16, the task CPU allocation unit 123 (FIG. 1) allocates the arrived task to a CPU core, schedules the task in a task queue prepared for each CPU core, and ends the processing of this flow. The allocation to the CPU core may be a round-robin method among the CPU cores in use, or may be a method of allocating the task to a CPU core with the fewest remaining tasks in the task queue prepared for each CPU core.

[0079] In addition, the task CPU allocation unit 123 (FIG. 1) may preferentially allocate high-priority tasks to available CPU cores according to the assigned priorities, or may rearrange the task queues for each CPU core according to the priorities.

[0080] If it is necessary to reduce the number of CPU cores in step S14, the task CPU allocation unit 123 (FIG. 1) reduces the number of CPU cores to be used in step S17. For example, as a method of reducing the number of CPU cores, a CPU core that will no longer be used is determined, and no tasks are assigned to that CPU core thereafter.

[0081] In step S18, if a C-state upper limit has been set for the CPU core that has been determined not to be used, C-state setting unit 132 (FIG. 1) cancels the C-state upper limit setting and ends the processing of this flow.

[0082] If it is necessary to increase the number of CPU cores in step S15, the task amount / cycle prediction unit 122 (FIG. 1) performs pre-wake-up on the CPU cores to be newly used in step S19. The reason for pre-waking up a newly used CPU core is as follows: In other words, many CPU products return the C-state to C0 if any processing is executed on the CPU core. Therefore, by executing minor processing on the CPU core, such as small calculations or outputting strings to standard output, the CPU core is prevented from transitioning to a deeper C-state.

[0083] Here, instead of waking up in advance, for the newly used CPU core described in <C-state upper limit setting> (Fig. 8), the C-state upper limit setting may be performed before allocating tasks, and it may be returned to a shallow state. In this case, considering the time lag from when the C-state upper limit setting is turned on to when it is reflected, the C-state upper limit setting is turned on in advance.

[0084] In step S20, the C-state setting unit 132 turns on the C-state upper limit setting for the newly used CPU core and ends the processing of this flow. The upper limit state is determined by being set by the operator in advance.

[0085] Note that when tasks constantly flow in and tasks can be continuously allocated, since the active CPU core group does not transition to a deep C-state, there may be cases where the C-state upper limit setting does not need to be turned on.

[0086] [Hardware Configuration] The task scheduler devices 100 and 100A (Figs. 1 and 10) according to the above embodiment are realized by a computer 900 having a configuration as shown in Fig. 14, for example. Fig. 14 is a hardware configuration diagram showing an example of a computer 900 that realizes the functions of the task scheduler devices 100 and 100A (Figs. 1 and 10). The computer 900 includes a CPU 901, a ROM 902, a RAM 903, an HDD 904, a communication interface (I / F) 906, an input / output interface (I / F) 905, and a media interface (I / F) 907.

[0087] The CPU 901 operates based on a program stored in the ROM 902 or the HDD 904, and controls each part of the task scheduler devices 100 and 100A (Figs. 1 and 10). The ROM 902 stores a boot program executed by the CPU 901 when the computer 900 is started up, a program dependent on the hardware of the computer 900, and the like.

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

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

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

[0091] For example, when the computer 900 functions as the task scheduler devices 100 and 100A (FIGS. 1 and 10) configured as one device according to the present embodiment, the CPU 901 of the computer 900 realizes the functions of the task scheduler devices 100 and 100A by executing a program loaded on the RAM 903. Further, the HDD 904 stores the data in the RAM 903. The CPU 901 reads and executes a program related to the target process from the recording medium 912. In addition, the CPU 901 may read a program related to the target process from another device via the communication network (NW920).

[0092] [Application Example] (Configuration in which the task scheduler device is arranged in User space60) As shown in FIG. 2, it can be applied to a configuration example in which the task scheduler device 100 is arranged in User space60. In this case, the OS is not limited. Also, it is not limited to being in a server virtualization environment. Therefore, the arithmetic system can be applied to each configuration shown in FIGS. 15 and 16.

[0093] <Application Example to VM Configuration> Against the backdrop of the progress of virtualization technologies such as NFV (Network Functions Virtualization), systems are being constructed and operated for each service. Also, from the form of constructing a system for each service, the service functions are divided into reusable module units and operated on an independent virtual machine (VM: Virtual Machine or container, etc.) environment, and a form called SFC (Service Function Chaining) that enhances operability by using it as needed like a component is becoming the mainstream.

[0094] A known technology for configuring virtual machines is a hypervisor environment consisting of Linux (registered trademark) and KVM (kernel-based virtual machine). In this environment, a Host OS (an OS installed on a physical server is called a Host OS) with a built-in KVM module operates as a hypervisor in a memory area called kernel space, which is different from the user space. In this environment, a virtual machine operates in the user space, and a Guest OS (an OS installed on a virtual machine is called a Guest OS) operates within the virtual machine.

[0095] A virtual machine running a Guest OS is different from a physical server running a Host OS in that all HW (hardware), including network devices (typified by Ethernet (registered trademark) card devices, is subject to register control required for interrupt processing from the HW to the Guest OS and writing from the Guest OS to the hardware. In this type of register control, notifications and processing that should be executed by physical hardware are simulated by software, so performance is generally lower than in a Host OS environment.

[0096] 15 is a diagram showing an example in which a computing system 1000A is applied to an interrupt model in a server virtualization environment with a generic Linux kernel (registered trademark) and a VM configuration. The same components as those in FIG. 1 are denoted by the same reference numerals. 15, the computing system 1000A includes a Host OS 80 on which a virtual machine and an external process formed outside the virtual machine can run, and the Host OS 80 includes a Kernel 81 and a Driver 82. The computing system 1000A also includes a CPU 71 of a HW 70 connected to the Host OS 80, and a KVM module 91 incorporated in a hypervisor (HV) 90. The computing system 1000A also includes a Guest OS 95 that runs in the virtual machine, and the Guest OS 95 includes a Kernel 96 and a Driver 97. The arithmetic system 1000A includes a task scheduler device 100 that is connected to the Guest OS 95 and arranged in the User space 60.

[0097] By doing so, in the system of the virtual server configuration of the VM, arithmetic operations can be performed with low latency while achieving power saving in any of the Host OS 80 and the Guest OS 95.

[0098] <Example of application to container configuration> FIG. 16 is a diagram showing an example in which the arithmetic system 1000B is applied to an interrupt model in a server virtualization environment with a container configuration. The same components as those in FIGS. 1 and 15 are denoted by the same reference numerals. As shown in FIG. 16, the arithmetic system 1000B has a container configuration in which the Guest OS 95 in FIG. 15 is replaced by a Container 98. The Container 98 has a vNIC (virtual NIC).

[0099] In a system with a virtual server configuration such as a container, arithmetic operations can be performed with low latency while achieving power saving. As described above, the form of arranging the task scheduler device 100 in the user space 60 has been described. Next, the form of arranging the task scheduler device 100 in the kernel will be described.

[0100] (Form of arranging a task scheduler device in the kernel within the OS) As shown in FIG. 3, it can be applied to a configuration example in which the task scheduler device 100 is arranged within the OS 50. In this case, the OS is not limited. Also, it is not limited to being under a server virtualization environment. Therefore, the arithmetic system can be applied to each configuration shown in FIGS. 17 and 18.

[0101] <Example of application to VM configuration> FIG. 17 is a diagram showing an example in which the arithmetic system 1000C is applied to an interrupt model in a general-purpose Linux kernel (registered trademark) and server virtualization environment with a VM configuration. The same components as those in FIGS. 1 and 15 are denoted by the same reference numerals. As shown in FIG. 17, in the arithmetic system 1000C, the task scheduler device 100 is arranged in the Kernel 81 of the Host OS 80, and the task scheduler device 100 is arranged in the Kernel 96 of the Guest OS 95.

[0102] By doing so, in the system of the virtual server configuration of the VM, in either the Host OS 80 or the Guest OS 95, arithmetic operations can be performed with low latency while achieving power saving.

[0103] <Example of Application to Container Configuration> FIG. 18 is a diagram showing an example in which the arithmetic system 1000D is applied to an interrupt model in a server virtualization environment with a container configuration. The same components as those in FIGS. 1 and 16 are denoted by the same reference numerals. As shown in FIG. 19, in the arithmetic system 1000D, the task scheduler device 100 is arranged in the Kernel 81 of the Host OS 80.

[0104] In a system with a virtual server configuration such as a container, arithmetic operations can be performed with low latency while achieving power saving.

[0105] <Example of Application to Bare Metal Configuration (Non-Virtualized Configuration)> The present invention can be applied to a non-virtualized configuration system such as a bare metal configuration. In a non-virtualized configuration system, arithmetic operations can be performed with low latency while achieving power saving.

[0106] <Application to Processors Other Than CPU> The present invention can also be similarly applied to processors such as GPU / FPGA / ASIC in addition to the CPU when they have an idle state function.

[0107] <Application to CPU Operation Frequency Control> The present invention can also be applied to a mechanism that restores the frequency in advance before task allocation when the processor operation frequency is low in the pre-wake-up according to the embodiment.

[0108] <Application to Functions Other than CPU> The present invention can also be applied to functions other than the CPU, such as memory and storage (e.g., HDD, SSD). Furthermore, it can also be applied to the case where components to external connected peripheral devices, etc. are woken up in advance and prepared until they are used when they enter the power-saving mode.

[0109] [Effect] As described above, in the computing system 1000 (FIG. 1, FIG. 10) that reduces the operating state of the processor step by step according to the processing load to reduce the power consumption, the task scheduler devices 100, 100A (FIG. 1, FIG. 10) that allocate tasks to the core group of the processor, comprising a processor utilization rate acquisition unit (task amount / cycle prediction unit 122) that acquires the utilization rate of the processor, and a task allocation unit (task CPU allocation unit 123) that continuously allocates tasks to the core or core group of the processor that is used at a predetermined frequency or higher based on the utilization rate of the processor acquired by the processor utilization rate acquisition unit.

[0110] By doing so, according to the utilization rate of the processor (e.g., task amount), the frequently used CPU core group (Active CPU core group) is ensured by the determination logic shown in FIG. 4, and by continuously allocating tasks to the CPU core group, the transition to a deep C-state is prevented. As a result, the return delay from the C-state can be reduced. On the other hand, other than the Active CPU cores, they can transition to a deep C-state (e.g., C6), so power saving can be achieved. As a result, from the perspective of the entire computing system 1000, it is possible to perform calculations with low latency while achieving power saving.

[0111] Since the CPU core can be dropped into a deep C-state, power reduction effects can be maximized while avoiding the issue of dropping into a deep C-state and taking a long time to return.

[0112] In addition, it is possible to dynamically increase or decrease the number of CPU cores used depending on the amount of tasks and CPU usage, making it possible to dynamically scale in / out depending on the amount of tasks.

[0113] In addition, it is possible to select multiple decision logic (Figure 4) that changes the number of CPU cores to be used depending on the amount of tasks and CPU usage, making it possible to handle a wide variety of tasks.

[0114] In the task scheduler apparatus 100, 100A (FIGS. 1 and 10), an operating state setting unit (C-state setting unit 132) is provided that sets an upper limit for a processor core or group of cores that are used at a predetermined frequency or more so that the processor operating state cannot be transitioned to a deeper state.

[0115] In this way, by setting an upper limit on the CPU idle state that can be transitioned to for frequently used CPU cores, transition to a deeper C-state is prevented, and recovery delays are reduced. This reduces the delay time from task allocation to the start of calculation, enabling calculations to be performed in high real-time.

[0116] This is particularly effective as a countermeasure when tasks cannot be continuously assigned to frequently used CPU cores.

[0117] In addition, by assigning a priority to a task, it is possible to perform computation with priority on a task that is desired to be prioritized. For example, a task that is to be computed with priority is one that requires a guarantee of QoS (Quality of Service).

[0118] In the task scheduler device 100, 100A (FIGS. 1 and 10), the operation state setting unit (C-state setting unit 132) sets the operation state of the processor for a core or core group to which a task has not been assigned by the task allocation unit (task CPU allocation unit 123) so that the processor operation state can be transitioned to a deeper state.

[0119] By doing this, tasks can be continuously assigned to frequently used CPU cores (active CPU cores) and transitions to deeper C-states can be prevented (reducing the delay in returning from C-states), while CPU cores other than the active CPU cores can transition to deeper C-states, thereby saving power.

[0120] In the task scheduler devices 100, 100A (FIGS. 1 and 10), a core to be used for the first time or a core to be used again after not being used for a predetermined period of time is provided with a pre-wake-up unit (CPU pre-wake-up unit 131) that performs a pre-wake-up to restore the operating state of the processor to its original state when a task is assigned to the core.

[0121] The basic idea is that if it takes a long time from when a task is assigned until the processing is finished and the system returns, the system will wake up the processor in advance for the time it will take to return, so that the CPU is ready to use. In this way, by waking up a CPU core in advance before allocating a task to the CPU core that has transitioned to a deep state, the recovery time from the deep state can be reduced. A newly used core, or a core that has not been used for a predetermined period of time and will be used again, is assumed to be in a deep C-state. By waking up the CPU core in advance before allocating a task, for example, when increasing the number of CPU cores to be used, the delay time from task allocation to the start of calculation can be reduced, even if the core has fallen into a deep CPU idle state, making it possible to perform calculations with high real-time performance.

[0122] Also, a computing system 1000 (FIGS. 1 and 10) that reduces power consumption by gradually reducing the operating state of a processor in accordance with a processing load, the processor (CPU) has a plurality of core groups (CPU cores (CPUcore #0, CPUcore #1, ...) 32), and is equipped with a task scheduler device 100, 100A (FIGS. 1 and 10) that assigns tasks to the processor core groups, the task scheduler device 100, 100A being equipped with a processor utilization rate acquisition unit (task amount / cycle prediction unit 122) that acquires a processor utilization rate, and a task allocation unit (task CPU allocation unit 123) that continuously assigns tasks to a processor core or core group that is used at a predetermined frequency or more based on the processor utilization rate acquired by the processor utilization rate acquisition unit.

[0123] The calculation systems 1000 to 1000D (FIGS. 1, 10, 15 to 18) are not limited to packet arrival and processing tasks, but are extended to general tasks such as the calculation of π. By continuously allocating tasks to frequently used CPU cores (active CPU cores) according to processor usage, transitions to deep C-states can be prevented and recovery delays from C-states can be reduced. Meanwhile, non-active CPU cores can transition to deep C-states, which can save power. In other words, while reducing recovery delays from C-states, pre-wake-up can maintain the deepest LPI (C-state) for as long as possible, achieving both low latency and power savings.

[0124] The above processor can be applied to processors other than CPUs, such as GPUs, FPGAs, and ASICs, if they have an idle state function.

[0125] In the computing system 1000 (FIGS. 1 and 10), it is possible to achieve low latency while simultaneously achieving power saving. In particular, by continuously allocating tasks to a group of CPU cores that are frequently used (active CPU cores), it is possible to avoid the problem of a CPU core falling into a deep idle state, which results in a long latency time when returning from the state. This makes it possible to guarantee low latency.

[0126] In addition, 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 a known method. In addition, the information including the processing procedures, control procedures, specific names, various data and parameters shown in the above documents and drawings can be changed arbitrarily unless otherwise specified. In addition, each component of each device shown in the figure is a functional concept, and does not necessarily have to be physically configured as shown in the figure. In other words, the specific form of distribution and integration of each device is not limited to that shown in the figure, and all or part of them can be functionally or physically distributed and integrated in any unit according to various loads, usage conditions, etc.

[0127] In addition, the above-mentioned configurations, functions, processing units, processing means, etc. may be realized in part or in whole by hardware, for example, by designing them as integrated circuits. In addition, the above-mentioned configurations, functions, etc. may be realized by software for a processor to interpret and execute a program that realizes each function. Information on the programs, tables, files, etc. that realize each function can be stored in a 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, SD (Secure Digital) card, or optical disk. [Explanation of symbols]

[0128] 31 Hardware (HW) 32 CPU cores (processors) 1,1-1,1-2,1-3 Application (APL) 100,100A Task Scheduler Device 110 Management Department 111 Operator Settings 120 Task Management Department 121 Task Priority Assignment Unit 122 Task volume and period prediction unit (processor utilization acquisition unit) 123 Task CPU allocation unit (task allocation unit) 120 Task management unit 130 CPU idle state control unit 131 CPU pre-wake-up part (pre-wake-up part) 132 C-state setting unit (operation state setting unit) 1000, 1000A, 1000B, 1000C, 1000D Calculation system (calculation system) CPUcore #0, CPUcore #1, ... CPU core

Claims

1. 1. A task scheduler device for allocating tasks to a core group of a processor in a computing system that reduces power consumption by gradually reducing an operating state of the processor in accordance with a processing load, comprising: a processor utilization rate acquisition unit for acquiring a utilization rate of the processor; a task allocation unit that continuously allocates tasks to a core or a group of cores of the processor that are used at a frequency equal to or higher than a predetermined frequency based on the utilization rate of the processor acquired by the processor utilization rate acquisition unit; and an operation state setting unit that sets an upper limit for a core or a group of cores of the processor that are used at a predetermined frequency or more so that the operation state of the processor cannot be transitioned to a deeper state. A task scheduler device comprising:

2. The operation state setting unit is For a core or a group of cores to which the task allocation unit has not assigned a task, the operating state of the processor is set so as to be able to transition to a deeper state.

2. The task scheduler device according to claim 1, wherein the task scheduler device comprises: a processor;

3. 3. A program for causing a computer to function as the task scheduler device according to claim 1.

Images