Task scheduler device, task scheduling method, and program
The task scheduler device addresses latency and power consumption issues by managing CPU core usage through C-state limits and pre-waking, enhancing performance in real-time systems.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- NIPPON TELEGRAPH & TELEPHONE CORP
- Filing Date
- 2022-07-11
- Publication Date
- 2026-07-22
AI Technical Summary
Existing systems face challenges in achieving low latency while maintaining power savings, particularly in base stations where deep CPU idle states lead to prolonged resume times, impairing real-time performance.
A task scheduler device that dynamically manages CPU core usage by setting C-state limits, pre-waking cores, and continuously assigning tasks to active cores to prevent deep sleep states, thereby reducing latency and power consumption.
The solution enables low-latency calculations with power savings by preventing deep CPU idle states and minimizing recovery delays, ensuring efficient task management in real-time systems.
Smart Images

Figure 0007893262000001 
Figure 0007893262000002 
Figure 0007893262000003
Abstract
Description
Technical Field
[0001] The present invention relates to a task scheduler device ,Ta a scheduling method and a program.
Background Art
[0002] An overview of a radio access system will be described. FIG. 19 is a diagram for explaining an overview of a radio access system. As shown in FIG. 19, a radio 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 40.
[0003] The antenna 20 is an antenna and a transceiver that wirelessly communicates with the UE10 (hereinafter, the "antenna" generically refers to the antenna, the transceiver, and its power supply unit). The transmitted and received data is connected to the base station 30 by, for example, a dedicated cable.
[0004] The base station 30 is a fixed radio station established on land that communicates with the UE10. The base station (BBU: Broad Band Unit) 30 that performs radio signal processing is dedicated hardware (a dedicated device) for performing radio signal processing. Alternatively, the base station 30 is a vRAN (virtual Radio Access Network) that processes radio signal processing in a signal processing aggregation system such as LTE (Long Term Evolution) or 5G (five generation) using a general-purpose server. In the vRAN, a general-purpose server that is inexpensive and can be obtained 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 33, etc., L1, L2, L3 protocol radio signal processing applications (when collectively referred to, called APL1), and a task scheduler device 34.
[0005] The core network 40 is an EPC (Evolved Packet Core) / (in the following explanation, " / " indicates "or") 5GC (5G Core Network), etc.
[0006] One example of a system requiring real-time performance is a base station unit (BBU) in a Range Area Network (RAN). In a BBU that performs calculations using the CPU 32, the task scheduler device 34 often assigns wireless signal processing tasks to the CPU cores to perform calculations (Non-Patent Literature 1).
[0007] Figure 20 illustrates an example of task management for wireless access processing at a base station. The same reference numerals are used for components identical to those in Figure 19. The base station unit (BBU) 30 is equipped with a task scheduler device 34. The task scheduler device 34 performs task management, prioritization, and task allocation. The task scheduler device 34 assigns the APL1 wireless signal processing task to the task queue 37, and then assigns it from the task queue 37 to the CPU cores (CPUcore #0, CPUcore #1, ...) 32.
[0008] [LPI (Low Power Idle) Hardware Control] The CPU32 has a function called LPI, which controls the idle state of the CPU32 through hardware control. LPI is often referred to as CPUidle or C-state, and below, LPI will be explained as C-state. C-state is 、C When the PU load decreases, power saving is attempted by turning off the power to some of the CPU32's circuits (Non-Patent Literature 2).
[0009] Figure 21 is a table illustrating an example of the C-state configuration. Note that the state definition varies depending on the CPU hardware, so Figure 21 is for reference only. As shown in Figure 21, the CPUidle state has grades C0 to C6, and as the time spent without CPU load increases, it transitions to a deeper sleep state. While a deeper sleep state consumes less CPU power, it also increases the time required to recover, which can be a challenge from a low-latency perspective.
[0010] The definition of C-states varies depending on the CPU hardware. For example, there are variations such as models that do not have C4 or C5 states, or models where the state after C1 is C1E. As the state deepens, the power saving effect increases, but the time required to recover from the idle state also increases.
[0011] 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).
[0012] Figure 22 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 LATENCY). Figure 22 represents the C-state information for the Intel Xeon CPU E5-26X0 v4 (registered trademark).
[0013] [CPUidle State Governor] The Linux kernel 4 (registered trademark) provides two types of governors to manage the CPU idle state (C-state).
[0014] Figure 23 is a diagram illustrating the different types of CPU idle Governors. As shown in Figure 23, `ladder` is used for tick-enabled systems, while `menu` is used for tickless systems. For example, the menu used in tickless systems 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] Figure 24 is a diagram illustrating the logic overview of the menu. As shown in the left panel of Figure 24, the menu records the most recent idle time. Then, as shown in the middle panel of Figure 24, it estimates the next idle time. For example, based on the idle time shown in the left panel 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 panel of Figure 24, the menu estimates a suitable idle state depth based on the estimated next idle time. For example, if the estimated next idle time T_avr is equal to the exit latency (return time from idle state Cx), it is determined that the state is too deep, and the system transitions to the Cx-1 idle state.
[0016] Returning to Figure 23, neither of the two types of Governor ladders and menus has a mechanism to pre-wake the CPU from the idle state and prepare it when a new task arrives. Therefore, when assigning a task while in a deep state, there is a problem of a delay time due to the wake-up time. [Prior art documents] [Non-patent literature]
[0017] [Non-Patent Document 1] New API (NAPI), [online], [searched 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], [Searched on June 6, 2022], Internet <URL: https: / / link.springer.com / article / 10.1007 / s00450-014-0270-z#citeas>
Summary of the Invention
Problems to be Solved by the Invention
[0018] As shown in FIG. 21, there are grades in the CPU idle state, and as the time with no CPU load becomes longer, it transitions to a deep sleep state. The deep sleep state has lower CPU power consumption, but on the other hand, the time required to resume increases, which may pose a problem from the perspective of low latency.
[0019] FIGS. 25 and 26 are C-state transition images of the CPU core used for calculations. FIG. 25 shows the case where the time without tasks is short, and FIG. 26 shows the case where the time without tasks is long. As shown in FIG. 25, when the time without tasks is short, the CPU core is in a shallow sleep state, and after a task occurs, the delay time until resumption is short. However, as shown in FIG. 26, when the time without tasks is long, the CPU core is in a deep sleep state (CPU idle state: grade C6), and after a task occurs, the delay time until resumption increases. When it drops to a deep CPU idle state, it takes a long time to resume, and there is a problem that real-time performance is impaired.
[0020] The above problems are issues that cannot be overlooked in a system where real-time performance is prioritized, such as the base station (BBU) 30 shown in FIGS. 19 and 20. Therefore, in the base station (BBU), measures are taken to disable the C-state or to set a configuration that limits the transition to the idle state to a limited depth such as C1. That is, tuning may be performed that sacrifices power saving and aims at real-time performance.
[0021] In the conventional base station (BBU), once it dropped to a deep C-state, it had no choice but to wait until it returned. For this reason, measures were taken that sacrificed power saving and did not drop to a deep level.
[0022] The present invention has been made in view of such a background, and an object of the present invention is to perform calculations with low latency while achieving power saving.
Means for Solving the Problems
[0023] To solve the above problems, It has a processor that can transition to multiple sleep states, A task scheduler device that assigns tasks to a core group of a processor, the device including a usage rate acquisition unit that acquires the usage rate of the processor, It has a decision logic that determines whether to increase or decrease the number of CPU cores used for calculations, and based on this decision logic, the processor When the usage rate is Exceeded the threshold A task assignment unit that continuously assigns tasks to the core or core group of the processor, and a task scheduler device characterized by comprising the same.
Effects of the Invention
[0024] According to the present invention, it is possible to perform calculations with low latency while achieving power saving.
Brief Description of the Drawings
[0025] [Figure 1] It is a schematic configuration diagram of an arithmetic system according to an embodiment of the present invention. [Figure 2] It is a configuration example in which a task scheduler device of an arithmetic system according to an embodiment of the present invention is arranged in user space. [Figure 3] It is a configuration example in which a task scheduler device of an arithmetic system according to an embodiment of the present invention is arranged in the OS. [Figure 4] This figure shows, in table form, the logic for estimating the required number of active CPU cores in the task scheduler device of the computing system according to an embodiment of the present invention. [Figure 5] This figure illustrates the task quantity threshold determination and CPU usage threshold determination operations of the task scheduler device of a computing system according to an embodiment of the present invention. [Figure 6] This figure shows a threshold determination image for a task scheduler device in a computing system according to an embodiment of the present invention, based on the amount of tasks flowing in. [Figure 7] This figure illustrates a threshold determination image based on the CPU usage rate of a task scheduler device in a computing system according to an embodiment of the present invention. [Figure 8] This figure illustrates the setting of the C-state upper limit for the task scheduler device of a computing system according to an embodiment of the present invention. [Figure 9] This figure illustrates the case where there is no C-state upper limit setting and the case where a C-state upper limit setting is set in the calculation system according to the present invention. [Figure 10] This figure illustrates the pooling of highly usable CPU cores in a task scheduler device of a computing system according to an embodiment of the present invention. [Figure 11] This figure illustrates the pre-wake function of the task scheduler device of a computing system according to an embodiment of the present invention. [Figure 12] This figure illustrates the pre-wake function of the task scheduler device of a computing system according to an embodiment of the present invention. [Figure 13] This is a flowchart showing the task scheduling process of a task scheduler device in a computing system according to an embodiment of the present invention. [Figure 14] This is a hardware configuration diagram showing an example of a computer that implements the functions of a task scheduler device in a computing system according to an embodiment of the present invention. [Figure 15] This figure shows an example of applying the computing system according to an embodiment of the present invention to an interrupt model in a server virtualization environment with a general-purpose Linux kernel (registered trademark) and a VM configuration. [Figure 16] This figure shows an example of applying the computing system according to an embodiment of the present invention to an interrupt model in a containerized server virtualization environment. [Figure 17] This figure shows an example of applying the computing system according to an embodiment of the present invention to an interrupt model in a server virtualization environment with a general-purpose Linux kernel (registered trademark) and a VM configuration. [Figure 18] This figure shows an example of applying the computing system according to an embodiment of the present invention to an interrupt model in a containerized server virtualization environment. [Figure 19] This is a diagram illustrating the overview of a wireless access system. [Figure 20] This diagram illustrates an example of task management for wireless access processing at a base station. [Figure 21] This diagram shows an example of a C-state configuration in a table format. [Figure 22] This diagram shows an example of the maximum values for the transition time to a given state (RESIDENCY) and the time required to return to the previous state (WAKE-UP LATENCY). [Figure 23] This diagram explains CPU governor types. [Figure 24] This diagram illustrates the logic overview of the menu. [Figure 25] This is a diagram illustrating the C-state transitions of the CPU cores used for calculations. [Figure 26] This is a diagram illustrating the C-state transitions of the CPU cores used for calculations. [Modes for carrying out the invention]
[0026] The following describes the calculation system and other components in an embodiment of the present invention (hereinafter referred to as "this embodiment") with reference to the drawings. [overview] Figure 1 is a schematic diagram of a calculation system according to an embodiment of the present invention. The same reference numerals are used for components identical to those in Figure 20. This embodiment is an example of application to a CPU as a computing system. It can also be similarly applied to other processors such as GPUs (Graphics Processing Units), FPGAs (Field Programmable Gate Arrays), and ASICs (Application Specific Integrated Circuits) if they have an idle state function.
[0027] As shown in Figure 1, the computing system 1000 comprises hardware (HW) 31, CPU cores (CPUcore #0, CPUcore #1, ...) 32 (processors) on the hardware 31, OS 33, L1, L2, L3 protocol wireless signal processing applications 1-1, 1-2, 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 the processor according to the processing load. The computing system 1000 has a processor with multiple core groups and includes 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 comprises a management unit 110, a task management unit 120, and a CPU idle state control unit 130.
[0029] <Management Department 110> The management unit 110 includes an operator configuration unit 111. The operator configuration unit 111 allows the operator to set parameters related to C-state. For example, the operator configuration unit 111 allows the administrator to pre-enter the C-state limit setting, taking into account the time lag between entering the C-state limit setting and it being reflected.
[0030] <Task Management Department 120> The task management unit 120 includes a task priority assignment unit 121, a task volume / period prediction unit 122 (processor usage acquisition unit), and a task CPU allocation unit 123 (task allocation unit).
[0031] The task priority assignment unit 121 assigns a task priority to the tasks sent from APL1 as needed. The task management unit 120 then performs priority control for assigning tasks to CPU cores according to this priority.
[0032] Here, the most accurate representation of the CPU state is considered to be the "CPU utilization rate per unit time of the CPU cores being used." The "CPU utilization rate per unit time of the CPU cores being used" can be estimated almost entirely by the amount of tasks. While the amount of tasks can be used to estimate how busy the CPU is, 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 utilization rate per unit time of the CPU cores being used."
[0033] The task volume / period prediction unit 122 obtains the processor usage. Specifically, the task volume / period prediction unit 122 measures the task volume per unit time and CPU usage according to the decision logic shown in Figure 4, and determines whether it is necessary to increase or decrease the number of CPU cores used for calculations. The task volume / period prediction unit 122 pre-wakes the CPU core to be used. In many CPU products, the C-state returns to C0 once some processing is executed by the CPU core. Therefore, there is a method to execute small calculations or string output to standard output on the CPU core in question.
[0034] Based on the usage rate of the processor acquired by the task CPU allocation unit 123 (processor usage rate acquisition unit) for the task amount and period prediction unit 122, for the cores or core groups of the processor that are used at a predetermined frequency or higher, tasks are continuously allocated. The task CPU allocation unit 123, for example, reduces the CPU cores to be used. As a method of reducing CPU cores, determine the CPU cores that will not be used hereafter and prevent tasks from being allocated to the CPU cores hereafter. The task CPU allocation unit 123 allocates the arrived tasks to the CPU cores (the allocation to the CPU cores may be done by round-robin of the used CPU cores, or may be allocated to the CPU cores with fewer remaining tasks in the task queues prepared for each CPU core), and schedules the tasks in the task queues 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 rearranged according to the priority.
[0035] <CPU idle state control unit 130> The CPU idle state control unit 130 includes a CPU pre-wake-up unit 131 (pre-wake-up unit) and a C-state setting unit 132 (operation state setting unit). For a core that is newly used or a core that is reused after not being used for a predetermined period, the CPU pre-wake-up unit 131 performs a pre-wake-up operation to restore the operation state of the processor to the original state when allocating tasks (refer to reference c in FIG. 1).
[0036] For the cores or core groups of the processor that are used at a predetermined frequency or higher, the C-state setting unit 132 sets an upper limit so that the operation state of the processor cannot transition to a deeper state. Specifically, the C-state setting unit 132 inputs a C-state upper limit setting for the newly used CPU core. The upper limit state is determined by the operator's setting (refer to reference b in FIG. 1). Furthermore, if tasks are constantly flowing in and tasks can be continuously assigned, the active CPU cores will not transition to deep C-states, so it may not be necessary to set an upper limit.
[0037] Here, instead of pre-waking, you can set a C-state limit for the newly used CPU core before assigning a task, returning it to a shallower state. In this case, you should set the C-state limit in advance to account for the time lag between setting the C-state limit and its reflection. The C-state setting unit 132 removes the C-state limit setting if one is set for a CPU core that has been decided not to be used. The C-state setting unit 132 configures the cores or groups of cores that the task CPU allocation unit 123 (task allocation unit) did not assign tasks to, so that the operating state of the processor can transition to a deeper state.
[0038] [Placement of Task Scheduler Device] Figures 2 and 3 illustrate the arrangement of the task scheduler device 100 shown in Figure 1. • Placing the Task Scheduler device in user space Figure 2 shows an example configuration in which the task scheduler device 100 from Figure 1 is placed in user space. In the computing system 1000 shown in Figure 2, a task scheduler device 100 is located in User space 60. The computing system 1000 executes packet processing APL1 located in User space 60. The computing system 1000 executes packet processing APL1 on a server equipped with an OS.
[0039] The present invention can be applied when there are threads in user space 60, such as in the Intel DPDK (Intel Data Plane Development Kit) (DPDK) (registered trademark).
[0040] • Placement of the Task Scheduler device in the OS Figure 3 shows an example configuration in which the task scheduler device 100 from Figure 1 is placed on OS50. In the computing system 1000 shown in Figure 3, a task scheduler device 100 is deployed on the OS 50. The computing system 1000 executes packet processing APL1 on a server equipped with the OS 50.
[0041] The present invention can be applied to cases where there are threads within the kernel, such as New API (NAPI) (registered trademark) (Non-Patent Literature 1) and KBP (kernel-based virtual machine).
[0042] [Logic for estimating the required number of active CPU cores] This section explains the logic for estimating the required number of active CPU cores (see dashed box a in Figure 1). The inventors considered assigning tasks continuously to the active CPU cores, while transitioning the other CPU cores to a deep C-state to reduce power consumption. To achieve this, when managing the active CPU core group, it is necessary to calculate the required number of CPU cores based on the volume of incoming tasks, etc.
[0043] Figure 4 is a table illustrating the logic for estimating the required number of active CPU cores. As shown in Figure 4, the estimation logic decision consists of "1. Judgment based on task arrival patterns" and "2. Judgment based on CPU usage," which are determined by threshold judgment, periodicity, and machine learning, respectively. As shown in Figure 4, each decision logic is applicable to different tasks. Therefore, select and use the appropriate logic based on the applicability listed in the right column of the table in Figure 4. Alternatively, multiple decision logics may be used in combination.
[0044] The operation of the arithmetic system 1000, configured as described above, will be explained below. [Basic Concepts of Task Scheduler Device 100 Operation] In a computing system requiring real-time performance, the present invention provides a task scheduler that assigns tasks to CPU cores while considering the C-state state of the CPU cores when assigning tasks.
[0045] Features <1> :Continuing task assignment By securing frequently used CPU cores and continuously assigning tasks to them, transitions to deep C-states are prevented (Figures 5-7). As shown in the dashed box a of Figure 5, depending on the workload, the CPU cores that are frequently used (active CPU cores) are reserved using the decision logic shown in Figure 4, and tasks are continuously assigned to these CPU cores. This prevents transitions to deep C-states and reduces the delay in returning from C-states. CPU cores other than the active ones can transition to deep C-states, thus saving power.
[0046] Features <2> : C-state limit setting As a countermeasure for situations where tasks cannot be continuously assigned, an upper limit on the number of C-states that can be transitioned to is set for frequently used CPU cores (Figures 8-10). To address situations where tasks cannot be continuously assigned to active CPU cores, a limit is set on the number of C-states that can be transitioned to from the active CPU core group. This prevents transitions to deeper C-states and reduces recovery delays.
[0047] Features <3> : Wake up in advance By pre-waking up CPU cores that have transitioned to a deep state before assigning them tasks, the recovery time from the deep state is reduced (Figures 11-12). By pre-waking up newly used CPU cores (CPU cores that haven't been used for a while) before assigning tasks, the recovery time from deep C-states is reduced. Features <1> ,Features <2> ,Features <3> I will explain these in order.
[0048] [Task volume threshold determination and CPU usage threshold determination] (Features) <1> (Continuing task assignment) Figure 5 illustrates the task quantity threshold determination and CPU usage threshold determination operations of the task scheduler device 100.
[0049] <Task volume threshold determination operation> First, let's explain the task volume threshold determination process. The task management unit 120 performs a task volume threshold determination operation. As shown by the dashed arrow d in Figure 5, the task priority assignment unit 121 assigns a priority to a task as needed. The task volume / period prediction unit 122 measures the task volume per unit time and CPU usage rate according to the decision logic shown in Figure 4, and determines whether it is necessary to increase or decrease the number of CPU cores used for calculations.
[0050] Figure 6 shows an image illustrating the threshold determination process based on the amount of task inflow. The task management unit 120 manages CPU cores according to the task inflow volume shown in Figure 6. In Figure 6, the task inflow per unit time (W_input) is correlated with the number of CPU cores used. For example, if W_input is "dd~ee", the number of CPU cores used is "4", and the number of active CPU cores (see dashed box a in Figure 5) is "4".
[0051] Returning to Figure 5, the task CPU allocation unit 123 assigns the incoming tasks to CPU cores and schedules them in the task queue prepared for each CPU core. At this time, tasks with higher priority are preferentially assigned to available CPU cores according to their assigned priority. The task queue for each CPU core is also rearranged according to priority.
[0052] For tasks whose computing time is completed within a fixed time, the task management unit 120 designs the number of CPU cores required for computing the task inflow rate per unit time according to the threshold determination table in FIG. 6. 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 to be 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 computing time of a task is fixed (or has little variation), if the maximum allowable waiting time Tw for 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 consideration, but in this embodiment, if the return time from the C-state can be made as close to zero as possible, it becomes unnecessary to consider it.
[0054] · Example of calculating the required number of CPU cores λ [tasks / s]: Task inflow rate per unit time (W_input) μ [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 allowable waiting time for the service N [cores]: Number of CPU cores in use ρ = λ / μ: Degree of congestion
[0055] μ = N / t_s Ts = 1 / μ = t_s / N
[0056] Tw = (ρ / (1 - ρ)) * Ts …(1)
[0057] Substituting ρ and Ts into the above formula (1) results in formula (2). Tw = ((λ / μ) / (1 - (λ / μ)) ) *(t_s / N) …(2)
[0058] Substituting μ into the above formula (2) and solving it gives formula (3). N 2 -λ·t_s·N - λ·t_s 2 / Tw = 0 …(3) It is only necessary to find the smallest natural number that satisfies this equation.
[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 number of CPU cores to be used. Also, when the average CPU usage rate falls below the lower limit, the number of CPU cores to be used is decreased.
[0060] When the average CPU usage rate of the CPU cores in use exceeds Threshold_upper (upper limit), it indicates a sign that the number of CPU cores in use is insufficient, and it can be determined to increase the number of CPU cores newly. On the other hand, when the average CPU usage rate of the CPU cores in use is below Threshold_base (lower limit), it means that the CPU cores are excessive, and it can be determined to degenerate the CPU cores in use.
[0061] Here, when newly increasing the number of CPU cores as described above, since the CPU core is a CPU core that has not been used until now, it is assumed that it has dropped to a deep C-state. In particular, the method for calculating the recovery time when recovering 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 has described the task amount 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 there is a high possibility of task assignment, even if transitioning to a deep idle state, the residence period in the corresponding state is short and the power saving effect cannot be fully enjoyed. There may be a demerit that an overhead in the recovery time from the idle state occurs despite the inability to enjoy the power saving effect.
[0064] In this embodiment, to address this problem, for frequently used CPU cores, the upper limit of the CPU idle state that can be transitioned (for example, see C1, C1E, etc. in FIG. 22) is determined, and it is set so that a transition to a state deeper than the corresponding state is not possible. As a result, at the time of task assignment, a recovery from a shallow state can be made, and the recovery delay time can be reduced.
[0065] The number of CPU cores to be used can be determined by the decision logic shown in Figure 4, which determines which CPU cores will be used to set / release the CPU idle state limit. The C-state setting unit 132 dynamically sets the CPU idle state limit using the decision logic shown in Figure 4.
[0066] Also, when adding a new CPU core (after a long time), before assigning a task to the newly added CPU core, 、 You can also set a C-state limit and revert to a shallower C-state.
[0067] Figure 9 illustrates the C-state upper limit setting. The upper part of Figure 9 shows the case where no C-state upper limit is set, and the lower part of Figure 9 shows the case where a C-state upper limit is set. As shown in the upper part of Figure 9, if there is no C-state upper limit setting, the system will drop to the CPUidle state (grade C2), and the delay time until it returns to C0 will be prolonged. In contrast, as shown in the lower part of Figure 9, by setting a C-state upper limit for frequently used CPU cores (see symbol g in the lower part of Figure 9), transitions to deeper states are prevented, thereby reducing the recovery delay time when returning from a shallow state.
[0068] <Pooling of highly usable CPU cores> Next, we will discuss pooling of highly available CPU cores as an extension of the C-state limit setting. Figure 10 illustrates the pooling of highly available CPU cores in the task scheduler device 100. As shown in Figure 10, if future use is anticipated, a group of CPU cores (indicated by the dashed line h in Figure 10) configured to only fall into a shallow idle state may be prepared. For example, the CPU cores (CPUcore #4, CPUcore #5) 32 shown in Figure 10 can be pooled as a group of CPU cores that can only transition up to C1.
[0069] If it's possible to predict which CPU cores are likely to be used in the future based on task trends, such as handling nighttime / daytime traffic fluctuations, then the CPU cores most likely to be used (indicated by the dashed line h in Figure 10) should be configured to only transition to shallow idle states (e.g., up to C1). Then, an active-standby CPU core pool should be prepared so that it can be used immediately when needed. Thus, if future use is anticipated, a group of CPU cores configured to only fall into shallow idle states should be prepared (for example, a pool of CPU cores that can only transition up to C1). This concludes the explanation of setting the C-state limit.
[0070] [Wake up beforehand] (Features) <3> (Wake up beforehand) Figure 11 illustrates the pre-wake-up process of the task scheduler device 100. The CPU pre-wake unit 131 pre-wakes up CPU cores when using CPU cores that have fallen into a deep CPU idle state (C-state) (see symbol c in Figure 11).
[0071] Figure 12 illustrates the pre-wake-up of the task scheduler device 100. The upper part of Figure 12 shows the case of existing technology, while the lower part of Figure 12 shows the case where the task scheduler device 100 is pre-wake-up. As shown in the upper part of Figure 12, in the case of existing technology (without prior wake-up), there is a large delay between task assignment (symbol i in the upper part of Figure 12) and the start of computation (symbol j in the upper part of Figure 12). In contrast, as shown in the lower part of Figure 12, if there is pre-waking (indicated by c in the lower part of Figure 12), the delay from task assignment to the start of calculation becomes low (indicated by k in the lower part of Figure 12).
[0072] In this way, infrequently used CPU cores can be transitioned to deep C-states, reducing power consumption while simultaneously mitigating the impact of latency associated with returning from deep C-states.
[0073] [Operation flow of Task Scheduler device 100] Figure 13 is a flowchart showing the task scheduling process of the task scheduler device 100. In step S11, APL1 (Figure 1) registers a task with the task management unit 120 (Figure 1).
[0074] In step S12, the task priority assignment unit 121 (Figure 1) assigns a priority to the task as needed. The task CPU allocation unit 123 (Figure 1) then performs priority control for allocation to CPU cores according to this priority.
[0075] In step S13, the task volume / period prediction unit 122 (Figure 1) measures the task volume per unit time and CPU usage rate according to the decision logic shown in Figure 4, and determines whether it is necessary to increase or decrease the number of CPU cores used for calculations (the branching after the decision is shown in steps S14 and S15 below).
[0076] If it is necessary to reduce the number of CPU cores in step S14 (S14:Yes), proceed to step S17; otherwise, proceed to step S15.
[0077] If it is necessary to increase the number of CPU cores in step S15 (S15:Yes), proceed to step S19; otherwise, proceed to step S16.
[0078] In step S16, the task CPU allocation unit 123 (Figure 1) assigns the incoming tasks to CPU cores, schedules the tasks to the task queue prepared for each CPU core, and terminates the processing of this flow. Assignment to CPU cores can be done using a round-robin system with the CPU cores currently in use, or it can be assigned to the CPU core with the fewest remaining tasks in the task queue prepared for each CPU core.
[0079] Also, the task CPU allocation unit 123 (Fig. 1) may preferentially allocate tasks with higher priorities 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 above, in step S17, the task CPU allocation unit 123 (Fig. 1) reduces the CPU cores to be used. For example, as a method of reducing CPU cores, determine the CPU cores not to be used hereafter, and prevent tasks from being allocated to the corresponding CPU cores hereafter.
[0081] In step S18, when there is a C-state upper limit setting for the CPU core determined not to be used, the C-state setting unit 132 (Fig. 1) releases 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 above, in step S19, the task amount / cycle prediction unit 122 (Fig. 1) performs pre-wake-up for the newly used CPU cores. The reason for performing pre-wake-up for the newly used CPU cores is as follows. That is, for many CPU products, if any processing is executed on the CPU core, the C-state returns to C0. Therefore, by executing minor processing such as small calculations or outputting a string to standard output on the corresponding CPU core, it is possible to suppress the corresponding CPU core from transitioning to a deep C-state.
[0083] Here, instead of pre-wake-up, before allocating tasks to the newly used CPU cores, a C-state upper limit setting may be performed and the state may be returned to a shallow state as described in <C-state upper limit setting> (Fig. 8). 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 applies the C-state upper limit setting to the newly used CPU core and terminates the processing of this flow. The upper limit state is determined in advance by the operator.
[0085] Furthermore, if tasks are constantly flowing in and tasks can be continuously assigned, the active CPU cores will not transition to deep C-states, so it may not be necessary to set a C-state limit.
[0086] [Hardware configuration] The task scheduler devices 100 and 100A according to the above embodiment (Figures 1 and 10) are implemented by a computer 900 having a configuration such as that shown in Figure 14. Figure 14 is a hardware configuration diagram showing an example of a computer 900 that implements the functions of task scheduler devices 100 and 100A (Figures 1 and 10). 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.
[0087] The CPU 901 operates based on programs stored in the ROM 902 or HDD 904, and controls the various parts of the task scheduler devices 100 and 100A (Figures 1 and 10). 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.
[0088] The CPU 901 controls input devices 910, such as a mouse or keyboard, and output devices 911, such as a display, 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 also be used as a processor.
[0089] HDD904 stores programs executed by CPU901 and data used by those programs. Communication I / F906 receives data from other devices via a communication network (e.g., NW(Network)920) and outputs it to CPU901, and also transmits data generated by CPU901 to other devices via the communication network.
[0090] 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 can be 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.
[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 this embodiment, the CPU 901 of the computer 900 realizes the functions of the task scheduler devices 100 and 100A by executing the program loaded on the RAM 903. Also, the HDD 904 stores the data in the RAM 903. The CPU 901 reads and executes the program related to the target process from the recording medium 912. In addition, the CPU 901 may read the 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 space 60) As shown in FIG. 2, it can be applied to a configuration example in which the task scheduler device 100 is arranged in User space 60. 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> Based on 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 the operability by using it as needed like a component is becoming the mainstream.
[0094] A well-known technology for configuring virtual machines is a hypervisor environment composed of Linux (registered trademark) and KVM (kernel-based virtual machine). In this environment, a Host OS (an OS installed on a physical server) with the KVM module installed acts as a hypervisor, running in a memory area called kernel space, which is different from user space. In this environment, a virtual machine runs in user space, and a Guest OS (an OS installed on the virtual machine) runs within that virtual machine.
[0095] Unlike a physical server running a Host OS, a virtual machine running a Guest OS uses all hardware, including network devices (such as Ethernet® card devices), to control registers necessary for interrupt handling from the hardware to the Guest OS and for writing from the Guest OS to the hardware. In such register control, notifications and processes that should be performed by the physical hardware are simulated by software, so performance is generally lower than in a Host OS environment.
[0096] Figure 15 shows an example of applying the arithmetic system 1000A to the interrupt model in a server virtualization environment with a general-purpose Linux kernel (registered trademark) and VM configuration. The same reference numerals are used for components identical to those in Figure 1. As shown in Figure 15, the computing system 1000A includes a Host OS 80 on which virtual machines and external processes formed outside the virtual machine can run, and the Host OS 80 has a Kernel 81 and a Driver 82. The computing system 1000A also has a CPU 71 of HW 70 connected to the Host OS 80, and a KVM module 91 incorporated into the hypervisor (HV) 90. Furthermore, the computing system 1000A includes a Guest OS 95 that runs within a virtual machine, and the Guest OS 95 has 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 either the Host OS 80 or 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 of a container configuration. The same reference numerals are assigned to the same components as in FIGS. 1 and 15. As shown in FIG. 16, the arithmetic system 1000B has a container configuration in which the Guest OS 95 in FIG. 15 is replaced with a Container 98. The Container 98 has a vNIC (virtual NIC).
[0099] In a system of 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 in which the task scheduler device 100 is arranged in the user space 60 has been described. Next, the form in which the task scheduler device 100 is arranged in the kernel will be described.
[0100] (Form of arranging the 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. FIG 18 As shown in, 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 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 Operating Frequency Control> The present invention can also be applied to a mechanism that restores the frequency in advance before task allocation when the processor operating 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 put into the power-saving mode and are made ready in advance until they are pre-woken up and used.
[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 more 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, it is possible to prevent the transition to a deep C-state. 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] By allowing the CPU core to be reduced to a deep C-state, power savings can be maximized, while simultaneously avoiding the problem of the system taking a long time to recover from a deep C-state.
[0112] Furthermore, it becomes possible to dynamically increase or decrease the number of CPU cores used depending on the workload and CPU usage, enabling dynamic scaling in / out in response to the workload.
[0113] Furthermore, since it is possible to select multiple decision logics (Figure 4) that change the number of CPU cores used depending on the workload and CPU usage, it is possible to handle a wide variety of tasks.
[0114] Task scheduler devices 100 and 100A (Figures 1 and 10) are equipped with an operating state setting unit (C-state setting unit 132) that sets an upper limit to prevent the operating state of a processor from transitioning to a deeper state for processor cores or groups of cores that are used at a predetermined frequency or more.
[0115] In this way, by setting an upper limit on the CPU idle state that can be transitioned to for frequently used CPU cores, transitions to deep C-states are prevented, thereby reducing recovery delays. This suppresses the delay time from task assignment to the start of computation, enabling highly real-time computation.
[0116] In particular, this is an effective countermeasure when tasks cannot be continuously assigned to frequently used CPU cores.
[0117] Furthermore, by assigning priorities to tasks, it is possible to prioritize the tasks that you want to perform calculations on. Tasks that are prioritized for calculations may have certain quality of service (QoS) guarantees.
[0118] In the task scheduler devices 100 and 100A (Figures 1 and 10), the operating state setting unit (C-state setting unit 132) configures the cores or groups of cores to which the task assignment unit (task CPU assignment unit 123) did not assign a task, so that the operating state of the processor can transition to a deeper state.
[0119] By doing this, tasks are continuously assigned to the CPU cores that are frequently used (the active CPU cores), preventing transitions to deep C-states (reducing the delay in returning from C-states), while CPU cores other than the active ones can transition to deep C-states, thus saving power.
[0120] In the task scheduler devices 100 and 100A (Figures 1 and 10), a pre-wake-up unit (CPU pre-wake-up unit 131) is provided to perform a pre-wake-up that restores the operating state of the processor to its original state when assigning a task to a core that is newly to be used or a core that will be used again after not being used for a predetermined period of time.
[0121] The basic idea is that if it takes time for a task to be assigned and then for the system to finish processing and return to normal, the system should be woken up in advance for that amount of time before it can be used, and the CPU should be prepared beforehand. By doing this, the recovery time from a deep state can be reduced by pre-waking up CPU cores that have transitioned to a deep state before assigning them a task. Cores that are newly used, or cores that will be used again after a predetermined period of disuse, are expected to be in a deep C-state. By pre-waking them before assigning a task, the recovery time from a deep C-state can be reduced. For example, when increasing the number of CPU cores used, pre-waking the relevant CPU cores can suppress the delay time from task assignment to the start of computation, even if they have fallen into a deep CPU idle state, enabling computation with high real-time performance.
[0122] Furthermore, the computing system 1000 (Figures 1 and 10) reduces power consumption by gradually reducing the operating state of the processor according to the processing load, and the processor (CPU) has a plurality of core groups (CPU cores (CPUcore #0, CPUcore #1, ...) 32), and is equipped with task scheduler devices 100, 100A (Figures 1 and 10) that assign tasks to the core groups of the processor, and the task scheduler devices 100, 100A include a processor usage rate acquisition unit (task amount / period prediction unit 122) that acquires the usage rate of the processor, and a task assignment unit (task CPU assignment unit 123) that, based on the processor usage rate acquired by the processor usage rate acquisition unit, continuously assigns tasks to processor cores or core groups that are used at a predetermined frequency or more.
[0123] The computing systems 1000-1000D (Figures 1, 10, 15-18) are technologies that have been extended not only to packet arrival and processing tasks, but also to general tasks such as the calculation of pi. By continuously assigning tasks to frequently used CPU cores (active CPU cores) according to processor usage, it is possible to prevent transitions to deep C-states and reduce the delay in returning from the C-state. On the other hand, CPU cores other than the active ones can transition to deep C-states, thus saving power. In other words, pre-wake-up reduces the delay in returning from the C-state while maintaining the deepest possible LPI (C-state) for as long as possible, thus achieving both low latency and power saving.
[0124] The above processor can also be applied to other processors besides CPUs, such as GPUs, FPGAs, and ASICs, if they have an idle state function.
[0125] In the computing system 1000 (Figures 1 and 10), low latency and power saving can be achieved simultaneously. In particular, by continuously assigning tasks to frequently used CPU cores (active CPU cores), the problem of long latency occurring when CPU cores fall into a deep idle state and then recover can be avoided. This ensures low latency.
[0126] Furthermore, among the processes described in the above embodiments, all or part of the processes described as being performed automatically may be performed manually, or all or part of the processes described as being performed manually may 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 may be changed at will unless otherwise specified. Furthermore, the components of each illustrated device are functionally conceptual and do not necessarily need 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.
[0127] 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. The following additional information is disclosed regarding the embodiments described above. [Note] (Additional note 1) A task scheduler device having a processor capable of transitioning to multiple sleep states, and which assigns tasks to a group of cores of said processor, A usage rate acquisition unit that acquires the usage rate of the aforementioned processor, The system includes a task assignment unit which has a decision logic for determining an increase or decrease in the number of CPU cores used for calculations, and which, based on the decision logic, continuously assigns tasks to the cores or groups of cores of the processor whose processor utilization exceeds a threshold. A task scheduler device characterized by the following: (Additional note 2) A task scheduler device having a processor capable of transitioning to multiple sleep states, and which assigns tasks to a group of cores of said processor, A task quantity acquisition unit that acquires the amount of tasks per unit time, The system includes a task allocation unit which has a decision logic for determining an increase or decrease in the number of CPU cores used for calculations, and which, based on the decision logic, continuously allocates tasks to the processor cores or groups of cores whose task volume exceeds a threshold. A task scheduler device characterized by the following: (Additional note 3) Based on the judgment logic, the task assignment unit increases the number of CPU cores to use if the processor usage exceeds a preset threshold for the average usage of the cores being used. A task scheduler device as described in Appendix 1, characterized by the features described herein. (Additional note 4) Based on the judgment logic, the task allocation unit increases the number of CPU cores used if the amount of tasks exceeds a pre-set threshold for the amount of tasks on the cores being used. The task scheduler device according to Appendix 2, characterized by the features described herein. (Additional note 5) When the aforementioned decision logic determines to increase the number of CPU cores, the processor The system includes a pre-wake-up unit that changes the operating state from idle to active. A task scheduler device as described in appendix 3 or 4, characterized by the above. (Additional note 6) A computing system comprising a group of processors consisting of multiple processors, and a task scheduler device that assigns tasks to the core group of the processors, The processor has a function for transitioning between multiple sleep states, The processor's core group comprises a first processor group consisting of cores whose sleep state is controlled to prevent deep sleep, and a second processor group in which the sleep state of the processor transitions in stages according to the processing load. The task scheduler device, The system includes an operating state setting unit that assigns priorities to tasks and processes tasks that require priority calculation using the first group of processors. A computing system characterized by the following features. (Additional note 7) The task scheduler device, The system includes a decision logic that determines whether to increase or decrease the number of CPU cores used for calculations. If a decision is made to increase the number of CPU cores used for calculations, the system includes a pre-wake-up unit that pre-wakes the CPU cores of the processors in the second processor group and causes the pre-wake-up processors to perform the processing that would normally be done by the first processor group. The calculation system according to appendix 6, characterized in that (Additional note 8) The task scheduler device, If the decision logic for determining the number of CPU cores used for calculations determines that the number of CPU cores used for calculations should be increased, a setting to control the sleep state is applied to the processors in the second processor group, and those processors are added to the first processor group. The calculation system according to appendix 6, characterized in that (Additional note 9) A task scheduling method for a task scheduler device having a processor capable of transitioning to multiple sleep states, and assigning tasks to a group of cores of said processor, The task scheduler device, The steps include obtaining the processor usage rate, The system has a decision logic that determines whether to increase or decrease the number of CPU cores used for calculations, and based on this decision logic, it performs the step of continuously assigning tasks to the cores or groups of cores of the processor whose processor utilization exceeds a threshold. A task scheduling method characterized by the following: (Additional note 10) A task scheduling method for a task scheduler device having a processor capable of transitioning to multiple sleep states, and assigning tasks to a group of cores of said processor, The task scheduler device, Steps to obtain the amount of tasks per unit time, The system has a decision logic that determines whether to increase or decrease the number of CPU cores used for calculations, and based on this decision logic, it performs the step of continuously allocating tasks to the cores or groups of cores of the processor if the amount of tasks exceeds a threshold. A task scheduling method characterized by the following: (Additional note 11) A program for causing a computer to function as a task scheduler device as described in any one of the appendices 1 through 4. [Explanation of symbols]
[0128] 31 Hardware (HW) 32 CPU cores (processor) 1, 1-1, 1-2, 1-3 Application (APL) 100,100A Task Scheduler Device 110 Management Department 111 Operator Settings Section 120 Task Management Department 121 Task Priority Assignment Section 122 Task Volume / Cycle Prediction Unit (Processor Usage Acquisition Unit) 123 Task CPU allocation unit (Task allocation unit) ) 130 CPU idle state control unit 131 CPU pre-wake-up part (pre-wake-up part) 132 C-state setting section (operational state setting section) 1000, 1000A, 1000B, 1000C, 1000D Calculation System (Calculation System) CPUcore #0,CPUcore #1,… CPU core
Claims
1. A task scheduler device having a processor capable of transitioning to multiple sleep states, and which assigns tasks to a group of cores of said processor, A usage rate acquisition unit that acquires the usage rate of the aforementioned processor, The system includes a decision logic that determines whether to increase or decrease the number of CPU cores used for calculations, and a task assignment unit that, based on the decision logic, continuously assigns tasks to the cores or groups of cores of the processor whose processor utilization exceeds a threshold. A task scheduler device characterized by the following:
2. A task scheduler device having a processor capable of transitioning to multiple sleep states, and which assigns tasks to a group of cores of said processor, A task quantity acquisition unit that acquires the amount of tasks per unit time, The system includes a task allocation unit which has a decision logic for determining an increase or decrease in the number of CPU cores used for calculations, and which, based on the decision logic, continuously allocates tasks to the processor cores or groups of cores whose task volume exceeds a threshold. A task scheduler device characterized by the following:
3. Based on the judgment logic, the task assignment unit increases the number of CPU cores to use if the processor usage exceeds a preset threshold for the average usage of the cores being used. The task scheduler device according to claim 1.
4. Based on the judgment logic, the task allocation unit increases the number of CPU cores used if the amount of tasks exceeds a pre-set threshold for the amount of tasks on the cores being used. The task scheduler device according to claim 2.
5. When the aforementioned decision logic determines to increase the number of CPU cores, the processor The system includes a pre-wake-up unit that changes the operating state from idle to active. The task scheduler device according to claim 3 or 4, characterized by the above.
6. A task scheduling method for a task scheduler device having a processor capable of transitioning to multiple sleep states, and assigning tasks to a group of cores of said processor, The task scheduler device, The steps include obtaining the processor usage rate, The system has a decision logic that determines whether to increase or decrease the number of CPU cores used for calculations, and based on this decision logic, it performs the step of continuously assigning tasks to the cores or groups of cores of the processor whose processor utilization exceeds a threshold. A task scheduling method characterized by the following:
7. A task scheduling method for a task scheduler device having a processor capable of transitioning to multiple sleep states, and assigning tasks to a group of cores of said processor, The task scheduler device, Steps to obtain the amount of tasks per unit time, The system has a decision logic that determines whether to increase or decrease the number of CPU cores used for calculations, and based on this decision logic, it performs the step of continuously allocating tasks to the cores or groups of cores of the processor if the amount of tasks exceeds a threshold. A task scheduling method characterized by the following:
8. A program for causing a computer to function as a task scheduler device according to any one of claims 1 to 4.