JP2014096024A - Control program for multi-core processor, electronic apparatus, and control method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a control program for multi-core processor, an electronic apparatus, and a control method such that a menu core processor can improve a throughput by actualizing an SMP model, and secure real-time properties by securing an execution time of a thread of high priority.SOLUTION: A control program for multi-core processor includes: a global scheduler 21 which determines an operation core 10 of a generated thread; and local schedulers 31 each provided for a plurality of cores 10. The local scheduler 31 makes its core 10 execute a thread assigned thereto according to the priority. The global scheduler 21 determines execution of thread migration between the plurality of cores 10 based upon a predetermined scheduling policy. Here, top 10 threads of high priority among threads allocated to the respective cores 10 are not objects of thread migration.

Description

  The present invention relates to control of a multi-core processor having a plurality of cores. In particular, the present invention relates to a control program, an electronic device, and a control method that can achieve both improvement in throughput and real-time performance in a processor incorporating a large number of cores.

  Conventionally, many of these types of multi-core processors use different types of cores. Such a configuration using different types of cores is employed to improve performance per power consumption by providing a core for a specific application. However, considering rapid progress in process technology and the like, it is expected that it will become increasingly difficult to secure the superiority of chips for specific application applications. Under such circumstances, it is considered that the number of chips having a more scalable configuration, that is, a homogeneous core is increased. In recent years, the number of cores incorporated in a single chip tends to increase. According to the configuration using such a homogeneous core, even if the number of cores increases, the number of cores can be easily accommodated. It is also expected to promote the increase in

  By the way, the most common approach for managing runtime software is to use an operating system, and an operating system corresponding to the multi-core processor is used to control the multi-core processor. In a multi-core environment where the number of cores is about 4 at the maximum, an operating system that performs control by using either an asymmetric multi-processing (AMP) model or a symmetric multi-processing (SMP) model is used.

  AMP is a processing method for fixing a core on which a thread is executed, and is widely used because it avoids thread migration and cache-related problems and easily secures real-time processing. This AMP is advantageous when the number of cores is relatively small, but as the number of cores increases, processing costs such as communication between cores, device sharing, and service sharing cannot be tolerated. Occur. The hypervisor-based partitioning model is an AMP model in principle, and has the same problem.

  Thus, although AMP is effective when the number of cores is relatively small, there is a limit to the response to the increase in the number of cores, so in the present situation where a further increase in the number of cores is expected, scalable SMP There is a strong demand to improve throughput with operating systems that employ models.

  However, when an SMP model operating system is implemented in a many-core processor having eight or more cores, a new problem of insufficient cache coherency or high cost occurs. For example, the exclusive control of the shared memory is complicated and expensive, which becomes a bottleneck given to the entire process. In the SMP model, thread migration that changes the operating core of the thread is executed. There is a problem that increases. Note that most many-core processors do not provide hardware / cache coherency mechanisms, and even in rare many-core processors with cache coherency, the cost of maintaining coherency between cores in a chip is Compared to a processor with a small number of cores, the cost is much higher.

  As described above, when the SMP model is adopted in order to increase the throughput, there is a problem in that bottlenecks and overhead occur as tradeoffs, and real-time performance is sacrificed. In this regard, although there are a plurality of prior studies on the control of the many-core processor (see, for example, Non-Patent Document 1), it is mainly intended for server processing, and is a field that requires real-time performance, such as an embedded system. Because it is not a study in Japan, there was little discussion about scheduling to ensure real-time performance.

David Wentzlaff et al., "An Operating System for Multicore and Clouds: Mechanisms and Implementation", MIT Open Access Articles, [online], Internet <URL: http://dspace.mit.edu/openaccess-disseminate/1721.1/62570>

  The present invention realizes an SMP model in a many-core processor to improve throughput, and also guarantees a high-priority thread execution time to ensure real-time performance, a multi-core processor control program, an electronic device, and a control method It is an issue to provide.

  The present invention has been made to solve the above-described problems, and is characterized by the following.

