Task scheduler device, task scheduling method, and program

Abstract

A task scheduler device (100, 100A, 100B) comprises: a task performance acquisition unit (110) that acquires characteristics of a task that is running; a task characteristic change monitoring unit (120) that acquires a performance index of each logical core from the task performance acquisition unit (110) and detects a change in the characteristics; each task characteristic recording unit (150) that, for each running task, records the characteristics of the task acquired by the task performance acquisition unit (110); and a core reallocation determination and allocation change unit (130) that determines core reallocation and changes allocation, on the basis of the characteristics of each running task recorded by each task characteristic recording unit (150) and the use state of physical cores.

Description

Task scheduler device, task scheduling method and program

[0001] The present invention relates to a task scheduler device, a task scheduling method, and a program.

[0002] vRAN (virtual radio access network) and AI (artificial intelligence) inference technologies make extensive use of CPU calculations. For example, applications that use the CPU for signal and media processing (e.g., vRAN L1 signal processing and deep-learning) often make extensive use of the CPU's SIMD (Single Instruction Multiple Data) instruction set extensions (e.g., Intel SSE / AVX512) ("Intel" is a registered trademark) for high-throughput calculations. SIMD instructions use hardware multithreading, which simulates a single physical core as multiple logical cores, to assign dedicated instruction execution processes to logical cores.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0022] [Task Processing with Real-Time Performance as a Requirement] In some computer systems, a processor on a computer (hereinafter referred to as a server) processes a task with a real-time performance as a requirement.

[0023] <Configuration and Prerequisites> 1. Server Machine (1) A server machine is equipped with a CPU. (2) The CPU has two or more physical cores. (3) The CPU supports hardware multithreading technology, which makes a single physical core appear as multiple logical cores, allowing multiple applications to run simultaneously. 2. Task (1) There are multiple types of tasks that run on a machine, and they have different requirements for processing load, CPU instructions used, and low latency performance. (2) The processing content of a task changes depending on the time and input.

[0024] <Requirements> ・Requirement 1: (Performance) Processing must be completed by the deadline required for each task. ・Requirement 2: (Efficiency of computing resource utilization) The number of execution cores required to execute each task must be minimized (highly efficient use of cores in an SMT environment must be possible). ・Requirement 3: (No need to understand task characteristics in advance) No need to analyze or understand the characteristics of each task in advance.

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

[0026] The Linux CFS (Completely Fair Scheduler) described in Non-Patent Document 1 is a core allocation technology that ensures fairness in the allocation of logical core time to each task, but does not take into account the type of instruction within the CPU. Therefore, if there is a bias in the arithmetic units used by tasks, contention within the CPU core (logical cores using the same set of arithmetic units) may occur, resulting in a decrease in performance.

[0027] The issues with existing technology will be explained in detail. FIG. 17 is a diagram illustrating a core allocation technology that ensures fairness in the allocation of time to each task among logical cores. Components identical to those in FIGS. 15 and 16 are designated by the same reference numerals. A CPU 1 (hardware) includes two physical cores 11 and 12. These physical cores 11 and 12 are single CPU cores that simultaneously execute two or more processes. The physical cores 11 and 12 each include a logical core 21 (logical core <1>) and a logical core 22 (logical core <2>) that execute two threads. Software applications include task 41 (task 1 (SIMD)) and task 42 (task 2 (SIMD / general-purpose changed)).

[0028] The in-kernel scheduler [CFS] has a fair time allocation function that allocates time to each task in a fair manner. In Figure 17, task 41 (task <1>) is SIMD (a task that executes SIMD instructions), but the SIMD instruction type is not taken into consideration and a fixed amount of CPU time is allocated to each process (symbol f in Figure 17). Task 42 (task <2>) is a task whose core allocation switches from SIMD instructions to general-purpose instructions (and vice versa), but the instruction type switch is not taken into consideration and a fixed amount of CPU time is allocated to each process (symbol g in Figure 17).

[0029] Fig. 18 is a diagram explaining contention within a CPU core (logical cores using the same group of arithmetic units) that occurs when fair time allocation is performed using CFS as shown in Fig. 17. The upper left diagram of Fig. 18 is a conceptual diagram showing timing without contention, and the upper right diagram of Fig. 18 is a conceptual diagram showing timing with contention.

[0030] <Contention-Free Timing> In the contention-free timing shown in the upper left of Figure 18, the software task <1> (SIMD) executes a SIMD instruction by the logical core 21 (logical core <1>) of the hardware (physical core 11) using the arithmetic unit group 51 (arithmetic unit group <1>) (symbol h in Figure 18). Furthermore, the software task <2> (general-purpose) executes a general-purpose instruction by the logical core 22 (logical core <2>) of the hardware (physical core 11) using the arithmetic unit group 52 (arithmetic unit group <2>) (symbol i in Figure 18). Because the arithmetic unit groups used by task <1> (SIMD) and task <2> (general-purpose) are different, namely, the arithmetic unit group <1> and the arithmetic unit group <2>, no contention occurs within the CPU core (logical cores using the same arithmetic unit group), as shown in the lower left of Figure 18 (symbol j in Figure 18).

