WO2022168661A1

WO2022168661A1 - Scheduler, scheduling method, and computer-readable storage medium

Info

Publication number: WO2022168661A1
Application number: PCT/JP2022/002541
Authority: WO
Inventors: 才将中曽根
Original assignee: 日本電気株式会社
Priority date: 2021-02-03
Filing date: 2022-01-25
Publication date: 2022-08-11
Also published as: JP2022118736A; JP7188472B2

Abstract

The present invention suppresses a deterioration in performance related to context switching. This scheduler is provided with: a selection unit that selects, when a thread has been allocated to each core and no available cores exist, from the cores, a core having a thread in the same thread group as that of a worker thread to be generated in an executable queue or a standby queue of the core; and a determination unit that determines the allocation, to the selected core, of the worker thread to be generated.

Description

Scheduler, scheduling method and computer readable storage medium

This disclosure relates to thread scheduling in multicore.

A typical operating system interrupts a user program (user thread) to perform processing. This causes a slight delay in the processing of the user program. This delay builds up on a particular task and causes operating system (OS) jitter.

The architecture disclosed in Patent Document 1 has two types of cores: a control core that executes an OS and a computational core that executes a user program. The technique of Patent Document 1 avoids OS jitter by providing a mechanism in which the OS on the control core provides the OS function to the calculation core.

On the other hand, in the technique of Patent Document 1, since the OS does not exist on the calculation core, every time an OS function such as scheduling is provided to the calculation core, overhead due to information transmission between the control core and the calculation core is added. become. In particular, the cost of context switching increases.

Therefore, in programs that emphasize performance, it is desirable to keep the number of threads below the number of cores to suppress context switches.

Japanese Patent No. 5867482 WO2012/020478 Japanese Patent Publication No. 2017-506773 Japanese Patent Publication No. 2016-524238 JP 2006-190265 A Japanese Patent Application Laid-Open No. 2004-086921

Signals are a type of interprocess communication, and serve as an interrupt function that notifies other processes that a certain event has occurred. Interruption by a signal may trigger an operation that is not async-signal-safe, such as deallocating memory. In this case, a method is conceivable in which a worker thread is created in advance to execute the processing on behalf of the worker thread and is kept on standby, and the signal handler requests activation and processing of the worker thread.

However, as in the architecture disclosed in Patent Document 1, when the cost of context switching is high, activation of worker threads (hereinafter also referred to as workers) causes performance degradation due to context switching. For example, user threads are running on all cores, and one user thread receives a signal to start a worker. When the user thread that receives the signal starts a worker, the worker is scheduled on one of the cores and a context switch occurs. At this time, in a general scheduler, the target of the context switch is not limited to the user thread that started the worker.

Therefore, the progress of user threads unrelated (that is, different thread groups) from user threads that require worker processing is hindered. On the other hand, user threads that require worker processing end up with excessive CPU (Central Processing Unit) resources.

A worker is required for each user process if the worker performs process resource control such as memory release. Therefore, if there are multiple user processes, the same number of workers must also exist. When multiple workers are scheduled on the same core, context switches between workers also occur.
It is desired to provide a technique for suppressing performance degradation related to context switching in scheduling.

An object of the present disclosure is to provide a technology that can suppress performance degradation related to context switching.

The scheduler, which is one aspect of the present disclosure, assigns a thread to each core, and when there is no free core, the same worker thread to be generated is added to the executable queue or waiting queue of each core among the cores. a selection unit that selects a core in which a thread of the thread group exists; and a determination unit that determines allocation of the worker thread to be generated to the selected core.

A scheduling method, which is one embodiment of the present disclosure, assigns threads to each core, and when there is no free core, a worker thread to be generated and A core in which threads of the same thread group exist is selected, and it is decided to allocate the worker thread to be generated to the selected core.

In the computer-readable storage medium according to one aspect of the present disclosure, when threads are assigned to each core and there is no free core, A program for causing a computer to execute selecting a core in which a thread of the same thread group as a worker thread to be generated exists and deciding to allocate the worker thread to be generated to the selected core is stored.