(Claim 1)
The control program for a multi-core processor according to claim 1 is a control program for a multi-core processor having a plurality of cores, and is provided for each of the plurality of cores, a global scheduler that determines an operating core of a generated thread. A local scheduler, wherein the local scheduler schedules threads assigned to the own core according to priority and executes the threads in the own core, and the global scheduler executes the plurality of the plurality of threads based on a predetermined scheduling policy. Thread migration between cores is determined and thread migration is performed for the top N threads (N is a predetermined natural number of 1 or more) with high priority among threads assigned to each core. It is characterized by not being subject to

(Claim 2)
The invention described in claim 2 has the following features in addition to the features of the invention described in claim 1 described above.

  That is, the global scheduler maps high-priority top M threads (M is the number of cores to which threads can be assigned) among all generated threads so that the operating cores of the threads are different from each other. It is characterized by that.

(Claim 3)
The invention described in claim 3 is characterized by the following points in addition to the characteristics of the invention described in claim 1 or 2.

  In other words, the global scheduler determines a thread and a core to be migrated based on a result of periodically checking a load balance of threads among the plurality of cores.

(Claim 4)
A fourth aspect of the present invention is an electronic device equipped with the control program for the multi-core processor according to any one of the first to third aspects.

(Claim 5)
The multi-core processor control method according to claim 5 is a multi-core processor control method that operates on a multi-core processor having a plurality of cores and performs thread scheduling by a local scheduler provided for each of the plurality of cores. A step of determining an operating core of the generated thread, a step in which the local scheduler schedules a thread assigned to the own core according to priority and executes the thread in accordance with a priority, and a predetermined scheduling policy. Executing thread migration between the plurality of cores, and among the threads assigned to each core, the top N threads with high priority (N is a predetermined natural number of 1 or more) are threads. No migration is performed And features.

(Claim 6)
The invention described in claim 6 has the following characteristics in addition to the characteristics of the invention described in claim 5.

  In other words, among the generated threads, high-priority top M threads (M is the number of cores to which threads can be assigned) are mapped so that the operating cores of the threads are different from each other. .

(Claim 7)
The invention described in claim 7 is characterized by the following points in addition to the characteristics of the invention described in claim 5 or 6.

  That is, the thread and core to be migrated are determined based on the result of periodically checking the load balance of threads among the plurality of cores.

  According to the first aspect of the present invention, the thread is executed by a two-stage schedule by the global scheduler and the local scheduler. The global scheduler determines the operating core of the generated thread and determines the execution of thread migration based on a predetermined scheduling policy. For this reason, threads can be allocated to each core almost evenly, and hardware resources can be effectively used to improve throughput.

  Also, among the threads assigned to each core, the top N threads with the highest priority (N is a predetermined natural number equal to or greater than 1) are not subject to thread migration. Rather, the highest priority execution in the assigned core is guaranteed. For this reason, the execution time of a high-priority thread that requires real-time performance can be guaranteed, so that real-time performance can be ensured.

  Further, the invention according to claim 2 is as described above, and the global scheduler has the highest priority among the generated threads of the top M threads (M is the number of cores to which threads can be allocated). Map so that the operating core of each thread is different from each other. In other words, the same number of threads as the number of cores to which threads can be allocated can be guaranteed to be executed in the order of priority, so the execution time of these high priority threads can be guaranteed and real-time performance can be ensured. be able to.

  Further, the invention according to claim 3 is as described above, and the global scheduler determines the thread and core to be migrated based on the result of periodically checking the load balance of threads among a plurality of cores. , Load balance can be maintained in an optimum state, and throughput can be improved.

  In addition, thread migration is not always executed, but thread migration is executed based on the results of periodic inspections. Therefore, thread migration does not occur frequently and the load balance does not change. Therefore, the cost of thread migration can be suppressed. In particular, when shared memory is not used to avoid bottlenecks and cache coherency problems (local memory for each core is used), a copy of local memory is required during thread migration, so thread migration costs are reduced. It becomes a problem. However, according to the control of the present invention, the cost associated with thread migration can be suppressed by minimizing the number of thread migrations. In other words, while maintaining throughput and real-time performance, bottlenecks and The problem of cache coherency can be avoided.

  The invention according to claim 4 is as described above, and an electronic device equipped with a control program that exhibits the above-described effects can be obtained.

  According to claim 5, the same effect as that of the invention of claim 1 can be obtained.

  According to claim 6, the same effect as that of the invention of claim 2 can be obtained.

  According to claim 7, the same effect as that of the invention of claim 3 can be obtained.

