Computer system, task scheduler device, pending process awakening method, and program

Abstract

The present invention is a computer system (1000) which has a processor composed of a plurality of cores and in which processes each operate for executing a prescribed command using a time period on the processor. The processes includes: a standby process (101) that is in a standby state until there is a notification and awakens when there is a notification and restarts the operation; and a notification process (90) that transmits a notification for causing awakening from the standby process at an event generation time, wherein the standby process (101) comprises a pseudo idle task (103) that continues to exclusively occupy the processor while in the standby state.

Description

Computer system, task scheduler device, method and program for waking up waiting processes

[0001] The present invention relates to a computer system, a task scheduler device, a method for waking up a waiting process, and a program.

[0002] In a computer system, a general-purpose processor (CPU) is installed on a computer (hereinafter referred to as a server), and when a process running on the CPU does not need to be running all the time, the process is stopped, and when necessary, a notification is sent from another process to return the process to an operating state.

[0003] Figure 19 shows inter-process communication within a server using the polling method. As shown in Figure 19, an application (hereinafter referred to as "APL") [A: waiting side] 1 requests APL [B: notifying side] 1 to process a task (S1). APL [A: waiting side] 1 then requests the processing results by polling (S2). APL [B: notifying side] 1 executes the task processing requested by APL [A: waiting side] 1 (S3).

[0004] When the requested task processing is completed, APL[B: notifying side] 1 responds to the polling request and sends the processing result to APL[A: waiting side] 1 (S4). APL[A: waiting side] 1 executes the next process (S5).

[0005] Figure 20 shows inter-process communication within a server using the notification method. The same steps as in Figure 19 are assigned the same step numbers. As shown in Figure 20, APL[A: waiting side]1 requests APL[B: notifying side]1 to process a task (S1). APL[A: waiting side]1 performs sleep control and enters a sleep state (S6).

[0006] The APL[B: notifying side] 1 executes the task processing requested by the APL[A: waiting side] 1 (S3). When the APL[B: notifying side] 1 completes the requested task processing, it notifies the APL[A: waiting side] 1 of the completion of the processing (S7).

[0007] APL[A: waiting side]1 receives a processing completion notification from APL[B: notifying side]1 (S7), wakes up from sleep state, and requests the processing result from APL[B: notifying side]1 (S8). APL[B: notifying side]1 receives a result request from APL[A: waiting side]1 and sends the processing result to APL[A: waiting side]1 (S4). APL[A: waiting side]1 executes the next process (S5).

[0008] In the polling method of FIG. 19, for example, a process A requests another process B to process a task, and polls to see if the task processing in process B is complete until it is completed. Process A is in an active state, which increases power consumption. In the notification method of FIG. 20, sleep control is used in which process A enters a sleep state after requesting task processing from process B. Since process A enters a sleep state, power consumption can be reduced. When process A enters a sleep state, process B notifies process A that the processing is complete, and upon receiving the notification, process A wakes up from sleep and requests the task from process B after processing is completed. However, since process A wakes up from sleep, a delay time occurs for it to return.

[0009] To quickly send such notifications between processes on the same server, it is common to send notifications via shared resources such as file descriptors. However, because the process is managed by the OS scheduler or governor until it returns from a stopped state, there is a possibility of unexpected delays for the user.