According to the scheduler and the like of the present disclosure, performance degradation related to context switching can be suppressed.

FIG. 4 is a diagram showing a schedule example by a scheduler according to the first embodiment; FIG. 3 is a block diagram showing an example of the configuration of a scheduler according to the first embodiment; FIG. 7 is a flow chart showing an example of the operation of a scheduler when creating a thread; FIG. 11 is a flow chart showing an example of the operation of the scheduler when causing a thread to transition from the waiting state to the ready state; FIG. FIG. 11 is a flow chart showing another example of the operation of the scheduler; FIG. FIG. 11 is a block diagram showing an example of the configuration of a scheduler according to the second embodiment; FIG. FIG. 11 is a flow chart showing an example of the operation of a scheduler according to the second embodiment; FIG. It is a figure which shows the hardware constitutions by computer.

(First embodiment)
A scheduler, which is one aspect of the first embodiment, will be described with reference to the drawings.

FIG. 1 is a diagram showing a schedule example by the scheduler according to the first embodiment. The scheduler 1 schedules and allocates threads to each core (

cores

0, 1, 2, and 3). The scheduler 1 uses thread management data 2 to schedule threads. Scheduling is the process of determining the execution order of threads or the process of determining which cores to allocate threads to.

In the first embodiment, an example of scheduling threads to four cores will be described, but the number of cores is not limited to four.

The thread management data 2 includes information expressing scheduling for each thread associated with each core. For example, the thread management data 2 includes a thread identifier 21 (indicated as ID in the figure), a thread group identifier 22 (indicated as group ID in the figure), priority 23 and worker flag 24 . The scheduler 1 refers to the thread management data 2 to confirm the execution order and dependency of each thread.

The thread identifier 21 is information for identifying a thread. The thread group identifier 22 is information for identifying a group of threads forming a process. A thread group can also be said to be a set of threads that constitute a user process. The priority 23 is information indicating the degree of priority between threads in the same thread group. In FIG. 1, two priority levels, high and low, are shown, but the priority level is not limited to this. For example, there may be three or more priority levels.

The worker flag 24 is information for determining whether a thread is a worker thread. The worker flag 24 is, for example, a specification that can be finally set by the user by adding or extending an argument in an application interface for generating threads provided by the OS. For example, in the case of Linux (registered trademark) clone(), the third argument intflags (flags specifying thread attributes) is extended to add worker attributes, and the task_struct structure (thread management data) has a field for determining whether it is a worker or not.

Also, the scheduler 1 uses two types of queues that represent the scheduling of threads associated with each core. One is a runnable queue 31 consisting of threads in running or ready state, and the other is a wait queue 32 consisting of threads in waiting state.

For ease of implementation, instead of having two types of queues, threads may be managed as one task list. In this case, if the thread management data 2 exists in either the core's executable queue 31 or the core's standby queue 32, it is assumed that the thread is assigned to the core.

The scheduler 1 described in this specification shall have a function as a thread scheduler in the OS. Therefore, a detailed description of the functions of the normal scheduler will be omitted.

FIG. 2 is a block diagram showing an example of the configuration of the scheduler according to the first embodiment. A scheduler 1 shown in FIG.

The confirmation unit 11 identifies and confirms the core to which the thread is assigned. For example, the confirmation unit 11 refers to the thread management data 2 for each thread and identifies the core to which the thread having the specified thread identifier 21 is assigned.

Also, the confirmation unit 11 confirms the type of thread. For example, the confirmation unit 11 confirms whether the thread is a user thread or a worker thread. Specifically, the confirmation unit 11 refers to the thread management data 2 of the thread and confirms the worker flag 24 of the thread.

Also, the confirmation unit 11 refers to the executable queue 31 and the standby queue to confirm the allocation status of threads to each core. For example, the confirmation unit 11 confirms whether there is a core with an empty executable queue in each core. Alternatively, the confirmation unit 11 may confirm whether or not an isolated worker exists in the executable queue 31 for threads associated with each core.