It is a conceptual diagram which shows the outline | summary of a system. It is a figure explaining a scheduling policy. (A) Calculation formula of workload for each core, (b) Calculation formula of variation in load balance. It is a flowchart of a thread production | generation process. It is a flowchart of a thread deletion process. It is a flowchart of a load balancing process.

  Embodiments of the present invention will be described with reference to the drawings.

(Basic system configuration)
The system according to this embodiment is an embedded system that is used by being incorporated in an electronic device, and includes a multi-core processor (a many-core processor). As shown in FIG. 1A, this multi-core processor includes a plurality of cores 10 (64 cores 10 in FIG. 1A). A non-volatile memory built in the electronic device stores a control program (operating system) for controlling the multi-core processor, and various applications 25 are executed by executing the control program on the multi-core processor. It is formed to be.

  In this system, there is no hardware cache coherency mechanism. In addition, although there is a shared memory shared by the core 10, since access is expensive, the microkernel 30 described later does not use this shared memory, and uses a local memory for each core 10. .

  The plurality of cores 10 are divided into an OS server execution core 11 and an application execution core 12 as shown in FIG. The OS server execution core 11 is a core 10 that executes the OS server 20 that forms part of the control program. The application execution core 12 is a core 10 that executes an application 25 such as a user application, middleware, or driver. Each of the OS server 20 and the application 25 is assigned to the core 10 as a thread and executed. Note that which core 10 is to be the OS server execution core 11 or the application execution core 12 may be statically determined in advance, or may be dynamically determined by assignment of a global scheduler 21 described later. It is good. When dynamically determined by the assignment of the global scheduler 21, when the OS server 20 is shifted to the execution standby state in the OS server execution core 11, the application 25 is executed in the OS server execution core 11, and the OS server execution core 11 may change to the application execution core 12.

  The OS server 20 executes various functions provided by the operating system as threads. Then, as one of these OS servers 20, a global scheduler 21 that determines the operating core 10 of the generated thread is executed. The global scheduler 21 determines the operation core 10 of the generated thread based on a predetermined scheduling policy, and determines execution of the change (thread migration) of the operation core 10 of the thread. Details of the global scheduler 21 will be described later.

  As shown in FIG. 1A, each core 10 is provided with microkernels 30 forming a part of the control program in a distributed manner for each core 10. The microkernel 30 includes a local scheduler 31, a message manager 32, a memory manager 33, and an interrupt manager 34 as shown in FIG.

  The local scheduler 31 schedules the threads assigned to the own core 10 according to the priority and executes them on the own core 10. For example, when three threads are assigned by the global scheduler 21 to the core 10 controlled by a certain local scheduler 31, the local scheduler 31 preferentially executes the thread having the highest priority among the three threads. When the highest priority thread enters the standby state, the next highest priority thread is executed. Only when the top two threads enter the standby state, the lowest priority thread is executed. Schedule to run. Then, when a thread having a higher priority than the executing thread becomes executable, the executing thread is stopped and switched to a higher priority thread for execution.

  The message manager 32 has a function of messaging to other threads. The message manager 32 also has a messaging function to the OS server 20. For example, when the application thread 42 calls a kernel API (for example, generation / deletion of a thread), the kernel API is called using the interface library 41 of each core 10, and the message manager 32 is stored in the interface library 41. Is used to call the OS server 20 (executed by the other core 10). As described above, the communication between the cores 10 is executed using the message manager 32 and the processing request / response processing waiting for the OS server 20 is performed. Can be called.

  The memory manager 33 manages local memory for each core 10 allocated to the own core 10. In other words, this system is configured to avoid the bottleneck and cache coherency problems by using the local memory for each core 10 without using the shared memory that is expensive to access. The memory manager 33 manages the local memory. The memory manager 33 manages a memory image associated with, for example, thread generation / deletion.

  The interrupt manager 34 is for performing interrupt management of the processing of the own core 10. When an interrupt request is generated, the interrupt manager 34 switches the processing of the core 10 so as to interrupt the current processing and execute the interrupt processing.