[0031] <Timing with Contention> In the timing with contention shown in the upper right of Figure 18, for software task <1> (SIMD), the logical core 21 (logical core <1>) of the hardware (physical core 11) executes a SIMD instruction using the arithmetic unit group 51 (arithmetic unit group <1>), and the logical core 22 (logical core <2>) also executes a SIMD instruction using the arithmetic unit group 51 (arithmetic unit group <1>). SIMD instructions inherently have a small number of arithmetic units capable of executing them, resulting in a low degree of parallelism. Therefore, contention occurs in which the logical cores of logical core <1> and logical core <2> use the same arithmetic unit group 51 (arithmetic unit group <1>) (symbol k in Figure 18).

[0032] Since the group of arithmetic units used by task <1> (SIMD) and task <2> (SIMD) is biased toward group of arithmetic units <1> (symbol m in FIG. 18), contention occurs within the CPU core (symbol n in FIG. 18), as shown in the lower diagram of FIG. 18.

[0033] As mentioned above, CFS does not take into account the instruction types within the CPU, so if there is a bias in the computing units used by tasks, contention may occur within the CPU core, resulting in a decrease in performance. Therefore, while it satisfies requirement 3 (no need to understand the characteristics of tasks in advance), it has the issue of being unable to satisfy both requirement 1 (performance) and requirement 2 (computing resources). In other words, if two logical cores within the same physical core are used simultaneously to satisfy requirement 2 (computing resource utilization efficiency), contention may occur, making it impossible to satisfy requirement 1 (performance).

[0034] The present invention was made in light of this background, and its objective is to minimize the number of physical cores used for processing a group of tasks that have processing loads and low-latency performance requirements, while satisfying the low-latency requirements of each task.

[0035] In order to solve the above-mentioned problems, the present invention provides a task scheduler device comprising: a task performance acquisition unit that acquires the characteristics of a task currently being executed; a task characteristic change monitoring unit that periodically starts the task performance acquisition unit, acquires performance indicators of each logical core, and detects changes in the characteristics; a task characteristic recording unit that records the characteristics of each currently being executed task acquired by the task performance acquisition unit; and a core reallocation decision and allocation change unit that decides to reallocate cores and changes the allocation based on the characteristics of each currently being executed task recorded by the task characteristic recording unit and the usage status of physical cores.

[0036] According to the present invention, for a group of tasks having processing loads and low latency performance requirements, the number of physical cores used for processing can be minimized while satisfying the low latency requirements of each task.

[0037] 12 is a schematic configuration diagram of a computing system including a task scheduler device according to an embodiment of the present invention. FIG. 13 is a configuration diagram of a task scheduler device according to an embodiment of the present invention. FIG. 14 is a configuration diagram of arranging each functional unit of a task scheduler device according to an embodiment of the present invention in userland. FIG. 15 is a configuration diagram of arranging a task scheduler device according to an embodiment of the present invention in a VM / container. FIG. 16 is a diagram explaining a dynamic scheduler function to which a task scheduler device according to an embodiment of the present invention is applied. FIG. 17 is a schematic diagram showing dynamic core allocation change using a PMC of a task scheduler device according to an embodiment of the present invention. FIG. 18 is a conceptual diagram explaining dynamic analysis / core allocation control using a PMC of a task scheduler device according to an embodiment of the present invention in a contention-free timing. FIG. 19 is a diagram showing an example of a table recorded by each task characteristic recording unit of a task scheduler device according to an embodiment of the present invention. FIG. 19 is a flowchart showing the operation of each unit of a task scheduler device according to an embodiment of the present invention. FIG. 19 is a detailed flow chart of a task isolation / characteristic analysis unit of a task scheduler device according to an embodiment of the present invention. FIG. 19 is a hardware configuration diagram showing an example of a computer that realizes the functions of a task scheduler device of a computing system according to an embodiment of the present invention. FIG. 19 is a diagram showing the configuration of a CPU including a SIMD unit that executes microinstructions in a core. FIG. 19 is a diagram showing the configuration of a CPU when the microinstruction of FIG. 12 is a general-purpose instruction (Scalar). 17 is a diagram showing the configuration of a CPU when the microinstruction in FIG. 12 is a SIMD operation. 18 is a diagram showing the core allocation status. 19 is a diagram explaining an overview of CPU cores and in-core performance counters (PMU / PMC). 20 is a diagram explaining a core allocation technique that ensures fairness in the allocation time of logical cores to each task. 21 is a diagram explaining contention within a CPU core that occurs when fair time allocation is performed using CFS in FIG. 26.

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

[0039] The task execution request unit 102 requests task execution from the task scheduler device 100. The application command ratio management unit 103 manages application information and is called by the task scheduler device 100. The application information (e.g., vRAN task group) is, for example, as follows: Pre-Coding (Vector multiplication M-divide, Vector shift N-divide) Demap Logger process (general-purpose command 100%) QR-Decompression Phase Noise Estimation Eigen Beamforming Pre-Coding De-mapping

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

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

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