The selection unit 12 selects a core based on the result of confirmation by the confirmation unit 11, for example. Further, the selection unit 12 selects the free core as a thread allocation destination. Alternatively, the selection unit 12 selects a core in which a thread of the same thread group as that of the isolated worker exists in the executable queue 31 of another core. The selection unit 12 may select a core for which a thread of the same thread group as that of the worker exists in either the executable queue 31 or the standby queue 32 . Alternatively, the selection unit 12 may preferentially select cores having threads of the same thread group in the executable queue 31 . The selection unit 12 may select another core as the allocation destination of the isolated worker.

The determining unit 13 determines to allocate threads to the cores selected by the selecting unit 12 . For example, the determining unit 13 determines to allocate threads to the executable queue 31 of the core selected by the selecting unit 12 .

The transfer unit 14 migrates threads (user threads, worker threads) for each core. For example, the transfer unit 14 migrates the worker to the executable queue 31 of the core selected by the selection unit 12 . The transfer unit 14 may migrate each thread group of threads.

The counting unit 15 counts the number of threads in the thread group. For example, the counting unit 15 refers to the thread management data 2 for each thread and counts the number of threads having the designated thread group identifier 22 . Note that the counting unit 15 may be included in the checking unit 11 .

The setting unit 16 sets priorities between threads in the same thread group. For example, the setting unit 16 sets the priority of the worker thread to be higher than the priority of threads belonging to the same thread group as the worker thread.

The operation of the scheduler 1 according to the first embodiment will be explained using the drawings. The scheduling of workers by scheduler 1 is detailed.

First, the scheduling when the scheduler 1 generates threads will be described. FIG. 3 is a flow chart showing the operation of the scheduler 1 when creating threads. The confirmation unit 11 confirms the thread management data 2 of the threads related to each core with respect to the executable queue 31 of each core. At this time, the confirmation unit 11 confirms whether or not an isolated worker exists in the executable queue 31 for the thread associated with each core (step S101). An isolated worker is one in which the thread is a worker in the executable queue 31 of each core and there is no other thread in the same thread group as the worker.

If there is an isolated worker (Yes in step S101), the selection unit 12 selects a core in which a thread of the same thread group as the isolated worker exists in the executable queue 31 of another core (step S102). The transfer unit 14 migrates the isolated worker to the executable queue 31 of the selected core (step S103).

Next, the confirmation unit 11 confirms whether there is a core with an empty executable queue 31 in each core (step S104). A free core is also called a free core.

If there is a free core (Yes in step S104), the selection unit 12 selects the free core as the allocation destination of the generated thread (step S105). The determination unit 13 determines to allocate the generated thread to the executable queue 31 of the core selected in step S105 (step S109).

On the other hand, if there is no free core (No in step S104), the confirmation unit 11 of the scheduler 1 refers to the thread management data 2 of the thread to be generated and confirms the worker flag 24 (step S106).

When the worker flag 24 is True, that is, when the thread to be created is a worker, the setting unit 16 of the scheduler 1 sets the priority of the thread to high. Priority is set to be higher than other threads. For example, the setting unit 16 sets the priority of the worker thread to be higher than the priority of threads belonging to the same thread group as the worker thread. For example, by increasing the priority of a thread, it is possible to guarantee that it will run immediately after being scheduled.

The selection unit 12 selects a core that has a thread in the same thread group as the worker in either the executable queue 31 or the standby queue 32 (step S107). Specifically, the selection unit 12 selects the same thread group as the worker thread group (a set of threads forming the user process) from the thread management data 2 of the threads in the executable queue 31 and the standby queue 32 of each core. Pick one thread with identifier 22 . The selection unit 12 selects a core to which the selected thread is assigned. In step S<b>107 , the selection unit 12 preferentially selects cores having threads of the same thread group in the executable queue 31 . The determination unit 13 determines to allocate the thread to the executable queue 31 of the core selected in step S107 (step S109).

On the other hand, if the worker flag 24 is false, the selection unit 12 selects the allocation destination core based on the normal scheduling function (step S108). Finally, the thread is scheduled in the executable queue 31 of the core selected in any of step S108 (step S109).