(About thread groups)
The global scheduler 21 determines and changes the operating core 10 of the thread based on a predetermined scheduling policy. One basic idea of the scheduling policy of the global scheduler 21 is to divide a thread group assigned to each core 10 into a “priority higher thread group” and a “priority lower thread group”. The “priority upper thread group” is the upper N threads with higher priority among the threads assigned to each core 10. The “priority lower thread group” is a low-priority thread not included in the “priority upper thread group” (see FIG. 2. Note that in FIG. 2, the number of cores 10 is simplified to four. However, this is for convenience of explanation, and a large number of cores 10 as shown in FIG. 1 are actually incorporated).

  The difference between the “priority higher-level thread group” and the “priority lower-level thread group” is whether or not a thread migration target. Threads belonging to the “priority upper thread group” are not subject to thread migration, and threads belonging to the “priority lower thread group” are subject to thread migration.

  The threads belonging to the “priority higher thread group” are not thread-migrated as long as they belong to the “priority higher thread group”, and therefore are preferentially executed in the assigned core 10. For this reason, the execution time of a high-priority thread that requires real-time performance can be guaranteed, so that real-time performance can be ensured.

  In this embodiment, N = 1 is set, and only one thread belongs to the “priority higher-level thread group” of each core 10. For this reason, the threads belonging to the “priority higher-level thread group” always transition to the execution state when in the executable state, so that the execution is always guaranteed.

(Determination of the operating core 10 of the generated thread)
Next, how the operation core 10 of the generated thread is determined will be described.

  The global scheduler 21 determines the operation core 10 of the thread generated based on the following scheduling policy. That is, among all the generated threads, the top M threads with the highest priority (M is the number of cores 10 to which threads can be assigned) are mapped so that the operation cores 10 of the threads are different from each other. In this embodiment, since M = 64, the high-priority upper 64 threads are mapped to be executed by different cores 10 respectively. In other words, each core 10 is mapped to be the highest priority thread.

  Hereinafter, a specific behavior of the global scheduler 21 will be described with reference to a flow chart of the thread generation process of FIG.

  The thread generation process shown in FIG. 4 is executed, for example, when the application thread 42 issues a thread generation request (kernel API). When the global scheduler 21 receives the thread generation request, as shown in step S101 in FIG. 4, it is checked whether or not there is a vacancy in the higher priority thread group. If there is a vacancy in the higher priority thread group (in this embodiment, if the number of generated threads is smaller than the number of cores 10 to which threads can be assigned (= 64)), the process proceeds to step S102. . On the other hand, if there is no space in the higher priority thread group, the process proceeds to step S103.

  When the process proceeds to step S102, the global scheduler 21 issues a thread generation instruction to the core 10 in which the priority higher-order thread group has a vacancy. Thereby, a thread is created in the core 10, and the created thread belongs to the higher priority thread group.

  On the other hand, when the process proceeds to step S103, it is checked whether or not a thread having a lower priority than the generated thread exists in the higher priority thread group. If a thread having a lower priority than the generated thread exists in the higher priority thread group, the process proceeds to step S104. On the other hand, if a thread having a lower priority than the generated thread does not exist in the higher priority thread group, the process proceeds to step S105.

  When the processing proceeds to step S104, the global scheduler 21 issues a thread generation instruction to the core 10 having the lowest priority thread (referred to as the thread X) among the threads in the higher priority thread group. As a result, a thread is created in the core 10, and the created thread belongs to the higher priority thread group, and at the same time, the thread X moves from the higher priority thread group to the lower priority thread group.

  When the process proceeds to step S105, the global scheduler 21 issues a thread generation instruction to the core 10 having the smallest number of assigned threads. As a result, a thread is created in the core 10, and the created thread belongs to the low priority thread group.

  In the above-described flow, the global scheduler 21 always determines the thread operating core 10, but the thread operating core 10 may be designated to create a thread. For example, the operation core 10 may be designated by an argument of the kernel API. In this case, the global scheduler 21 directly issues a thread generation instruction to the designated core 10 without performing the processing of steps S101 to S105 described above.