[0043] <PMC> The CPU has four to eight PMCs 31 per logical core. In Fig. 1, the CPU has four PMCs <1> to <4> per logical core. Items that the PMC 31 can acquire include core internal behavior (core operation bottleneck, memory access bottleneck, in-core instruction type utilization rate, etc.), CPU frequency, uncore frequency, etc.

[0044] <Management of Application Information> The task scheduler device 100 manages the type and frequency of commands of each application in a table (described later).

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

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

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

[0048] The task scheduler device 100 includes, in userland 70, a task performance acquisition unit 110, a task characteristic change monitoring unit 120, a core reallocation determination and allocation change unit 130, a task isolation and characteristic analysis unit 140, a task characteristic recording unit 150, and an in-core performance counter acquisition unit 160. The task scheduler device 100 also includes, as software located in the OS / driver / privileged area 60, an in-core performance counter 170 and a core allocation setting unit 180.

[0049] <CPU 50> The CPU 50 includes physical cores (physical core <1>, physical core <2>, physical core <3>) 11. The physical core 11 includes a logical core <1> and a logical core <2> that execute two threads for each physical core by using hyperthreading that makes one physical core appear as two.

[0050] <Task performance acquisition unit 110> The task performance acquisition unit 110 acquires the characteristics of a task that is currently being executed. Task characteristics include "processing volume," "location of bottlenecks," and "usage rates of various instructions" (examples of which are given in "each task characteristics recording unit 150"). One method for acquiring task characteristics is to use "intra-CPU performance counters using the in-core performance counter acquisition unit 160." In addition to the iostat command, which acquires the IO volume recorded by the OS, the perf command, which obtains various performance indicators, and the vmstat command, which obtains CPU usage, pre-recorded characteristics for each task may also be used in combination. Furthermore, the performance acquisition method and log output function of each task may also be used.

[0051] <Task characteristic change monitoring unit 120> The task characteristic change monitoring unit 120 acquires performance indicators of each logical core from the task performance acquisition unit 110 (for example, by periodically activating the task performance acquisition unit 110) and detects changes in characteristics. The timing / trigger for activating the task performance acquisition unit 110 may be a method of executing it at regular time intervals, a method of constantly monitoring the results of the various commands described in the task performance acquisition unit 110, or a method of detecting performance changes using an application log. When a change in characteristics is detected, the unit 120 selects one of the tasks to which the target logical core is assigned and notifies the task isolation / characteristics analysis unit 140, thereby performing re-analysis and core reallocation.

[0052] <Core Reallocation Decision and Allocation Change Unit 130> The core reallocation decision and allocation change unit 130 makes a decision to reallocate cores and change their allocations based on the characteristics of each running task recorded in the task characteristic recording unit 150 and the usage status of physical cores. The core reallocation decision and allocation change unit 130 acquires the usage status of each CPU core and then allocates tasks to cores in a combination that does not cause performance conflicts. An example of the logic for determining core allocation will be described later in the flowchart of FIG. 9. Note that multiple tasks may be assigned to a single logical core.

[0053] <Task Isolation and Characteristics Analysis Unit 140> The task isolation and characteristics analysis unit 140 is activated when a new task is started or by the task characteristics change monitoring function of the task characteristics change monitoring unit 120, executes the target task on an isolated core, and then acquires the characteristics of the target task using the task performance acquisition unit 110. Here, an isolated core is a core reserved in advance for characteristics analysis, and only the task to be isolated is executed on the physical core in question, and other tasks are not executed on the isolated core.

[0054] The task isolation and characteristics analysis unit 140 executes the target task on an isolated core, and after a certain period of time has passed, acquires the characteristics of the target task using the task performance acquisition unit 110. For this function, there are two methods for the isolated core: "allocating a dedicated core for analysis in advance," and "detecting a core on which no other tasks are running and temporarily using it when the task isolation and characteristics analysis unit 140 is started."

[0055] <Task characteristic recording unit 150> The task characteristic recording unit 150 records, for each task currently being executed, the characteristics (performance bottleneck locations and instruction utilization rates) acquired by the task performance acquisition unit 110. An example of the configuration of the table will be described later with reference to table 200 in FIG. 8.

[0056] <In-core performance counter acquisition unit 160> The in-core performance counter acquisition unit 160 accesses the performance counters of all logical cores installed in the processor and acquires the values ​​of the performance counters. Examples of performance counters include statistical values ​​of bottleneck locations (FrontEnd, memory, arithmetic cores) and utilization rates of arithmetic unit groups. In another embodiment, performance indicators may be acquired only for logical cores on which tasks are running. The in-core performance counter acquisition unit 160 accesses the in-core performance counters 170 to acquire performance indicators and record the acquired performance indicators in each task characteristics recording unit 150.