As an option for core allocation during thread generation, it is conceivable not to perform the operations of steps S101, S102, S103, S104, and S105. Also, if it is determined that the number of times of migration should be reduced from the cost associated with migration, the scheduler 1 performs scheduling according to step S107 when generating workers.

Next, the operation when the scheduler 1 transitions a certain thread from the waiting state to the ready state will be described. FIG. 4 is a flow chart showing an example of the operation of the scheduler 1 when a thread transitions from the waiting state to the ready state.

The confirmation unit 11 of the scheduler 1 confirms whether there is an isolated worker in a different thread group in the executable queue 31 for the core to which the thread is assigned (step S201).

If there is no isolated worker (No in step S201), the transfer unit 14 moves the thread management data 2 of the thread transitioning from the standby state to the executable state from the standby queue 32 to the executable queue 31 ( step S206).

If there is an isolated worker (Yes in step S201), the confirmation unit 11 confirms whether there is another core with an empty executable queue (step S202).

If there is another core with an empty executable queue 31 (Yes in step S202), the selection unit 12 selects the other core as an allocation destination for the isolated worker (step S203). The transfer unit 14 migrates the worker to the executable queue 31 of the other core selected in step S203 (step S205).

On the other hand, if there is no other core with an empty executable queue 31 (No in step S202), the selector 12 selects a worker thread group based on the thread management data 2 of the threads in the executable queue 31 of each core. One thread having the same thread group identifier 22 as the identifier 22 is selected. The selection unit 12 selects a core to which the selected thread is assigned (step S204). The transfer unit 14 migrates the worker to the executable queue of the core selected in step S204 (step S205).

The transfer unit 14 moves the thread management data 2 of the thread transitioning from the standby state to the executable state from the standby queue 32 to the executable queue 31 (step S206).

As an option for the operation of the scheduler 1, only step S204 may be performed among the operations of the scheduler 1 shown in FIG. 4 in order to reduce the number of migrations. In this case, for the core to which the thread that transitions from the wait state to the ready state is assigned, there must be an isolated worker in a different thread group in the ready queue 31 and no other core with an empty ready queue 31. is the premise.

Next, the scheduler 1 migrates threads, terminates threads, or transitions from the ready state to the waiting state to create a space in the ready queue and to rebalance process migration operations. FIG. 5 is a flow chart showing another example of the operation of the scheduler 1. FIG.

The operation of scheduler 1 to migrate threads will be explained. The counting unit 15 of the scheduler 1 counts the number of threads in the thread group in the executable queue 31 for the threads selected for migration. Specifically, the counting unit 15 refers to the thread management data 2 of threads to be migrated, and counts the number of threads having the specified thread group identifier 22 .

The confirmation unit 11 refers to the counting result of the counting unit 15 and confirms whether the number of threads in the thread group is 2 (step S301). When the number of threads in the thread group is 2 (Yes in step S301), the scheduler 1 checks whether a worker exists in the thread group of the thread (step S302). If workers exist, perform migration for each thread group. If the number of threads is not 2 (No in step S301), the scheduler 1 terminates the process.

Next, the operation of scheduler 1 to terminate threads will be described. First, the confirmation unit 11 of the scheduler 1 confirms the thread group identifier 22 of the thread to be terminated, and confirms whether the number of threads in the thread group is 2 (step S301).

If the number of threads is 2 (Yes in step S301), the worker flag 24 of the thread that is not in the end process, that is, the remaining thread is checked (step S302). If the remaining thread is a worker (Yes in step S302), the worker also performs termination processing (step S303). After that, the target thread is terminated (step S304).

If the number of threads is not 2 (No in step S301), terminate the target thread.

(Modification)
For ease of implementation, instead of two queues, the executable queue 31 and the standby queue 32, one task list may be managed. In that case, if the threads registered in the task list are regarded as threads connected to the executable queue 31, this embodiment can be applied. In this case, since there is no waiting queue 32, there is no operation of the scheduler 1 when the thread shown in FIG. 4 is changed from the waiting state to the ready state.