(About thread deletion)
FIG. 5 is a flowchart of thread deletion processing. The thread deletion process will be described with reference to FIG.

  The thread deletion process shown in FIG. 5 is executed, for example, when the application thread 42 issues a thread deletion request (kernel API). When the global scheduler 21 receives this thread deletion request, the thread is deleted as shown in step S200 of FIG. Then, the process proceeds to step S201.

  In step S201, it is checked whether or not the deleted thread belongs to the higher priority thread group. If it does not belong to the higher priority thread group, the process ends. If it belongs to the higher priority thread group, the process proceeds to step S202.

  In step S202, the highest priority thread (referred to as thread Y) is extracted from the threads not belonging to the higher priority thread group, and whether or not this thread Y is assigned to the same core 10 as the deleted thread. Is checked. When the thread Y is assigned to the same core 10 as the deleted thread, the processing ends (this causes the thread Y to belong to the higher priority thread group instead of the deleted thread). If the thread Y is not assigned to the same core 10 as the deleted thread, the process proceeds to step S203.

  In step S203, the thread Y is migrated to the core 10 to which the deleted thread belongs. As a result, the thread Y belongs to the higher priority thread group in the core 10 to which the deleted thread belongs.

  As described above, when a thread belonging to the higher priority thread group is deleted, the threads are upgraded to the higher priority thread group in order from the highest priority thread.

(About thread migration)
The global scheduler 21 according to the present embodiment periodically checks the load balance of threads among the cores 10 when executing thread migration, and determines the migration target threads and the cores 10 based on the check results.

  As shown in FIG. 2, the load balance is calculated based on the priority of a thread (load measurement thread) in a ready (READY) state including a running (RUNNING) state.

  Specifically, the workload is calculated for each core 10 using the calculation formula shown in FIG. For example, the workload of “Core 0” illustrated in FIG. 2 is (256-1) ^ 2 + (256-6) ^ 2 + (256-10) ^ 2 = 188,041.

  By substituting the calculated workload value into the calculation formula shown in FIG. 3B, the variation in load balance is calculated. Since it is determined that the smaller the value D derived from this calculation formula, the smaller the load balance variation and the higher the throughput, the global scheduler 21 executes thread migration so that the value D becomes smaller.

  FIG. 6 is a flowchart of load balancing processing including thread migration. The load balancing process by the global scheduler 21 will be described with reference to FIG.

  The load balancing process shown in FIG. 6 is called at a constant cycle such as 50 ms. In the present embodiment, the global scheduler 21 starts processing at a constant cycle by a timer interrupt.

  When the process starts, first, the workload of all the cores 10 is measured as shown in step S300 of FIG. Specifically, the global scheduler 21 issues a workload measurement instruction to each core 10, and each core 10 that has received the instruction calculates the workload using the formula shown in FIG. 3A and returns it to the global scheduler 21. To do. Then, the process proceeds to step S301.

  In step S301, the core 10 with the lowest load (the core 10 with the smallest workload) is selected as the “migration target” based on the workload measurement result of each core 10. The reason why the core 10 having the lowest load is selected as the migration target is that the purpose of the thread migration is defined as “effective use of the core 10 having a low load”. By limiting the purpose in this way, the calculation is not excessively complicated and the processing load is not increased. When the migration target is selected, the process proceeds to step S302.

  In step S302, for all the cores 10 other than the migration target, the load balance variation when the thread included in the core 10 (the highest priority thread in the low priority thread group) is migrated to the migration target is calculated. Is done.

  Specifically, assuming that the core 10 other than the migration target has moved the thread with the highest priority in the lower priority thread group to the migration target, the variation in load balance is calculated using the formula shown in FIG. calculate. This is calculated for all the cores 10 other than the migration target, and the combination with the smallest load balance variation is inspected. The reason why the thread to be migrated is the highest priority thread in the low priority thread group is that the purpose of the migration is defined as “maximizing the execution opportunity of the high priority thread”. By limiting the purpose in this way, the system is configured such that the number of load balance variation calculations is not excessive and the processing load does not increase. When the load balance variation is calculated, the process proceeds to step S303.

  In step S303, thread migration is executed with the combination calculated in step S302 when the load balance variation is minimized. If the variation in load balance is smaller when thread migration is not executed, the process is terminated without executing thread migration.

  According to the processing as described above, since thread migration is periodically performed, throughput can be improved. In the present embodiment, since the maximum number of threads that are thread-migrated in one load balancing process is one, the thread migration is suppressed from occurring excessively.

  Also, when performing thread migration, thread migration is performed based on variations in priority-based load balance instead of simply performing thread migration based on priority, while improving thread throughput. It is formed so that the number of times can be suppressed.

  In the above-described processing, the global scheduler 21 issues a workload measurement instruction to each core 10. However, the microkernel 30 of each core 10 sends the workload measurement result to the global scheduler 21 every predetermined time. You may make it transmit.