[0057] <In-core performance counter 170> The in-core performance counter 170 accepts requests to access a performance counter in the processor, accesses the in-core performance counter 170, and responds with the results. By providing a hardware-dependent access method according to the type of processor (e.g., Intel Xeon model number, ARM (Advanced RISC Machine) processor, etc.) and the differences in its performance counters, the hardware differences for access are hidden and abstracted. The in-core performance counter 170 may operate within the kernel or may be provided by a user space application.

[0058] <Core Allocation Setting Unit 180> For each task, the core allocation setting unit 180 sets one or more processor cores that can execute the task. For example, in Linux, the taskset command sets the processor cores that can execute each process. Furthermore, an application running in user space may have its own task allocation function to assign tasks to cores, without relying on the core allocation function of an OS such as Linux.

[0059] [Example 1 of application of task scheduler device] FIG. 2 shows an example in which the in-core performance counter 170 and the core allocation setting unit 180 of the task scheduler device 100 are included in software located in the OS / kernel / privileged area 60, but the task scheduler device 100 may also be one in which the core allocation setting unit 180 is located in userland 70.

[0060] 3 is a configuration diagram in which the functional units of the task scheduler device 100A are arranged in userland 70. Components that are the same as those in FIG. 2 are assigned the same reference numerals. The task scheduler device 100A includes a CPU 50, a physical core 11 (processor) on the CPU 50, a task performance acquisition unit 110, a task characteristic change monitoring unit 120, a core reallocation determination and allocation change unit 130, a task isolation and characteristic analysis unit 140, a task characteristic recording unit 150, an in-core performance counter acquisition unit 160, and a core allocation setting unit 180, all of which are arranged in userland 70, and an in-core performance counter 170 arranged in the OS / driver / privileged area 60.

[0061] [Application Example 2 of the Task Scheduler Apparatus: Application to VM Configuration] This section describes an application example of the task scheduler apparatus to a virtualized environment, such as a VM configuration. Against the backdrop of advances in virtualization technology such as network functions virtualization (NFV), systems are being built and operated for each service. Furthermore, instead of building systems for each service, a form known as service function chaining (SFC) is becoming mainstream. This form divides service functions into reusable modules and runs them in independent virtual machine (VM: Virtual Machine, container, etc.) environments, allowing them to be used as components when needed, improving operability.

[0062] FIG. 4 is a configuration diagram illustrating a task scheduler device 100B with a VM / container arrangement. Components identical to those in FIG. 2 are designated by the same reference numerals. The task scheduler device 100B includes a CPU 50, physical cores (physical core <1>, physical core <2>, physical core <3>) 11 (processor) on the CPU 50, a virtual machine monitor (VMM) 80 on the OS / privileged / VM, and a container / VM 90. The OS / privileged / VMM 80 virtualizes a computer and allows multiple different OSs to run in parallel without interfering with each other. The container / VM 90 creates a virtual machine (VM) that behaves like a physical computer to software, allowing various types of OSs to run on it.

[0063] The task scheduler device 100B includes, in the OS / privilege / VMM 80, a task performance acquisition unit 110, a task characteristic change monitoring unit 120, a core reallocation judgment / allocation change unit 130, a task isolation / characteristic analysis unit 140, a task characteristic recording unit 150, an in-core performance counter acquisition unit 160, an in-core performance counter 170, and a core allocation setting unit 180.

[0064] The container / VM 90 includes a container / VM 91 (container / VM-1), a container / VM 92 (container / VM-2), and a container / VM 93 (container / VM-3).

[0065] When using virtual machines (VMs) or containers, in order to allocate cores across containers / VMs, the core allocation function is aggregated outside each container / VM instance, such as the OS / privilege / VMM 80, to enable allocation processing across containers / VMs. In this case, only the function for acquiring the dedicated instruction ratio of each process is placed within each container / VM.

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

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

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

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

[0070] <Dynamic core allocation change using PMC> Tasks that use specific groups of processors, such as signal processing that makes heavy use of SIMD instructions, experience performance degradation due to contention within the CPU when instructions are executed (port contention). Existing technology required prior trend analysis of each task to avoid this contention. Furthermore, existing technology cannot keep up with tasks whose instruction usage trends and bottleneck locations change dynamically.

[0071] Therefore, in this embodiment, in addition to the dynamic scheduler function of "dynamic analysis and core allocation using PMC" shown in Fig. 5, "dynamic core allocation change using PMC" described later is performed. "Dynamic core allocation change using PMC" avoids intra-CPU contention without prior analysis by dynamically changing core allocation based on an intra-CPU performance counter (PMC) index used for performance tuning.

[0072] Fig. 6 is a schematic diagram showing dynamic core allocation change using the PMC of the task scheduler device 100. The same components as those in Fig. 1 and Fig. 5 are assigned the same reference numerals. As shown in Fig. 6, a server 101 constituting a computing system includes the task scheduler device 100. The task scheduler device 100 allocates cores based on the instruction utilization rate and bottleneck location (CPU or memory) of each task, which are dynamically acquired from a counter in the CPU.