[0010] An existing technology is a notification mechanism that uses the function "eventfd+epoll_wait" in the Linux OS (registered trademark). FIG. 21 is a diagram showing a notification system that uses eventfd+epoll_wait. As shown in FIG. 21, a server has hardware (HW) 10, an OS 20, and, in user space, a standby process [core #n] 30 and a notification process [core #m] 32. In FIG. 20, the standby process [core #n] 30 is "process A" of APL [A: waiting side] 1, and the notification process [core #m] 32 is "process B" of APL [B: notifying side] 1.

[0011] The hardware (HW) 10 includes a CPU 11. A standby process [core #n] 30 includes a standby function 31. The OS 20 includes an event monitoring instance 21 and a notification file descriptor (FD) 22. The notification FD 22 is an integer value that specifies a file when requesting access to the OS 20. When a file is operated from a program, the FD 22 is assigned to identify the file to be operated (hereinafter, "." represents "and").

[0012] In the existing technology, notification and wake-up are performed in the flow of steps 1 to 9 in Figure 21. 1. The standby process 30 ("Process A") creates an event monitoring instance 21 (eventpoll). 2. The standby process 30 creates a notification FD 22 (eventfd), which is an FD to be used for notification, and registers it in the event monitoring instance 21 described in step 1 above. 3. The standby process 30 transfers the notification FD 22 to the notification process 32 ("Process B"). This results in an agreement between the standby process 30 ("Process A") and the notification process 32 ("Process B") to use this notification FD 22.

[0013] 4. The wait process 30 issues the wait function 31 (epoll_wait) specifying the event monitoring instance 21 described above in 1, and enters a blocking (sleep) state. When the wait function 31 (epoll_wait) is issued, the wait process 30 enters a sleep state until an event is issued. The wait process 30 itself enters a sleep state, but if there are no other processes running on the CPU core in question, i.e., if the state corresponds to an idle state, an idle task appears when the wait process 30 enters sleep. This idle task appears automatically when the CPU core is not doing anything but there are no processes.

[0014] 5. <Event Occurrence> 6. The notification process 32 detects the occurrence of an event and writes it to the notification FD 22. 7. When writing to the notification FD 22, an event monitoring callback runs (occurs). 8. When the event monitoring callback occurs, an instruction is sent to the wait function 31 that is waiting for the event monitoring instance 21. The specified wait function 31 detects the event and wakes up. 9. The wait process 30 that called the wait function 31 resumes processing. Note that the creation of the notification FD in 2 above may be performed by the notification process 32 in some cases.

[0015] The existing technology will be further explained. FIG. 22 is a diagram illustrating the standby process of the existing technology described in Non-Patent Document 1. As shown in FIG. 22, a standby process 40 has a standby unit 41 and a sleep unit 42, and an idle process 50 (idle task) has an idle unit 51. In addition, an OS kernel 60 has a scheduler 61 and a C-state control unit 62 (C-states will be described later). The idle process 50 will disappear if another process (thread) exists on the CPU core.

[0016] In the power saving method of the existing technology, the standby unit 41 calls the sleep unit 42, and the process (standby process 40) enters a standby state. If there are no other processes in an executable state, the scheduler 61 calls a process having the idle unit 51. The idle unit 51 uses the C-state control unit 62 to transition the CPU to a sleep state or turn off the power.

[0017] Existing technologies inevitably involve a context switch, which is the process of saving and restoring the CPU state (context) so that multiple processes can share a single CPU.

[0018] In existing technology, the C-state recovery time is determined by the kernel. The kernel determines the C-state depth based on the idle time estimated by the C-state control unit 62. A recovery time from the corresponding C-state occurs (Non-Patent Document 2).

[0019] FIG. 23 is a table showing an example of the C-state. Note that state definitions vary depending on the CPU hardware, so FIG. 23 is merely a reference example. As shown in FIG. 23, the CPU idle state has grades C0 to C6, and as the time without CPU load increases, the CPU transitions to a deeper sleep state. A deeper sleep state reduces CPU power consumption, but on the other hand, the time required to return to normal operation increases, which can be an issue in terms of low latency.

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

[0021] Furthermore, the depth to which the CPU idle state transitions is controlled by the CPU hardware and is dependent on the CPU product (it is often not possible to control this from software such as the kernel).

[0022] cpuidle - Do nothing, efficiently, [online], [Retrieved July 6, 2022], Internet <URL: http: / / landley.net / kdocs / ols / 2007 / ols2007v2-pages-119-126.pdf> CPU analysis, [online], [Retrieved July 6, 2022], Internet <URL: https: / / docs.microsoft.com / ja-jp / windows-hardware / test / wpt / cpu-analysis>

[0023] Existing technology has the problem of increased delay time. (1) Increased delay time due to context switch time Figure 24 is a diagram explaining the problem of existing technology. The bottom part of Figure 24 is the schedule of the standby process (core #n), and the top part of Figure 24 is the schedule of the notification process (core #m). Assume that the following steps 1 to 3 have been executed at initialization. 1. Create an event monitoring instance 2. Create a notification FD and register the event monitoring instance 3. Transfer the notification FD

[0024] 4. When the standby process 71 enters a sleep state, an idle task may be scheduled for the corresponding CPU core. In FIG. 24, after the standby process 71 and the standby function 72 are executed, the event receiver (core #n) transitions to the idle task 76 by a context switch (symbol a in FIG. 24). As described above, when the standby process enters a sleep state, if the corresponding CPU core is in an idle state with no other processes running on it, the idle task 76 appears. As the idle task 76 operates, the CPU core (event receiver (core #n)) gradually enters a deeper sleep state (CPU idle), making it possible to reduce power consumption.

[0025] On the other hand, when an event occurs in the event sender (core #m) in step 5, an event monitoring callback 75 is executed in step 6 by writing to the FD for notification in step 74, and the event sender (core #m) issues an inter-processor interrupt (symbol b in FIG. 24 ) to the event receiver (core #n).

[0026] When the standby function wakes up in step 8, the idle task 76 is scheduled again, and then the standby function is scheduled via a context switch (reference symbol c in FIG. 24), resulting in step 9. standby process processing resumes (number 78 in FIG. 24). A context switch generally switches between operating in kernel space and operating in user space. This context switch from the idle task 76 to the standby function wakeup 77 (reference symbol c in FIG. 24) causes a significant delay (indicated by the star d in FIG. 24). In other words, a context switch time is required to switch to the standby function, resulting in a significant delay.

[0027] (2) Increased delay time due to return from sleep state (C-state) When the CPU enters the idle state, the CPU gradually or directly transitions to a sleep state (C-state) permitted by the OS governor. If the OS governor allows a deep sleep state as a server-wide policy (e.g., C6), a long return time of 100 μs or more occurs before the CPU returns to the operating state (C0).

[0028] Figure 25 is a diagram that overlays the C-state transition image of the CPU core used for calculations on the schedule of Figure 24. As shown in Figure 25, when there is a long period of time without tasks, the CPU core is in a deep sleep state (CPU idle state: grade C6), and the delay time until recovery after a task occurs (symbol e in Figure 25) is extended. If the CPU falls into a deep CPU idle state, it takes a long time to recover, which poses a problem of impairing real-time performance.

[0029] The above issue cannot be ignored in a system where real-time performance is the top priority, such as a base station (BBU). For this reason, the base station (BBU) takes measures such as disabling the C-state or limiting the idle state transition to a limited depth, such as C1. In other words, tuning aimed at real-time performance may be performed at the expense of power saving.

[0030] The present invention has been made in view of the above background, and an object of the present invention is to reduce the time it takes for a standby process to wake up after an event occurs.

[0031] In order to solve the above-mentioned problems, a computer system is provided which has a processor consisting of multiple cores and in which a process which executes a predetermined instruction operates using time on the processor, the process having a standby process which waits until a notification is received and wakes up and resumes operation when a notification is received, and a notification process which sends a notification to wake up the standby process when an event occurs, and the standby process has a pseudo-idle task which continues to occupy the processor when in standby state.

[0032] According to the present invention, it is possible to reduce the time it takes for the standby process to wake up after an event occurs.

[0033] 1 is a schematic configuration diagram of a computer system according to an embodiment of the present invention. FIG. 2 is a diagram explaining the elimination of context switches (feature <1>) in a computer system according to an embodiment of the present invention. FIG. 3 is a diagram showing a schedule of a CPU core used for calculations in a computer system according to an embodiment of the present invention, with a C-state transition image of the CPU core superimposed on it. FIG. 4 is a diagram showing the behavior of the standby process at <standby start>, <standby>, and <when ​​an event occurs> in a comparative example of a computer system according to an embodiment of the present invention. FIG. 5 is a diagram showing the behavior of the standby process at <standby start>, <standby>, and <when ​​an event occurs> in a computer system according to an embodiment of the present invention. FIG. 6 is a diagram showing the behavior of the standby process at <standby start>, <standby>, and <when ​​an event occurs> in a comparative example of a computer system according to an embodiment of the present invention. FIG. 7 is a diagram showing the behavior of the standby process at <standby start>, <standby>, and <when ​​an event occurs> in a computer system according to an embodiment of the present invention. FIG. 8 is a diagram showing an implementation image of a computer system according to an embodiment of the present invention. FIG. 9 is a diagram explaining application range 1 of a computer system according to an embodiment of the present invention. FIG. 10 is a diagram explaining application range 2 of a computer system according to an embodiment of the present invention. FIG. 11 is a sequence for a case in which a pseudo-idle function is required before an event occurs in a computer system according to an embodiment of the present invention. FIG. 1 is a sequence diagram for a case in which the pseudo-idle function before an event occurs in a computer system according to an embodiment of the present invention is unnecessary. FIG. 2 is a sequence diagram for a case in which the pseudo-idle function after an event occurs in a computer system according to an embodiment of the present invention is necessary. FIG. 3 is a flowchart for executing the pseudo-idle function in a pseudo-idle determination unit of a computer system according to an embodiment of the present invention. FIG. 4 is a flowchart for determining a maximum return time in a return time determination unit of a computer system according to an embodiment of the present invention. FIG. 5 is a diagram showing an example of operation when maximum return time determination processing is executed in a computer system according to an embodiment of the present invention. FIG. 6 is a hardware configuration diagram showing an example of a computer that realizes the functions of a task scheduler device of a computer system according to an embodiment of the present invention. FIG. 7 is a diagram showing inter-process communication within a server using a polling method.24 is a diagram showing inter-process communication within a server using a notification method; FIG. 25 is a diagram showing a notification system using eventfd+epoll_wait; FIG. 26 is a diagram explaining the standby process of existing technology; FIG. 27 is a diagram showing an example of C-state states in a table; FIG. 28 is a diagram explaining the issues with existing technology; and FIG. 29 is a diagram showing the C-state transition image of the CPU core used for calculations superimposed on the schedule of FIG. 24.

[0034] A computer system 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. [Overview] Fig. 1 is a schematic diagram of a computer system according to an embodiment of the present invention. Components that are the same as those in Fig. 22 are assigned the same reference numerals. This embodiment is an example in which the computer 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) if they have an idle state function.

[0035] As shown in FIG. 1, the computer system 1000 includes a kernel 60, CPU cores (core #m, core #n, core #x) 80, a notification process 90, an idle process 50, and a task scheduler device 100.

[0036] The kernel 60 includes a scheduler 61, a C-state control unit 62, an fd (file descriptor) 63 such as an eventfd, and a socket (communication socket) 64 such as a Unix Domain Socket.

[0037] The idle process 50 has an idle section 51. The idle process 50 allows other processes (threads) to use the CPU core during standby.

[0038] The computer system 1000 has a processor consisting of multiple cores, and a process that executes a predetermined command operates using the time on the processor. The process is a standby process 101 that waits until it receives a notification and wakes up and resumes operation when it receives a notification, a notification process 90 that sends a notification to wake up the standby process when an event occurs, and an idle process 50 that is generated when there is no process on the processor and does not execute anything.

[0039] [Task scheduler device 100] Task scheduler device 100 includes a standby unit 110, a pseudo-idle unit 120, a pseudo-idle determination unit 130, a return time determination unit 140 (return time control unit), and a return time setting unit 150 (return time control unit). Standby unit 110 and pseudo-idle unit 120 constitute a standby process 101, and cooperate with an idle unit 51 of an idle process 50 (idle task). Pseudo-idle determination unit 130, return time determination unit 140, and return time setting unit 150 constitute a management unit 102.

[0040] The standby process 101 waits until it receives a notification, and when it receives a notification, it wakes up and resumes operation. The standby unit 110 maintains an executable state. The standby unit 110 performs standby setting and executable state setting in response to a pseudo-idle function request from the pseudo-idle determination unit 130. Specifically, in response to an instruction from the pseudo-idle determination unit 130, the standby unit 110 executes the pseudo-idle unit 120 or performs a context switch to an idle process having an idle function.

[0041] The pseudo-idle unit 120 maintains a sleep (NOP) state in which no processing is being performed. The pseudo-idle unit 120 invokes and executes the C-state control unit 62, which controls the operating state of the CPU, instead of the idle unit 51. The pseudo-idle unit 120 has a pseudo-idle task 103 (FIGS. 5 and 7) that keeps the standby process 101 exclusively using the processor when the pseudo-idle unit 120 is in a standby state. Here, the kernel scheduler gives execution time to the standby process 101 when an event occurs. Because the pseudo-idle task 103 that was executed immediately before is executed as an extension of the standby process, it is possible to eliminate the context switch that accompanies process switching.

[0042] Pseudo-idle determination unit 130 determines whether to execute pseudo-idle unit 120 (pseudo-idle task) based on the process occurrence status on the same processor and / or delay time requirements, and instructs standby unit 110. The reason why it is necessary to determine whether to execute pseudo-idle unit 120 is that, as will be described later in FIG. 10, in a situation where a notification process and a standby process are running on the same CPU core, running the pseudo-idle unit is ineffective in eliminating context switches, and there is also the possibility that it may have an impact on other processes, such as increasing processing delays.

[0043] The recovery time determination unit 140 determines the recovery time corresponding to the maximum C-state that the pseudo-idle unit 120 can fall into based on the delay time requirements and the current C-state. The recovery time determination unit 140 notifies the recovery time setting unit 150 of the maximum recovery time.

[0044] The recovery time setting unit 150 sets the maximum recovery time in the C-state control unit 62 using the maximum recovery time from the recovery time determination unit 140. After the pseudo-idle unit 120 has finished, the recovery time setting unit 150 returns the maximum recovery time to the original value.

[0045] The return time determination unit 140 and the return time setting unit 150 constitute a return time setting unit that sets the return time until the pseudo-idle task 103 returns after the task is generated. This return time control unit is a functional unit that overwrites the determined return time with the maximum return time and prevents the transition to a deep sleep state by shortening the maximum return time.

[0046] The operation of the computer system 1000 configured as described above will be described below. [Basic Concept of Operation of the Task Scheduler Apparatus 100] Feature <1>: Elimination of Context Switches The standby process is made to behave in the same way as an idle task, eliminating context switches from the idle task. Since the standby function operates in the same way as the idle task within its context, no context switches to existing idle tasks occur. This satisfies <Requirement 1: Reduction of notification time>. While the standby function is running, the CPU core can enter a deep sleep state, just like an idle task. This satisfies <Requirement 2: Power saving>.

[0047] Figure 2 is a diagram explaining the elimination of context switches (feature <1>). The same processes as in Figure 24 are given the same reference numerals. The lower part of Figure 2 is the schedule for the event receiver (core #n), and the upper part of Figure 2 is the schedule for the event sender (core #m). Assume that the following steps 1 to 3 have been executed at initialization. 1. Create an event monitoring instance 2. Create a notification FD and register the event monitoring instance 3. Transfer the notification FD

[0048] After the standby process processing 71, the event receiver (core #n) does not transition to the idle task (without generating a context switch) (symbol aa in FIG. 2), but goes to 4. standby function and 8. standby function wakeup 201. That is, in the standby function and standby function wakeup 201, 4. standby function behaves in the same way as the idle task (symbol bb in FIG. 2).

[0049] On the other hand, when an event occurs in the event sender (core #m) in step 5, an event monitoring callback 75 is executed in step 6 by writing to the FD for notification in step 74, and the event sender (core #m) issues an inter-processor interrupt (symbol b in FIG. 2) to the event receiver (core #n).

[0050] Since the 4. wait function behaves in the same way as the idle task, the idle task is not scheduled when the 8. wait function is woken up, and therefore a context switch (symbol cc in FIG. 2) does not occur, resulting in 9. the standby process processing resumes 78.

[0051] Because the wait function operates in the same way as the idle task within its context, a context switch to an existing idle task (symbol c in FIG. 24) does not occur. This satisfies <Requirement 1: Reduction of notification time>. Although not shown in FIG. 2, while the wait function is running, the CPU core can enter a deep sleep state, just like the idle task (number 76 in FIG. 24). This satisfies <Requirement 2: Low power consumption>.

[0052] Feature <2>: Specifying the return time of the pseudo-idle task Specify the maximum return time of the pseudo-idle task to prevent it from falling into a deep sleep state. The return time determined by the OS governor is overwritten with the maximum return time, shortening the maximum return time. This prevents the computer system from transitioning to a deep sleep state, making it possible to shorten the delay time until the standby function is woken up. This satisfies <Requirement 1: Reduction of notification time>. On the other hand, by lengthening the maximum return time, it is possible to transition to a deep sleep state, further reducing power consumption in the HW. This satisfies <Requirement 2: Power saving>.

[0053] Figure 3 shows the schedule in Figure 2, overlaid with the C-state transition image of the CPU core used for calculations. The same processes as in Figure 25 are assigned the same reference numerals. As shown in Figure 3, the maximum recovery time (ee in Figure 3) from task generation (dd in Figure 3) to recovery is specified. This maximum recovery time specification is possible because the standby function / standby function wakeup 201, which allows standby functions to behave similarly to idle tasks, allows for flexibility in scheduling the standby function / standby function wakeup 201. Regarding the maximum recovery time specification, if the maximum recovery time is set short, the CPU core will fall into a shallow sleep state, resulting in little power reduction. On the other hand, if the maximum recovery time is set long, the CPU core will fall into a deep sleep state, resulting in significant power reduction. However, if the CPU core falls into a deep sleep state, it will take some time to recover.

[0054] [Operation of the Task Scheduler Apparatus 100] [Operation 1] Operation 1 of the task scheduler apparatus 100 will be described in comparison with a comparative example (existing technology). First, the operation of the comparative example (existing technology) will be described. Figure 4 is a diagram showing the behavior of the standby process at "standby start", "standby", and "event occurrence" in the comparative example. The same components and processes as in Figure 1 are assigned the same reference numerals.

[0055] <At the Start of Standby> The server has a CPU core 80 (event receiver (core #n)) and a CPU core 80 (event sender (core #m)). At the start of standby, a standby process 91 is in a task queue 85 on the CPU core 80 (core #n).

[0056] <Waiting> The so-called waiting state means that the waiting process 91 enters the waiting queue 86 on the CPU core 80 (core #n). During waiting, the waiting process 91 leaves the task queue 85 (arrow f in FIG. 4) and enters the waiting queue 86 on the right side of FIG. 4, entering the waiting state.

[0057] Here, when there are no other processes running on the CPU core 80 (core #n), i.e., when the CPU core is in an idle state, an idle task 92 appears on the CPU core 80 (core #n). This idle task 92 is a process (task) that appears automatically so that the task queue 85 does not become empty.

[0058] <When an event occurs> When an event is detected in kernel mode, the notification process 90 notifies the standby process 91 via the fd 63 and socket 64 of the kernel 60 (FIG. 1), and the standby process 91 returns to the task queue 85 in the center of FIG. 4 (arrow g in FIG. 4). When the standby process 91 returns to the task queue 85, a context switch occurs between the idle task 92 and the standby process 91 (symbol c in FIG. 24).

[0059] Next, the operation of this embodiment will be described. Figure 5 shows the behavior of the standby process at "standby start", "standby", and "event occurrence" in this embodiment. The same components and processes as in Figures 1 and 4 are assigned the same reference numerals.

[0060] <At the start of standby> The server has a CPU core 80 (event receiver (core #n)) and a CPU core 80 (event sender (core #m)). The standby process 101 is in the task queue 85 on the CPU core 80 (core #n). <At the start of standby>, the behavior of the standby process is the same in this embodiment and the comparative example.

[0061] 4, when the standby process 91 returns to the task queue 85, a context switch occurs between the idle task 92 and the standby process 91 (symbol c in FIG. 24). This can be solved by preventing the idle task 92 from occurring.

[0062] Therefore, in this embodiment, the standby process 101 has a standby unit 110 and a pseudo-idle unit 120 (FIG. 1). That is, the standby process 101 further introduces a pseudo-idle unit 120 (pseudo-idle task 103) into the standby process 91 of FIG. 4. The pseudo-idle task 103 continues to exclusively use the CPU core 80 (core #n) so as not to generate the idle task 92 and prevent the standby process 101 from entering the task queue 85. That is, by introducing the pseudo-idle task 103, the CPU core is continued to be exclusively used without yielding it to other processes. More specifically, the exclusive use of the CPU core means continuing to exclusively use the CPU core without yielding CPU time. Specifically, the pseudo-idle task 103 issues epoll, but continues to exclusively use the CPU core without yielding it to other processes (threads).

[0063] As indicated by the symbol ff in Fig. 5, the standby process 101 continues to remain in the task queue 85. That is, in the comparative example of Fig. 4, during standby, the standby process 91 leaves the task queue 85 and enters the wait queue 86, entering a waiting state. In contrast, in this embodiment, although the pseudo-idle task 103 issues an epoll, it continues to monopolize the CPU time without yielding it to other processes (threads), so that the standby process 101 continues to remain in the task queue.

[0064] As a result, the pseudo-idle task 103 continues to occupy the CPU core 80 (core #n), so the waiting process 101 can continue to remain in the task queue 85 and no context switch occurs.

[0065] Also, as described in the comparative example of FIG. 4 , the presence of the idle task 92 in the task queue 85 allowed the CPU core 80 (core #n) to transition to the idle state. The pseudo-idle task 103 of this embodiment operates in the same manner as the idle task 92. Like the idle task 92, the pseudo-idle task 103 is a task that basically does nothing, but the presence of the pseudo-idle task 103 that operates in the same manner as the idle task 92 allows the pseudo-idle task 103 to cause the CPU to execute a sleep (NOP) instruction. This reduces the CPU cycle and makes it possible to suppress the power consumption of the corresponding CPU core.

[0066] <When an event occurs> When an event is detected in kernel mode, the standby process 101 receives a notification from the notification process 90 via the fd 63 and socket 64 of the kernel 60 (FIG. 1). Since the standby process 101 remains in the task queue 85 (symbol gg in FIG. 5), when the notification is received upon detection of an event issuance in kernel mode, the standby process 101 is already in the task queue 85. Therefore, no context switch occurs (symbol cc in FIG. 2).

[0067] [Operation 2] Operation 2 of the task scheduler device 100 will be described in comparison with a comparative example (existing technology). First, the operation of the comparative example (existing technology) will be described. Figure 6 is a diagram showing the behavior of the standby process at "standby start", "standby", and "event occurrence" in the comparative example. The same configurations and processes as in Figure 4 are assigned the same reference numerals. The task scheduler device 100 allocates CPU execution time to processes in the task queue 85 that are in an executable state (TASK_RUNNING).

[0068] <At the Start of Standby> Since only the standby process exists in the task queue 85, the task scheduler device 100 gives the standby process an execution time (symbol h in FIG. 6).

[0069] <Waiting state> When the task queue 85 becomes empty, the task scheduler device 100 generates an idle task 92 and gives execution time to the idle task 92. At this time, a context switch occurs (symbol i in FIG. 6). Also, during waiting, the waiting process 91 leaves the task queue 85 (arrow j in FIG. 6) and enters the waiting queue 86, entering a waiting state.

[0070] <When an Event Occurs> When the standby process 91 is called upon the occurrence of an event, the task scheduler apparatus 100 provides execution time to the standby process 91. At this time, a context switch occurs (symbol k in FIG. 6 ). The standby process 91 also returns to the task queue 85 in the center of FIG. 6 (arrow l in FIG. 4 ).

[0071] Next, the operation of this embodiment will be described. Figure 7 is a diagram showing the behavior of the standby process at "standby start", "standby in progress", and "event occurrence" in this embodiment. The same configurations and processes as in Figure 5 are assigned the same reference numerals. The task scheduler device 100 allocates CPU execution time to processes in the task queue 85 that are in an executable state (TASK_RUNNING).

[0072] <At the Start of Standby> Since only the standby process 101 exists in the task queue 85, the task scheduler device 100 gives the standby process 101 an execution time (symbol hh in FIG. 7).

[0073] <Waiting> Because the waiting process 101 remains in an executable state, the task scheduler apparatus 100 provides execution time to the waiting process 101 (symbol ii in FIG. 7). That is, because the pseudo-idle task 103 continues to occupy the CPU core 80 (core #n) (see <Waiting> in FIG. 5), the waiting process 101 can continue to remain in the task queue 85, and a context switch does not occur.

[0074] <When an Event Occurs> When the standby process 101 is called upon the occurrence of an event, the task scheduler apparatus 100 assigns an execution time to the standby process 101 (symbol jj in FIG. 7).

[0075] [Implementation Image] An implementation image of the task scheduler device 100 will be described in comparison with a comparative example (existing technology). First, the implementation image of the comparative example (existing technology) will be described. FIG. 8 is a diagram showing an implementation image in the comparative example. As shown in FIG. 8, the driver / hardware includes a cpuidle driver (ACPI / intel_idle) 306. The kernel includes the task scheduler device 100, sysfs 303, a cpuidle governor 304, and a cpuidle framework 305. The user space includes an epoll_wait 301 and an idle task 302. When the wait function (epoll_wait 301) enters a wait state (idle task 302), the task scheduler device 100 switches processes using the kernel function switch_to. A context switch (symbol c in FIG. 8) is executed to switch from epoll_wait 301 to idle task 302.

[0076] FIG. 9 is a diagram showing an implementation image of this embodiment. As shown in FIG. 9, the driver / hardware includes a cpuidle driver (ACPI / intel_idle) 306. The kernel includes a task scheduler device 100, a sysfs 303, a cpuidle governor 304, and a cpuidle framework 305. The user space includes an epoll_wait 301 and an idle task 302. In the task scheduler device 100, the wait function (epoll_wait 301) directly issues a cpuidle_idle_call to the cpuidle framework 305. At this time, the wait function (epoll_wait 301) itself remains in an executable state, i.e., it does not enter a waiting state. Furthermore, since there are no other processes, the task scheduler device 100 has no process to switch to. This allows the task scheduler device 100 to constantly use time in the wait function (epoll_wait 301).

[0077] The maximum recovery time may be specified when the wait function (epoll_wait 301) is directly issued by cpuidle_idle_call. The maximum recovery time may also be specified from the wait function (epoll_wait 301) to the kernel's sysfs 303 via the sysfs 303 (reference numeral 11 in FIG. 9).

[0078] The above-mentioned operation of the task scheduler device 100 to keep the wait function (epoll_wait 301) in an executable state and constantly use time corresponds to the description in <Waiting> of FIG. 5 that "the pseudo-idle task 103 issues an epoll, but continues to monopolize the CPU time without yielding it to other processes (threads)."

[0079] [Scope of Application] [Scope of Application 1] The scope of application of the task scheduler device 100 will be described. The standby process 101 can run on the same CPU core as the notification process 90 and other processes. However, to maximize the effect, it is desirable for the standby process 101 to be on a CPU core different from the notification process 90 and other processes.

[0080] 10 is a diagram for explaining the application range 1 of the task scheduler device 100. The same processes as those in FIG. 1 are denoted by the same reference numerals.

[0081] <Notification process and standby process run on different CPU cores> (Left diagram in Figure 10) This can be applied when the notification process 90 and standby process 101 run on different CPU cores (core #m and core #n). - Sleep state: core #n sleeps. - Delay effect: the standby process wakes up quickly. - Concerns: None in particular.

[0082] <Notification process and standby process coexist on the same CPU core> (middle diagram in Figure 10) This can be applied when the notification process 90 and standby process 101 coexist on the same CPU core (core #n). The notification process 90 and standby process 101 compete for CPU time (symbol mm in the middle diagram in Figure 10). - Sleep state: Core #n does not completely sleep due to the notification process 90. - Delay effect: The presence of the notification process 90 results in little improvement in delay (due to the existence of a context switch with the notification process 90 and the fact that the C-state is not deep to begin with). - Concerns: Because the standby process 101 is in an operational state, the notification process 90 is slow to detect events and send notifications.

[0083] <Standby process and other processes coexist on the same CPU core> (right diagram in Figure 10) This can be applied when the standby process 101 and other processes 104 coexist on the same CPU core (core #n). The notification process 90 and the standby process 101 compete for CPU time (symbol nn in the right diagram in Figure 10). - Sleep state: core #n does not completely sleep due to the other processes 104. - Delay effect: The presence of the other processes 104 results in little improvement in delay (due to the presence of context switches with the other processes 104 and the fact that the C-state is not deep to begin with). - Concerns: Because the standby process 101 is in an operational state, it takes away the operational time that the other processes 104 should have.

[0084] [Scope of Application 2] The notification process 90 and the standby process 101 are applicable regardless of whether they are located in the user space or the kernel space. FIG. 11 is a diagram illustrating scope of application 2 of the task scheduler apparatus 100. The same processes as those in FIGS. 1 and 10 are assigned the same reference numerals. The upper left diagram in FIG. 11 is an example where the notification process is in the user space and the standby process is in the user space. The upper right diagram in FIG. 11 is an example where the notification process is in the user space and the standby process is in the kernel space. The lower left diagram in FIG. 11 is an example where the notification process is in the kernel space and the standby process is in the user space. The lower right diagram in FIG. 11 is an example where the notification process is in the kernel space and the standby process is in the kernel space. As described above, the notification process 90 and the standby process 101 can be located in either the user space or the kernel space.

[0085] [Scope of application 3] Examples of file descriptors used for notification include eventfd, singalfd, and timerfd. Examples of wait functions for monitoring resources include read(), select(), poll(), and epoll(). All of these functions operate in a blocking or non-blocking manner, but when blocking, they fall into a state of waiting for a TASK_INTERRUPTIBLE / TASK_UNINTERRUPTIBLE event, so this invention is applicable.

[0086] [Control Sequence] The control sequence of the task scheduler device 100 will be described. [Control Sequence 1] Fig. 12 shows a sequence in a case where a pseudo-idle function is required before an event occurs. The standby process 101 requests the pseudo-idle determination unit 130 to start standby (S101). The pseudo-idle determination unit 130 requests the return time determination unit 140 to determine a return time (S102). The return time determination unit 140 determines the return time (S103). The detailed flow of determining the return time in step S103 will be described later with reference to Fig. 16.

[0087] The recovery time determination unit 140 notifies the recovery time setting unit 150 of the recovery time (S104). The recovery time setting unit 150 sets the recovery time for the C-state control unit 62 (S1051). The C-state control unit 62 responds to the recovery time setting unit 150 with the recovery time setting (S106).

[0088] Upon receiving the response of the recovery time setting from the C-state control unit 62, the recovery time setting unit 150 responds with the recovery time to the recovery time determination unit 140 (S107). The recovery time determination unit 140 notifies the pseudo-idle judgment unit 130 of the recovery time determination response from the recovery time setting unit 150 (S108).

[0089] The pseudo-idle determining unit 130 determines whether the pseudo-idle function is required (S109). The detailed flow of determining whether the pseudo-idle function is required in step S109 will be described later with reference to Fig. 15. The pseudo-idle determining unit 130 requests the standby unit 110 of the standby process 101 to provide the pseudo-idle function (S110).

[0090] In response to a pseudo-idle function request from pseudo-idle determination unit 130, standby unit 110 performs standby setting and executable state setting (S111). Standby unit 110 notifies pseudo-idle determination unit 130 of a pseudo-idle function response to the pseudo-idle function request (S112). Standby unit 110 requests pseudo-idle unit 120 to start pseudo-idle (S113). Pseudo-idle unit 120 requests C-state control from C-state control unit 62 (S114).

[0091] [Control Sequence 2] Figure 13 shows a sequence for a case where the pseudo-idle function before an event occurs is not required. The same processes as those in the control sequence of Figure 12 are assigned the same numbers. The standby process 101 requests the pseudo-idle determination unit 130 to start standby (S101). The pseudo-idle determination unit 130 requests the recovery time determination unit 140 to determine a recovery time (S102). The recovery time determination unit 140 determines the recovery time (S103). The detailed flow of determining the recovery time in step S103 will be described later with reference to Figure 15.

[0092] The recovery time determination unit 140 notifies the recovery time setting unit 150 of the recovery time (S104). The recovery time setting unit 150 sets the recovery time for the C-state control unit 62 (S1051). The C-state control unit 62 responds to the recovery time setting unit 150 with the recovery time setting (S106).

[0093] Upon receiving the response of the recovery time setting from the C-state control unit 62, the recovery time setting unit 150 responds with the recovery time to the recovery time determination unit 140 (S107). The recovery time determination unit 140 notifies the pseudo-idle judgment unit 130 of the recovery time determination response from the recovery time setting unit 150 (S108).

[0094] The pseudo-idle determining unit 130 determines whether the pseudo-idle function is required (S109). The detailed flow of the pseudo-idle function requirement determination in step S109 will be described later with reference to Fig. 16. The pseudo-idle determining unit 130 requests the standby unit 110 of the standby process 101 to provide the idle function (S201).

[0095] In response to the idle function request from the pseudo-idle determination unit 130, the standby unit 110 performs standby setting and wait state setting (S202). The standby unit 110 notifies the pseudo-idle determination unit 130 of an idle function response to the idle function request (S203). The standby unit 110 requests the scheduler 61 to start an idle state (S204).

[0096] The scheduler 61 issues an idle start request to the idle section 51 (S205). The idle section 51 requests the C-state control section 62 to perform C-state control (S114).

[0097] [Control Sequence 3] Figure 14 shows a sequence for a case where the pseudo-idle function is required after an event occurs. The notification process 90 notifies the standby unit 110 using a file descriptor or the like (S301). The standby unit 110 requests the pseudo-idle unit 120 to end the pseudo-idle (S302). The pseudo-idle unit 120 requests the C-state control unit 62 to control the C-state (S303).

[0098] The standby unit 110 requests the pseudo-idle determination unit 130 to end the pseudo-idle state (S304). The pseudo-idle determination unit 130 notifies the standby process 101 of the end of the standby state (S305). The standby process 101 resumes processing (S306).

[0099] The pseudo-idle determining unit 130 sets the recovery time in the C-state control unit 62 (S307). The C-state control unit 62 responds to the pseudo-idle determining unit 130 with the recovery time setting (S308).

[0100] [Flowcharts] The following describes the flowcharts of the task scheduler apparatus 100. [Flowchart 1] Fig. 15 is a flowchart for executing the pseudo-idle function in the pseudo-idle determination unit 130. This is a detailed flow of "determining whether pseudo-idle is necessary" in step S109 in Fig. 12 and Fig. 13. In step S11, the pseudo-idle determination unit 130 determines whether or not there are zero other processes 104 running in the same core as the standby process 101 while the standby process 101 is sleeping (see the right diagram in Fig. 10).

[0101] If the number of other processes 104 running during sleep is 0 (S11: Yes), it is determined that an idle task has occurred, and the pseudo-idle determining unit 130 executes the pseudo-idle function in step S12.

[0102] In step S13, the pseudo-idle determining unit 130 determines whether or not the CPU sleep state control is enabled by the hardware setting (BIOS).

[0103] If the CPU sleep state control is enabled (S13: Yes), it is determined that the C-state is present, and in step S14 the pseudo-idle judgment unit 130 determines whether the recovery time determined by the OS governor is greater than the allowable recovery time (whether the recovery time determined by the OS governor is greater than the allowable recovery time).

[0104] If the recovery time set by the OS governor is greater than the allowable recovery time (S14: Yes), the pseudo-idle judgment unit 130 determines that maximum recovery time control is necessary, and in step S15 sets the allowable recovery time to the maximum recovery time (set maximum recovery time = allowable recovery time), and then ends the processing of this flow.

[0105] If the number of other processes 104 running during sleep is not 0 in step S11 (S11: No), the pseudo-idle determining unit 130 determines that there is no idle task and proceeds to step S17 without executing the pseudo-idle function in step S16.

[0106] If the CPU sleep state control is not enabled in step S13 above, or if the recovery time determined by the OS governor in step S14 above is less than or equal to the allowable recovery time (if the recovery time determined by the OS governor is less than or equal to the allowable recovery time), the pseudo-idle judgment unit 130 terminates the processing of this flow in step S17 without specifying a maximum recovery time.

[0107] [Flowchart 2] Figure 16 is a flowchart of recovery time determination in the recovery time determination unit 140. It shows detailed flow of "recovery time determination" in step S103 of Figures 12 and 13. This flow is a method of determining the maximum recovery time using the actually measured C-state recovery time. In step S21, when the actually measured C-state = maximum recovery time in time slot #n, the recovery time determination unit 140 determines whether this actually measured C-state is equal to the C-state allowed by the maximum recovery time (C-state = C-state allowed by the maximum recovery time).

[0108] If the C-state is the C-state allowed by the maximum recovery time (S21: Yes), in step S22, the recovery time determination unit 140 determines whether (the C-state recovery time allowed by the maximum recovery time plus the increase in recovery time for the next deeper C-state) is smaller than the allowable delay time.

[0109] If (C-state recovery time allowed by maximum recovery time + recovery time increment in C-state one level deeper) < allowable delay time (S22: Yes), in step S23, the recovery time determination unit 140 sets the maximum recovery time in time slot #n+1 + recovery time increment in C-state one level deeper (allowable C-state + 1), and ends the processing of this flow.

[0110] If the C-state is not the C-state allowed by the maximum recovery time in step S21 (S21: No), the recovery time determination unit 140 determines that the recovery time has been shortened, and in step S24 sets the maximum recovery time in time slot #n+1 minus the difference in recovery time between the C-state that is one step shallower (allowable C-state - 1), and then ends the processing of this flow.

[0111] If, in step S22, (the C-state recovery time allowed for the maximum recovery time + the increase in the recovery time at the next deeper C-state) is equal to or greater than the allowable delay time (S22: No), in step S25, the recovery time determination unit 140 determines that the maximum recovery time will not be corrected and ends the processing of this flow.

[0112] In the above flow, a decision is made for each time slot as to whether additional delay is allowed by transitioning to a higher C-state, or whether transitioning to a lower C-state is possible. If there is periodicity in the past history, it is acceptable to transition to the target C-state immediately. Also, if the measured C-state is C0, it is busy, so it is acceptable to immediately return to C0 without going through the steps.

[0113] FIG. 17 shows an example of operation when the maximum recovery time determination process of FIG. 16 is executed. The vertical axis of FIG. 17 indicates the allowable delay, and the horizontal axis indicates time. The dashed line in FIG. 17 indicates the C-state recovery time allowed based on the maximum recovery time, and the solid line in FIG. 17 indicates the actually measured C-state recovery time. As shown in FIG. 17, once the allowable C-state recovery time is set, the actually measured C-state recovery time follows it. FIG. 17 shows an example in which the target C-state C3 in time slot t3 is not allowed because it exceeds the allowable delay (symbol oo in FIG. 17).

[0114] [Hardware Configuration] The task scheduler apparatus 100 ( FIG. 1 ) according to the above embodiment is realized by, for example, a computer 900 configured as shown in FIG. 18. FIG. 18 is a hardware configuration diagram showing an example of the computer 900 that realizes the functions of the task scheduler apparatus 100 ( FIG. 1 ). 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.

[0115] 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 (FIG. 1). 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.

[0116] 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.

[0117] 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) 922) and outputs the data to the CPU 901, and also transmits data generated by the CPU 901 to other devices via the communication network.

[0118] 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.

[0119] For example, when the computer 900 functions as the task scheduler device 100 ( FIG. 1 ) configured as one device according to this embodiment, the CPU 901 of the computer 900 executes a program loaded onto the RAM 903 to realize the functions of the task scheduler device 100. 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 device via a communication network (NW 922).

[0120] [Effects] As described above, computer system 1000 (FIG. 1) has a processor consisting of multiple cores, and a process that runs on the processor to execute a predetermined instruction using time on the processor. The process has a standby process 101 (FIGS. 5 and 7) that waits until it receives a notification and wakes up and resumes operation when it receives a notification, and a notification process 90 that sends a notification to wake up the standby process when an event occurs, and standby process 101 has a pseudo-idle task 103 (FIGS. 5 and 7) that continues to occupy the processor when it is in standby state.

[0121] By doing this, the computer system 1000 can make the standby process 101 behave the same as the idle task 92 (FIGS. 4 and 6), which is generated when there is no process on the processor and executes nothing. When waking up from standby, the idle task 92 is not scheduled, and therefore a context switch does not occur, and the standby process resumes processing. In other words, the pseudo-idle task 103 makes the standby process 101 behave the same as the idle task 92, eliminating a context switch from the idle task 92. This makes it possible to reduce the time it takes for the standby process to wake up after an event occurs.

[0122] In the computer system 1000 (FIG. 1), the pseudo-idle task 103 (FIGS. 5 and 7) is characterized by causing the processor to execute a sleep instruction.

[0123] By doing this, the pseudo-idle task 103 can make the CPU execute a sleep (NOP) instruction. That is, the pseudo-idle task 103 maintains a sleep state in which nothing is executed, and calls and executes the c-state control unit 62 (FIG. 1) that controls the operating state of the CPU instead of the idle unit 51 (FIG. 1). This reduces the CPU cycle and makes it possible to suppress the power consumption of the corresponding CPU core.

[0124] In a computer system 1000 (FIG. 1) having a processor consisting of multiple cores, in which a process that executes a predetermined instruction operates using time on the processor, a task scheduler device 100 (FIG. 1) that schedules the process includes a standby process 101 (FIGS. 5 and 7) that waits until it receives a notification and wakes up and resumes operation when it receives the notification, and a pseudo-idle task 103 (FIGS. 5 and 7) that keeps the standby process 101 exclusively using the processor when it is in the standby state.

[0125] By doing so, the task scheduler apparatus 100 resumes the standby process processing without generating a context switch, thereby minimizing the time it takes for the standby process to wake up after an event occurs.

[0126] In the task scheduler device 100 (FIG. 1), the pseudo-idle task 103 (FIGS. 5 and 7) is characterized by causing the processor to execute a sleep instruction.

[0127] In this way, the pseudo-idle task 103 can make the CPU execute a sleep (NOP) instruction, thereby reducing the CPU cycle and suppressing the power consumption of the CPU core.

[0128] The task scheduler device 100 (FIG. 1) is characterized by including a pseudo-idle determination unit 130 that determines whether to execute the pseudo-idle task 103 based on the process occurrence state on the same processor and / or delay time requirements.

[0129] In this way, the pseudo-idle task 103 can be executed under appropriate conditions based on the process occurrence state on the processor and the delay time requirements. Since the pseudo-idle task 103 is effective and is executed only under conditions that do not affect other processes, it is possible to achieve the effects of "eliminating context switches due to processor occupation" and "executing a sleep instruction."

[0130] The task scheduler device 100 (FIG. 1) is characterized by including a return time setting unit (return time determination unit 140 and return time setting unit 150) that sets the return time until the pseudo-idle task 103 (FIGS. 5 and 7) returns after the task is generated.

[0131] By doing so, the task scheduler apparatus 100 can shorten the delay time until the standby process (standby function) is woken up.

[0132] In the task scheduler device 100 (FIG. 1), the return time control unit (return time determination unit 140 and return time setting unit 150) is characterized in that it overwrites the determined return time with the maximum return time and prevents transition to a deep sleep state by shortening the maximum return time.

[0133] By doing so, it is possible to specify the maximum return time of the pseudo-idle task and control it so that it does not fall into a deep sleep state. This reduces the delay time from task allocation to the start of calculation, enabling calculations with high real-time performance. In other words, the task scheduler apparatus 100 can shorten the delay time until the standby process (standby function) is woken up. Therefore, it is possible to satisfy <Requirement 1: Reduction of notification time>. Furthermore, by extending the maximum return time, the task scheduler apparatus 100 can transition to a deep sleep state and reduce power consumption in the HW, thereby satisfying <Requirement 2: Power saving>.

[0134] Note that, among the processes described in the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically 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.

[0135] 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.

[0136] 50 Idle process (idle task) 51 Idle unit 60 Kernel 61 Scheduler 62 C-state control unit 90 Notification process 92 Idle task 100 Task scheduler device 101 Standby process 103 Pseudo-idle task 110 Standby unit 120 Pseudo-idle unit 130 Pseudo-idle determination unit 140 Recovery time determination unit (recovery time control unit) 150 Recovery time setting unit (recovery time control unit) 1000 Computer system CPU core #m, CPU core #n, ... CPU core

Claims

1. A computer system having a processor having a plurality of cores, and a standby process and a notification process each of which operates on a corresponding one of the plurality of cores and executes a predetermined instruction using time on the corresponding core, The standby process waits until a notification is received, and when the notification is received, the standby process wakes up and resumes operation; the notification process sends a notification to wake up the standby process when an event occurs; The waiting process has a pseudo-idle task that continues to occupy the core on which the waiting process operates when the waiting process is in a waiting state.

1. A computer system comprising:

2. The pseudo-idle task causes the core on which the standby process runs to execute a sleep command.

2. The computer system according to claim 1,

3. 1. A task scheduler device for scheduling a process in a computer system having a processor including a plurality of cores, the process executing a predetermined instruction using time on the processor, comprising: Operate on a corresponding one of the plurality of cores; a standby process that waits until it receives a notification and wakes up and resumes operation when it receives a notification; a pseudo-idle task that, when in a standby state, keeps the standby process exclusively using the corresponding one of the plurality of cores. A task scheduler device comprising:

4. The pseudo-idle task causes the corresponding one of the plurality of cores to execute a sleep instruction.

4. The task scheduler device according to claim 3.

5. A pseudo-idle determination unit that determines whether to execute the pseudo-idle task based on a process occurrence state on the corresponding one of the multiple cores and / or a delay time requirement.

4. The task scheduler device according to claim 3.

6. A return time control unit is provided for setting a return time until the pseudo-idle task returns after the task is generated.

4. The task scheduler device according to claim 3.

7. 1. A method for waking up a waiting process in a computer system having a processor having multiple cores, the method comprising: The task scheduler device includes: Operate on a corresponding one of the plurality of cores; A step of executing a standby process that waits until a notification is received and wakes up and resumes operation when the notification is received; and when in a standby state, the standby process executes a pseudo-idle task that continues to occupy the corresponding one of the plurality of cores. A method for waking up a waiting process.

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