(Summary)
As described above, according to the present embodiment, threads are executed according to a two-stage schedule by the global scheduler 21 and the local scheduler 31. The global scheduler 21 determines the operation core 10 of the generated thread and also determines execution of thread migration based on a predetermined scheduling policy. For this reason, threads can be allocated to each core 10 almost equally, and the hardware resources can be effectively used to improve the throughput.

  In addition, since the top one thread with high priority among the threads assigned to each core 10 is not subject to thread migration, the high priority thread is not subjected to thread migration and is executed with the highest priority in the assigned core 10. Is guaranteed. For this reason, the execution time of a high-priority thread that requires real-time performance can be guaranteed, so that real-time performance can be ensured.

  The global scheduler 21 maps the high-priority upper 64 threads among all the generated threads so that the operation cores 10 of the threads are different from each other. In other words, the same number of threads as the number of cores 10 to which threads can be allocated can be guaranteed to be executed in descending order of priority, so the execution time of these high priority threads can be guaranteed and real-time performance can be ensured. can do.

  In addition, since the global scheduler 21 determines the migration target thread and the core 10 based on the result of periodically checking the load balance of the threads among the plurality of cores 10, the load balance can be maintained in an optimum state. And throughput can be improved.

  In addition, thread migration is not always executed, but thread migration is executed based on the results of periodic inspections. Therefore, thread migration does not occur frequently and the load balance does not change. Therefore, the cost of thread migration can be suppressed. In particular, when shared memory is not used (a local memory for each core 10 is used) in order to avoid bottlenecks and cache coherency problems, a copy of local memory is required during thread migration, so the cost of thread migration Is a problem. However, according to the control of the present embodiment, the cost associated with thread migration can be suppressed by minimizing the number of thread migrations. In other words, the bottleneck is achieved while ensuring throughput and real-time performance. And cache coherency problems can be avoided.

  In the above-described embodiment, the number M of cores 10 to which threads can be assigned is the same as the total number 64 of cores 10. However, the embodiment of the present invention is not limited to this. Only an arbitrary number of cores 10 out of the cores 10 mounted on the processor may be treated as cores 10 to which threads can be assigned. For example, the OS server execution core 11 may be determined in advance and excluded from the management of the global scheduler 21, and these cores 10 may be excluded from the cores 10 that can be assigned with threads. Specifically, when there are 64 cores 10, 8 of them are OS server execution cores 11, the remaining 56 are application execution cores 12, and the 56 application execution cores 12 can be assigned to threads. The core 10 may be a target of thread assignment or thread migration by the global scheduler 21.

  Moreover, although the case where the number of cores 10 was 64 was demonstrated in the above-mentioned embodiment, it cannot be overemphasized that it can respond to not only this but arbitrary number of cores 10 as embodiment of this invention.

  In the above-described embodiment, the workload and the load balance are calculated using the calculation formula shown in FIG. 3. However, the present invention is not limited to this, and other calculation formulas may be used. . For example, the priority weight may be changed by changing the multiplier.

  In the above-described embodiment, the number N of threads belonging to the “priority higher-level thread group” of each core 10 is set to “1”, but the embodiment of the present invention is not limited to this. The value of N may be a predetermined natural number equal to or greater than 1, and may be 2 or 3, for example. However, if the value is too large, the throughput will decrease, so it must be set to an appropriate value. If the number of cores 10 is large, even if N is a small value, execution of a sufficient number of high-priority threads can be guaranteed. In such a case, a small value (for example, the minimum value “ By setting it to 1 "), the throughput can be maximized while ensuring the real-time property.

  In the case of N> 1, it is desirable that the global scheduler 21 maps the operation core 10 of the high priority thread as follows. First, as already described, the high-priority top M threads among all the generated threads are mapped so that the operation cores 10 of the threads are different from each other. Then, the next high priority M threads (that is, the (M + 1) th to (M × 2) th priority) are mapped so that the operation cores 10 of the respective threads are different from each other. In this manner, the operation of dividing the high priority thread into M blocks and mapping the threads included in each block to different cores 10 is repeated N times. According to such processing, even when N> 1, it is possible to guarantee the execution of threads in descending order of priority.

10 core 11 OS server execution core 12 application execution core 20 OS server 21 global scheduler 25 application 30 microkernel 31 local scheduler 32 message manager 33 memory manager 34 interrupt manager 41 interface library 42 application thread

Claims (7)

A control program for a multi-core processor having a plurality of cores,
A global scheduler that determines the operating core of the generated thread;
A local scheduler provided for each of the plurality of cores;
With
The local scheduler schedules the threads assigned to the own core according to the priority and causes the own core to execute,
The global scheduler determines execution of thread migration between the plurality of cores based on a predetermined scheduling policy, and the top N high-priority threads (N is assigned to each core). A control program for a multi-core processor, wherein a thread of one or more predetermined natural numbers) is not subject to thread migration.   The global scheduler maps high-priority top M threads (M is the number of cores to which threads can be assigned) of all generated threads so that the operating cores of the threads are different from each other. The multicore processor control program according to claim 1, wherein   The multi-core processor according to claim 1 or 2, wherein the global scheduler determines a thread and a core to be migrated based on a result of periodically checking a load balance of threads among the plurality of cores. Control program.   An electronic device equipped with the control program for a multi-core processor according to claim 1. A control method of a multi-core processor that operates on a multi-core processor having a plurality of cores and performs thread scheduling with a local scheduler provided for each of the plurality of cores,
Determining the operating core of the generated thread;
Scheduling the local scheduler according to priority for threads assigned to its own core and executing it in its own core;
Performing thread migration between the plurality of cores based on a predetermined scheduling policy;
With
A method for controlling a multi-core processor, characterized in that thread migration is not executed for the top N threads (N is a predetermined natural number equal to or greater than 1) with high priority among threads assigned to each core.   The high-priority top M threads (M is the number of cores to which threads can be assigned) of all the generated threads are mapped so that the operating cores of each thread are different from each other. Item 6. A multicore processor control method according to Item 5.   The multicore processor control method according to claim 5 or 6, wherein a thread and a core to be migrated are determined based on a result of periodically checking a load balance of threads among the plurality of cores.

Images