[0073] Specifically, the task scheduler device 100 includes a core reallocation determination and allocation change unit 130 that determines whether to reallocate cores and changes the allocation based on the characteristics of each running task and the usage status of the physical cores, and an in-core performance counter acquisition unit 160 that accesses the performance counters of all logical cores installed in the processor and acquires the values ​​of the performance counters.

[0074] The in-core performance counter acquisition unit 160 is an in-core counter monitoring function that monitors the port utilization rate and task utilization of each core, and executes reallocation if a bottleneck becomes apparent.

[0075] The core reallocation determination and allocation change unit 130 is a function for determining the degree of contention between tasks in real time, and performs contention-free core allocation based on the intra-CPU port utilization rate of each task and the location of the bottleneck, thereby realizing contention-free intra-core coexistence.

[0076] The task scheduler device 100 changes the core allocation to avoid intra-core contention when intra-core contention is expected. That is, by combining the dynamic analysis and core allocation control using the PMC of FIG. 6 with the dynamic scheduler function of FIG. 5 , for example, when task 42 (task 2 (SIMD / general-purpose change)) changes, the core allocation of task 2 (SIMD / general-purpose change) is changed from logical core 1 ("front core") of the same physical core 12 to logical core 2 ("back core") of the same physical core 11 (dashed arrow ff in FIG. 6 ). As a result, as shown by the double dashed line in FIG. 6 , when intra-core contention is expected, the core allocation is changed to avoid contention.

[0077] The task scheduler device 100 has the advantage of eliminating the need for prior task characteristic analysis, i.e., eliminating the need for prior measures. Furthermore, the task scheduler device 100 can respond to changes in task characteristics, and can track and optimize even when the task characteristics change dynamically. The above advantages will be described with reference to FIG. 7.

[0078] Figure 7 is a conceptual diagram illustrating dynamic analysis and core allocation control using a PMC in a contention-free environment. Components identical to those in the upper left diagram of Figure 18 are designated by the same reference numerals. As shown in Figure 7, software task <1> (SIMD) is executed by the logical core 21 (logical core <1>) of the hardware (physical core 11) using the arithmetic unit group 51 (arithmetic unit group <1>) to execute SIMD instructions (reference numeral gg in Figure 7). Software task <2> (general-purpose) is executed by the logical core 22 (logical core <2>) of the hardware (physical core 11) using the arithmetic unit group 52 (arithmetic unit group <2>) to execute general-purpose instructions (reference numeral hh in Figure 7).

[0079] Because the arithmetic unit groups used by task <1> (SIMD) and task <2> (general-purpose) are different, arithmetic unit group <1> and arithmetic unit group <2>, conflicts within the CPU core (logical cores using the same arithmetic unit group) do not occur, as shown in the lower diagram of Figure 7 (symbol kk in Figure 7). As shown in the dotted-line box rr in Figure 7, even if there is a trend change such as allocating logical task <1> from SIMD task <1> to general-purpose task <3>, there is an effect (Effect 1) that no prior action is required. Furthermore, as shown in the dotted-line box ss in Figure 7, there is an effect (Effect 2) that intra-CPU conflicts can be avoided even if there is a trend change in tasks.

[0080] [Flowchart of the Task Scheduler Apparatus] Figure 8 is a diagram showing an example of a table recorded by each task property recording unit 150 of the task scheduler apparatus 100. Each task property recording unit 150 (Figures 2 and 3) records the properties (performance bottleneck locations and instruction utilization rates) acquired by the task performance acquisition unit 110 for each task currently being executed. Table 200 shown in Figure 8 records, for each process ID, the executable file name, CPU core performance bottleneck rate, memory / IO performance bottleneck rate, in-core arithmetic unit port 1 and 5 utilization rate (ports used by extended instructions), in-core arithmetic unit port 2 utilization rate, in-core arithmetic unit port 3 utilization rate, and in-core arithmetic unit port 6 utilization rate.

[0081] The CPU core performance bottleneck rate and memory / IO performance bottleneck rate are combined to form a total of 100%, and a determination is made as to which bottleneck location will cause a problem. For example, in the task processing of process IDs "1," "2," and "3," the CPU core performance bottleneck rate is 80% and the memory / IO performance bottleneck rate is 20%, indicating that CPU core performance is the bottleneck. In addition, in the task processing of process ID "4," the CPU core performance bottleneck rate is 10% and the memory / IO performance bottleneck rate is 90%, indicating that memory / IO performance is the significant bottleneck. In the task processing of process ID "5," the CPU core performance bottleneck rate is 30% and the memory / IO performance bottleneck rate is 70%, indicating that memory / IO performance is the bottleneck, although not as severe as in the task processing of process ID "4."