Also, in the first embodiment, the configuration of the scheduler 1 may be such that at least one of the confirmation unit 11, transfer unit 14, counting unit 15, and setting unit 16 is omitted.

Although the configuration of the first embodiment has been described above, the present embodiment is not limited to the above example.

According to the scheduler 1 of the first embodiment, performance degradation related to context switching can be suppressed. The reason for this is that in scheduling when worker threads are generated in a state in which threads are assigned to each core and there are no free cores, the selection unit 12 assigns Select a core that has a thread in the same thread group as the worker thread to be created. The determining unit 13 determines to allocate the worker thread to be generated to the selected core.

For example, context switches between user threads that require worker processing and unrelated threads are suppressed.

Alternatively, if the number of user threads is less than or equal to the number of cores and the number of workers is less than or equal to the number of user processes, there will only be workers on the cores that are woken up by certain user threads and their signal handlers. This prevents context switching between workers when multiple workers are scheduled on the same core. For example, it is possible to provide a scheduler that allows workers to operate while preventing performance degradation on architectures where the cost of context switching is high.

(Second embodiment)
Next, the scheduler 1 according to the second embodiment will be explained using the drawings. The scheduler 1 of the second embodiment schedules and allocates threads to a plurality of cores in the same manner as in the first embodiment. The scheduler 1 of the second embodiment also schedules threads using the thread management data 2 shown in FIG. 1 of the first embodiment. In the second embodiment, the content of thread management data 2 is the same as in the first embodiment. Also in the second embodiment, it is assumed that there are an executable queue 31 and a standby queue 32 as queues representing the scheduling of threads associated with each core. If the thread management data 2 of the thread exists in either the executable queue 31 or the waiting queue 32 of the core, it is said that the thread is assigned to the core.

The configuration of the scheduler 1 of the second embodiment will be described. FIG. 6 is a block diagram showing an example of the configuration of a scheduler according to the second embodiment. A scheduler 1 shown in FIG. 6 includes a selection unit 12 and a determination unit 13 . In the description of the second embodiment, substantially the same components as those of the first embodiment are denoted by the same reference numerals, and detailed description thereof will be omitted. Note that the scheduler 1 of the second embodiment is assumed to have a function as a scheduler normally possessed by the OS.

The following description of the scheduler 1 of the second embodiment is an example of scheduling when worker threads are generated in a state in which threads are assigned to each core and there are no free cores.

The selection unit 12 selects cores for which threads of the same thread group as the worker thread to be generated exist in the executable queue of each core.

The decision unit 13 decides to allocate the worker thread to be generated to the selected core.

The operation of the scheduler 1 according to the second embodiment will be explained using the drawings. In the following description, the scheduling of workers by scheduler 1 is detailed.

Scheduling when scheduler 1 generates threads will be explained. FIG. 7 is a flowchart showing the scheduling operation when threads are generated.

The selection unit 12 selects a core in which a thread in the same thread group as that of the worker exists in the executable queue 31 (step S401). Specifically, the selection unit 12 selects one thread having the same thread group identifier 22 as the thread group of the worker based on the thread management data 2 of the threads in the executable queue 31 of each core. The selection unit 12 selects a core to which the selected thread is assigned. The selection unit 12 may preferentially select cores for which threads of the same thread group exist in the executable queue 31 .

The determining unit 13 schedules the worker threads generated in the executable queue 31 of the core selected in step S401 (step S402).

According to the scheduler 1 of the second embodiment, performance degradation related to context switching can be suppressed. The reason for this is that in scheduling when worker threads are generated in a state in which threads are assigned to each core and there are no free cores, the selection unit 12 assigns Select a core that has a thread in the same thread group as the worker thread to be created. The determining unit 13 determines to allocate the worker thread to be generated to the selected core.

This allows the user thread and its worker threads to suppress context switches between unrelated threads.

For example, if the number of user threads is less than or equal to the number of cores and the number of workers is less than or equal to the number of user threads, there will only be workers on the cores that are activated by certain user threads and their signal handlers. That is, no context switch occurs. Therefore, it is possible to schedule workers to operate while preventing performance degradation on architectures where the cost of context switching is high.