[0082] The utilization rates of in-core arithmetic unit ports 1 and 5 (ports used by extended instructions), in-core arithmetic unit port 2, in-core arithmetic unit port 3, and in-core arithmetic unit port 6 are used to determine whether a task requires consideration of core computation, such as SIMD specialization. For example, in the task processing of process IDs "2" and "3," the utilization rate of in-core arithmetic unit ports 1 and 5 (ports used by extended instructions) is 80%, which indicates that the task is a SIMD instruction. On the other hand, in the task processing of process IDs "4" and "5," there is no difference in the utilization rates of the in-core arithmetic unit ports, which indicates that the task is not a SIMD instruction. Furthermore, in the task processing of process ID "1," the utilization rate of in-core arithmetic unit ports 1 and 5 (ports used by extended instructions) is 10%, and there is no difference in the utilization rates of the other in-core arithmetic unit ports, which indicates that the task is a general-purpose computation task.

[0083] The CPU core performance bottleneck rate and memory / IO performance bottleneck rate are used in [Decision 1] in the flowchart of Fig. 9. The in-core arithmetic unit port 1 and 5 utilization rates (ports used by user extended instructions), in-core arithmetic unit port 2 utilization rate, in-core arithmetic unit port 3 utilization rate, and in-core arithmetic unit port 6 utilization rate are used in [Decision 2] in the flowchart of Fig. 9.

[0084] 9 is a flowchart showing the operation of each unit of the task scheduler device 100. This program starts periodically, and in step S101, the task characteristic change monitoring unit 120 periodically starts the task performance acquisition unit 110, acquires the performance index of each logical core, and detects changes in the characteristics.

[0085] The task property change monitoring unit 120 determines whether a property change of the target task has been detected. If a property change of the target task has been detected (step S101: Yes), the process proceeds to step S103, and returns to step S101 until a property change of the target task is detected (step S101: No).

[0086] Step S103 is initiated when a new task is started, as well as periodically. In step S103, the task isolation and characteristic analysis unit 140 is initiated when a new task is started or by the task characteristic change monitoring unit 120, executes the target task on an isolated core, and then acquires the characteristics of the target task being executed from the task performance acquisition unit 110.

[0087] In step S103, the task isolation and characteristic analysis unit 140 determines whether the time until the performance characteristics stabilize has passed. If the time until the performance characteristics stabilize has passed (step S104: Yes), the process proceeds to step S105. On the other hand, the process waits in step S104 until the performance characteristics stabilize (step S104: No).

[0088] In step S105, the task performance acquisition unit 110 acquires the characteristics of the task currently being executed.

[0089] In step S106, the intra-core performance counter acquisition unit 160 accesses the performance counters of all logical cores installed in the processor and acquires the values ​​of the performance counters.

[0090] Steps S107 to S112 are allocation change processing steps in the core reallocation determination and allocation change unit 130. In step S107, the core reallocation determination and allocation change unit 130 acquires the usage status of each core of the CPU.

[0091] In step S108, the core reallocation determination and allocation change unit 130 refers to the table 200 in FIG. 8 and determines, as [Determination 1], whether the performance bottleneck of the target task is IO (memory or IO).

[0092] If the performance bottleneck of the target task is IO (memory or IO) (step S108: Yes), in step S109, the core reallocation judgment / allocation change unit 130 allocates the task so that it is accommodated in the same physical core as the task with the core computation bottleneck, and ends the processing of this flow.

[0093] If the performance bottleneck of the target task is not IO (memory or IO) (step S108: No), in step S110, the core reallocation judgment / allocation change unit 130 refers to the table in FIG. 8 and determines (determination 2) whether there is a bias in the port utilization rate used by the target task.

[0094] If there is a bias in the port utilization rate used by the target task (step S110: Yes), it is determined that the task is SIMD specialization or other tasks that require consideration for core calculations, and in step S111 the core reallocation judgment / allocation change unit 130 allocates the task to the same physical core as the general-purpose calculation task or the memory-bottleneck task, and ends the processing of this flow.

[0095] If there is no bias in the port utilization rate used by the target task (step S110: No), the target task is determined to be a general-purpose computing task, and in step S112 the core reallocation judgment / allocation change unit 130 allocates the target task to the same physical core as the SIMD-specialized task or the memory-bottleneck task, and ends the processing of this flow.

[0096] 10 shows a detailed flow of the task isolation / characteristics analysis unit 140 of the task scheduler apparatus 100 of FIG. 9. The process starts with a subroutine call in step S101 of FIG. 9. In step S201, the task isolation / characteristics analysis unit 140 references the table shown in FIG. 8 and determines, as "Decision 1," whether an isolation core is available. Here, the isolation core is the isolation / measurement physical core 11 (physical core <1>) in FIG. 2. If the isolation core (the isolation / measurement physical core 11 (physical core <1>) in FIG. 2) is available (step S201: Yes), the process proceeds to step S204.

[0097] If the isolation core (the physical core for isolation and measurement 11 (physical core <1>) in FIG. 2) is not available (step S201: No), in step S202, physical cores <2> and <3> (FIG. 2) are started and assigned logical cores. In step S203, the task isolation and characteristic analysis unit 140 again refers to the table shown in FIG. 8 to determine whether the isolation core is available (Decision 1).

[0098] If the isolation core is free (step S203: Yes), the process proceeds to step S204, and if the isolation core is not free (step S203: No), the process waits until the isolation core becomes free.

[0099] In step S204, the task isolation and characteristic analysis unit 140 assigns the newly started process to run on core <1> using a taskset command or the like, and then returns to step S101 in FIG.

[0100] [Hardware Configuration] The task scheduler apparatus 100, 100A (FIGS. 2 and 3) according to the above-described embodiment is realized by, for example, a computer 900 configured as shown in FIG. 11. FIG. 11 is a hardware configuration diagram showing an example of the computer 900 that realizes the functions of the task scheduler apparatus 100, 100A (FIGS. 2 and 3). The computer 900 has a CPU 901, a ROM 902, a RAM 903, a HDD 904, a communication interface (I / F) 906, an input / output interface (I / F) 905, and a media interface (I / F) 907.

[0101] The CPU 901 operates based on programs stored in the ROM 902 or the HDD 904, and controls each unit of the task scheduler apparatus 100, 100A (FIGS. 2 and 3). The ROM 902 stores a boot program executed by the CPU 901 when the computer 900 starts up, programs that depend on the hardware of the computer 900, and the like.

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

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

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

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

[0106] [Effects] As described above, the task scheduler devices 100, 100A, 100B (FIGS. 2, 3, and 4) include a task performance acquisition unit 110 that acquires the characteristics of a task currently being executed, a task characteristic change monitoring unit 120 that acquires performance indicators of each logical core from the task performance acquisition unit 110 (for example, by periodically starting the task performance acquisition unit 110) and detects changes in the characteristics, a task characteristic recording unit 150 that records the task characteristics (performance bottleneck locations and instruction utilization rates) acquired by the task performance acquisition unit 110 for each currently being executed task, and a core reallocation determination and allocation change unit 130 that determines whether to reallocate cores and changes the allocation based on the characteristics of each currently being executed task recorded by the task characteristic recording unit 150 and the usage status of the physical cores.

[0107] In this way, the task scheduler devices 100, 100A, and 100B eliminate the need for prior task analysis by having the task performance acquisition unit 110 dynamically collect performance indicators for each logical core in real time, thereby satisfying Requirement 3 (no prior understanding of task characteristics). Furthermore, the task scheduler devices 100, 100A, and 100B satisfy Requirement 1 (performance) and Requirement 2 (core utilization efficiency) by having the core reallocation determination and allocation change unit 130 determine core reallocation based on the characteristics of each running task and the usage status of physical cores, and allocate cores to avoid conflicts between tasks. For example, the task scheduler devices 100, 100A, and 100B monitor the port utilization rate and task utilization rate of each core and perform reallocation if a bottleneck becomes apparent. Then, conflict-free core allocation based on the intra-CPU port utilization rate of each task and the location of the bottleneck achieves conflict-free intra-core coexistence.

[0108] The requirements to be met can be summarized as follows: Requirement 1: [Performance] Processing must be completed by the required processing deadline for each task Requirement 2: [Utilization efficiency of computing resources] The number of execution cores required to execute each task must be minimized (highly efficient use of cores in an SMT environment must be possible) Requirement 3: [No need to understand task characteristics in advance] No need to analyze or understand the characteristics of each task in advance Task scheduler devices 100, 100A, 100B can meet requirements 1, 2, and 3 above.

[0109] In this way, the task scheduler apparatuses 100, 100A, and 100B do not need to perform trend analysis of each task in advance, and can keep track of tasks with dynamically changing instruction usage trends and bottleneck locations. As a result, the task scheduler apparatuses 100, 100A, and 100B can minimize the number of physical cores used for processing a group of tasks with various processing loads and low-latency performance requirements executed on a server, while satisfying the low-latency requirements of each task.

[0110] In the task scheduler devices 100, 100A, and 100B (FIGS. 2, 3, and 4), the task performance acquisition unit 110 acquires task processing volume, the location of bottlenecks, or the utilization rates of various commands as task characteristics.

[0111] By doing this, the task scheduler devices 100, 100A, and 100B can dynamically acquire the task processing volume, the location of bottlenecks, or the utilization rates of various commands as task characteristics, thereby being able to keep up with tasks whose command utilization trends and bottleneck locations change dynamically.

[0112] For example, the task scheduler devices 100, 100A, and 100B can determine whether the performance bottleneck of a target task is IO (memory or IO) ([Decision 1] in FIG. 9 ) or whether there is a bias in the port utilization rate used by the target task ([Decision 2] in FIG. 9 ). Based on this determination ([Decision 1] [Decision 2]), for example, a memory-bottleneck task is assigned to the same physical core as a core-computing-bottle task. If there is a bias in the port utilization rate used by the target task, the task is assigned to the same physical core as a general-purpose computing task or a memory-bottle task. If there is no bias in the port utilization rate, the task is assigned to the same physical core as a SIMD-specialized task or a memory-bottle task. This dynamically changes core allocation, avoiding intra-CPU contention without prior analysis.