Alternatively, if the number of user threads is less than or equal to the number of cores and the number of workers is less than or equal to the number of user threads, there will only be workers on the cores that are awakened from certain user threads and their signal handlers. This prevents context switching between workers when multiple workers are scheduled on the same core. For example, it is possible to provide a scheduler that allows workers to operate while preventing performance degradation on architectures where the cost of context switching is high.

The scheduler 1 of the first and second embodiments can be applied, for example, to an architecture in which the cost of context switching is high and it is desirable to keep the number of threads below the number of cores in order to avoid performance degradation of the user program. For example, the scheduler 1 can be applied as an operating system scheduler for use in heterogeneous computers, computer systems, and heterogeneous computers in which an accelerator is installed in the host.

(Hardware configuration)
The scheduler 1 described above is realized by executing a program (software program, computer program) in the CPU 91 (Central Processing Unit) of the computer 90 shown in FIG. Specifically, it can be realized by executing a program as the function of each component in the scheduler 1 according to the first and second embodiments or the operation of the scheduler 1 . These components or operations are performed by the CPU 91 reading a program 94 from a ROM (Read Only Memory) 93 or a storage device 95, and executing the read program, for example, according to the procedures of the flow charts shown in FIGS. It may be realized by executing using a CPU 91 and a RAM (Random Access Memory) 92 as described above. In such a case, the present disclosure, which has been described with the above-described embodiment as an example, is considered to be configured by a computer-readable storage medium storing code representing such a computer program or code representing the computer program. be able to. The computer-readable storage medium is, for example, the storage device 95, a removable magnetic disk medium (not shown), an optical disk medium, a memory card, or the like. Note that the components of each embodiment may be dedicated hardware in the form of integrated circuits.

The present disclosure is not limited to the above-described embodiments, and various modifications are possible. Included in the technical scope.

The first and second embodiments described above are exemplary examples. The present disclosure is not limited to the embodiments described above. That is, within the scope of the present disclosure, various aspects that can be understood by those skilled in the art can be applied to the present disclosure.

This application claims priority based on Japanese Patent Application No. 2021-015377 filed on February 3, 2021, and the entire disclosure thereof is incorporated herein.

1 scheduler 2 thread management data 11 confirmation unit 12 selection unit 13 determination unit 14 transfer unit 15 counting unit 16 setting unit 21 thread identifier 22 thread group identifier 23 priority 24 worker flag 31 executable queue 32 standby queue

Claims

If threads are assigned to each core and there are no free cores,
selection means for selecting a core among the cores in which a thread belonging to the same thread group as a worker thread to be generated exists in the executable queue or the standby queue of each core;
determining means for determining to allocate the generated worker thread to the selected core;
scheduler.
The selection means preferentially selects cores having threads of the same thread group in the executable queue from among the cores.
A scheduler according to claim 1.
further comprising setting means for setting a priority indicating the degree of priority between threads in the same thread group to the worker thread to be generated higher than other threads;
A scheduler according to claim 1 or 2.
further comprising checking means for checking whether the thread is a user thread or a worker thread;
A scheduler according to any one of claims 1-3.
The confirming means confirms whether there is a core in which the executable queue is empty in each of the cores.
A scheduler according to claim 4.
The confirming means confirms whether or not an isolated worker thread in which no other thread belongs to the same thread group as the generated worker thread exists in the executable queue of each core.
A scheduler according to claim 4 or 5.
If threads are assigned to each core and there are no free cores,
Selecting, from among the cores, a core in which a thread of the same thread group as the worker thread to be generated exists in the runnable queue or the wait queue of each core;
A scheduling method that determines to assign the generated worker threads to the selected cores.
If threads are assigned to each core and there are no free cores,
Selecting, from among the cores, a core in which a thread of the same thread group as the worker thread to be generated exists in the runnable queue or the wait queue of each core;
Storing a program that causes a computer to determine to assign the generated worker threads to the selected cores;
computer readable storage medium;