[0113] The task scheduler devices 100, 100A, 100B (FIGS. 2, 3, 4) include an in-core performance counter acquisition unit 160 that accesses the performance counter of a logical core mounted in the processor and acquires the value of the performance counter.

[0114] By doing this, the task scheduler devices 100, 100A, and 100B can avoid intra-CPU contention without prior analysis by dynamically changing core allocation based on intra-CPU performance counter (PMC) indicators used for performance tuning.

[0115] The task scheduler devices 100, 100A, and 100B (FIGS. 2, 3, and 4) include a task isolation and characteristic analysis unit 140 that is activated when a task is newly started or by a task characteristic change monitoring unit 120, executes the target task on an isolated core reserved in advance for characteristic analysis, and then acquires the characteristics of the target task being executed from the task performance acquisition unit 110.

[0116] In this way, the task scheduler devices 100, 100A, and 100B can acquire accurate characteristics of a target task by executing the task on an isolated core and then acquiring the characteristics of the target task being executed from the task performance acquisition unit 110. For example, when a new task is started or the characteristics change, the execution core of the target task is isolated and the characteristics are measured using a performance counter, thereby enabling highly accurate task characteristics to be grasped.

[0117] In the task scheduler devices 100, 100A, and 100B (Figures 2, 3, and 4), the task isolation and characteristic analysis unit 140 is characterized in that only tasks to be isolated are executed on physical cores reserved as isolated cores, and other tasks are not executed.

[0118] In this way, the task scheduler devices 100, 100A, and 100B use isolated cores reserved in advance for characteristic analysis, and execute only the tasks to be isolated on the corresponding physical cores, and do not execute other tasks. Because only the tasks to be isolated are executed, it is possible to acquire accurate characteristics of the target tasks.

[0119] In the task scheduler devices 100, 100A, and 100B (Figures 2, 3, and 4), the task isolation and characteristic analysis unit 140 executes the target task on an isolated core, and after a certain period of time has passed, acquires the characteristics of the target task being executed from the task performance acquisition unit 110.

[0120] By doing this, the task scheduler devices 100, 100A, and 100B run on isolated cores and, after a certain period of time, acquire the characteristics of the target task being executed from the task performance acquisition unit 110. This makes it possible to suppress fluctuations in the target task caused by transient (transit) factors from the control system, and to acquire the characteristics of the target task with high accuracy.

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

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

[0123] 11, 12 Physical core (processor) 21, 22 Logical core 30 PMU In-core performance counter (processor performance counter) 31 PMC CPU performance counter (processor performance counter) 50 CPU 60 OS / driver / privileged area 70 Userland 100, 100A, 100B Task scheduler device 101 Server 110 Task performance acquisition unit 120 Task characteristic change monitoring unit 130 Core reallocation judgment / allocation change unit 140 Task isolation / characteristic analysis unit 150 Each task characteristic recording unit 160 In-core performance counter acquisition unit 170 In-core performance counter 180 Core allocation setting unit 200 Table 1000 Computing system

Claims

1. A task scheduler device comprising: a task performance acquisition unit that acquires the characteristics of a task currently being executed; a task characteristic change monitoring unit that acquires performance indicators of each logical core from the task performance acquisition unit and detects changes in characteristics; a task characteristic recording unit that records the task characteristics acquired by the task performance acquisition unit for each currently being executed task; and a core reallocation decision and allocation change unit that decides to reallocate cores and changes the allocation based on the characteristics of each currently being executed task recorded by the task characteristic recording unit and the usage status of physical cores.

2. The task scheduler device according to claim 1, wherein the task performance acquisition unit acquires task processing volume, location of bottlenecks, or utilization rates of various commands as task characteristics.

3. The task scheduler device according to claim 1, further comprising an in-core performance counter acquisition unit that accesses a performance counter of a logical core mounted in the processor and acquires the value of the performance counter.

4. The task scheduler device according to claim 1, further comprising a task isolation and characteristics analysis unit that is activated when a task is newly started or by the task characteristics change monitoring unit, executes the target task on an isolated core reserved in advance for characteristics analysis, and then acquires the characteristics of the target task being executed from the task performance acquisition unit.

5. The task scheduler device according to claim 4, characterized in that the task isolation / characteristics analysis unit executes only the tasks to be isolated on the physical core reserved as the isolated core, and does not execute other tasks.

6. The task scheduler device according to claim 4, characterized in that the task isolation / characteristics analysis unit executes the target task on an isolated core, and after a certain period of time has elapsed, acquires the characteristics of the target task being executed from the task performance acquisition unit.

7. A task scheduling method for a task scheduler device, wherein the task scheduler device executes the following steps: a task performance acquisition step of acquiring the characteristics of a task currently being executed; a task characteristic change monitoring step of acquiring performance indicators of each logical core from the task performance acquisition step and detecting changes in the characteristics; a task characteristic recording step of recording the task characteristics acquired in the task performance acquisition step for each currently being executed task; and a step of determining whether to reallocate cores and changing the allocation based on the characteristics of each currently being executed task recorded in the task characteristic recording step and the usage status of physical cores.

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

Images