JP2010182096A - Program parallel execution system and program parallel execution method on multi-core processor - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a parallel execution environment wherein overhead is reduced and the execution time is easily predicted on the multi-core processor of a general purpose CPU base. <P>SOLUTION: A plurality of processor cores of the multi-core processor 10 are divided into the processor cores of a first group for operating an operating system 20 and operating a first application program 21 on the operating system and the processor cores of a second group for operating a second application program 31 by a request from the first application without operating the operating system, and a control means is included for performing control for executing the second application program or receiving the processing result of the second application program by the first application program by performing communication between the processor cores of the first group and the processor cores of the second group. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a program parallel execution system including a multi-core processor in which a plurality of processor cores are interconnected by a bus, and a program parallel execution method on the multi-core processor.

  As a technique used when a single general-purpose CPU is insufficient in processing capacity, a dedicated hardware mechanism such as a moving image processing hardware is added, or a DSP (digital signal processor) or a 3D graphic processor There is a method of introducing a special processor having a calculation capability specialized for a use, such as a GPU (also referred to as a GPU), and performing a desired process in combination with a general-purpose CPU.

  For example, a portable device processor MP201 by NEC Electronics Corporation includes a general-purpose CPU ARM9, a DSP (K611) for image and sound processing, and an image processor and rotator for image processing. The desired moving image reproduction capability can be realized by performing the processing by the DSP.

  In this way, in addition to the general-purpose CPU, a related technology including a DSP for image and sound processing is described in Patent Document 1, for example.

  On the other hand, development of multi-core technology is progressing as one of the measures for improving the capacity of general-purpose CPUs. A multi-core processor is a combination of a plurality of single CPUs called “cores”, and high processing capability can be realized by parallel processing that moves multiple cores simultaneously.

  An example of a multi-core processor is MPCore by NEC Electronics / ARM. In MPCore, a plurality of (for example, four) ARM11 cores are combined in a single chip.

  Since a wide variety of processes in the system can be performed on a general-purpose CPU, it is a common practice to introduce an OS (operating system) and execute a number of tasks while switching them. In the multi-core processor, for example, various UNIX such as Linux, Microsoft Windows, etc. are used as an SMP (symmetric multi-processing) type OS.

  On a multi-core processor, high-speed processing of an application is possible by decomposing the application into several parts and executing them in parallel on multiple cores. For example, in a video playback application, when a video decoding process is composed of a plurality of tasks and execution of those tasks is started on Linux or Windows, these OSs allocate each task to each processor core, and use multi-core in parallel. The operation can be played back at high speed by the processing.

  For example, Patent Document 2 discloses a related technology relating to a multi-core processor that realizes high processing capability by parallel processing that moves a plurality of cores simultaneously.

  Thus, until now, when the processing capability of a single CPU is insufficient, a method has been used in which a dedicated hardware mechanism or special processor is introduced for processing, or processing is performed as a multi-core parallel application. Has been.

JP 2008-176699 A JP 2007-141155 A

  The problem of the related art described in Patent Document 1 is that it is expensive to introduce dedicated hardware and a special processor. If you develop a hardware mechanism that suits your purpose, such as graphics or video, you will be charged for the development, and if you procure it from the outside, you will have to pay a license. In recent years, with the diversification of systems, there has been a tendency to produce a wide variety of products in small quantities. However, when developing system LSIs that include these dedicated hardware or special processors, if the production volume is low, the development cost can be recovered. It may be difficult to do.

  The problem with the related art described in Patent Document 2 is that the execution overhead in a general-purpose CPU-based multicore increases. Since a general-purpose CPU is inferior in unit performance as compared with dedicated hardware or a special processor, parallel processing in which processing is shared by a plurality of cores is required to achieve desired performance. On the other hand, general-purpose CPUs usually have an OS installed to run a wide variety of tasks, and each task synchronizes and communicates with each other via OS services. Here, an overhead due to the OS occurs, and if synchronization or communication is performed in a fine unit, the overhead due to the OS cannot be ignored and a desired parallel performance may not be achieved.

  Another problem with the related art described in Patent Document 2 is that it is difficult to predict the execution time in a general-purpose CPU-based multicore. As described above, there are a wide variety of tasks on general-purpose CPUs, and these are executed in a time-sharing manner, so it is possible to predict when a specific task will be executed and how much real time will elapse. difficult. This is particularly a problem in real-time processing that requires completion of processing within a certain time.

(Object of invention)
An object of the present invention is to provide a program parallel execution system and a program parallel execution method on a multi-core processor that can realize a parallel execution environment with low overhead and easy execution time prediction on a general-purpose CPU-based multi-core processor. .

  Another object of the present invention is to provide a program parallel execution system and a program parallel execution method on a multi-core processor that can realize high arithmetic processing capability while suppressing the cost of introducing dedicated hardware and a special processor.

  A program parallel execution system according to the present invention is a program parallel execution system comprising a multi-core processor in which a plurality of processor cores are interconnected by a bus, the plurality of processor cores operating an operating system, and a first on the operating system. The first group of processor cores that operate the application program and the second group of processor cores that operate the second application program in response to a request from the first application without operating the operating system. By performing communication between the processor cores of the second group and the processor cores of the second group, the first application program causes the second application program to execute or the second application program. Comprising a control means for performing control for receiving a processing result of the application program.

  A program parallel execution method according to the present invention is a program parallel execution method on a multi-core processor in which a plurality of processor cores are interconnected by a bus, and an operating system is operated on a processor core of a first group of the plurality of processor cores. The first application program is operated on the operating system, and the second system is operated by a request from the first application without operating the operating system on the second group of processor cores of the plurality of processor cores. Causing the first application program to execute the second application program by operating the application program and performing communication between the first group of processor cores and the second group of processor cores; or It performs control for receiving a processing result of the second application program from the first application program.

  According to the present invention, it is possible to realize a parallel execution environment with less overhead and easy execution time prediction on a general-purpose CPU-based multi-core processor.

  In addition, high calculation processing capability can be realized while suppressing the cost of introducing dedicated hardware and a special processor.

1 is a block diagram showing an overall configuration of a program parallel execution system according to a first embodiment of the present invention. It is a block diagram which shows the internal structure of the lightweight scheduler in the program parallel execution system by 1st Embodiment. It is a figure which shows the structural example of each entry of the OL task table | surface in the program parallel execution system by 1st Embodiment. It is a block diagram which shows the internal structure of the OL remote control part in the program parallel execution system by 1st Embodiment. It is a flowchart which shows the operation | movement of OL task control in the program parallel execution system by 1st Embodiment. It is a flowchart which shows the operation | movement of the time division multiplexing control of the OL task in the program parallel execution system by 1st Embodiment. It is a figure which shows the list of the service function examples which the OL task service means in the program parallel execution system by 1st Embodiment provides. It is a block diagram which shows the whole structure of the program parallel execution system by the 2nd Embodiment of this invention. It is a block diagram which shows the internal structure of the OL remote control part in the program parallel execution system by 2nd Embodiment. It is a figure which shows the operation | movement of increase / decrease in the number of allocation cores in the program parallel execution system by 2nd Embodiment. It is a block diagram which shows the Example of the lightweight scheduler LS in 1st Embodiment. It is a block diagram which shows the Example of the OL remote control part in 1st Embodiment.

  Next, embodiments of the present invention will be described in detail with reference to the drawings.

(First embodiment)
FIG. 1 is a block diagram showing a configuration of a program parallel execution system according to the first embodiment of the present invention. The program parallel execution system according to the first embodiment has a configuration in which an application OS and a lightweight scheduler are mounted on a shared memory type multi-core processor.

  Referring to FIG. 1, a program parallel execution system according to the first embodiment operates on a multi-core SoC (System On Chip (system-on-chip); also referred to as system LSI) 10 having a plurality of CPU cores. AP OS (application OS) 20 and lightweight scheduler LS (LightweightScheduler) 32, application (AP) task group 21 and OL (offload) remote control unit 22 operating on the AP OS 20, and OL operating on the LS32 A task group 31 and a memory 50 used for these software operations are included.

  The multi-core SoC 10 drives a plurality of CPU cores (40, 41,..., 4n) of the same type, an inter-core interrupt mechanism 45 for interrupting between these CPU cores, and a memory 50. And a memory control unit 47 for connecting to each other via a SoC bus 46. As is the case with common processors in recent years, each CPU core includes an L1 cache (primary cache). The multi-core SoC shown in FIG. 1 shows a typical configuration example, and includes a processing unit (DMA controller, graphics processor, various I / O controllers, etc.) other than the illustrated components and a local memory. It may be.

  The CPU cores (40, 41,..., 4n) included in the multi-core SoC 10 are roughly divided into two groups for AP (application) processing and OL (offload) processing depending on the purpose of use. On the CPU core for AP (application) processing, a general-purpose CPU OS (for example, various UNIX OS such as Linux, Windows, etc.) operates as the AP OS 20. The AP tasks 210 and 211 constituting the AP task group 21 are linked to the OL task group operating on the CPU core for OL processing via the OL remote control unit 22 that is also executed on the AP OS 20. Works.

  The LS 32 operating on the CPU core for OL processing is a compact scheduler specialized for execution control of OL tasks, on which one or more OL tasks (OL tasks 310 and 311 in FIG. One is working)) is working. The LS32 is not simply a small OS with limited functions, but is a shared memory type multi-core processor, and the scheduling function is shared between the LS32 and the OL remote control unit 22. It is one of the features in the form.

  The OL tasks 310 and 311 are multi-thread tasks each composed of one or more threads. The OL tasks 310 and 311 are application programs designed so that a number of threads equal to or less than the number of OL processing CPU cores assigned to the LS 32 at the time of execution exist, and the LS 32 includes a plurality of OLs. Executes while switching between tasks by gang scheduling method. Here, the gang scheduling method is a method in which all necessary numbers of physical cores are secured at a time and task switching is performed.

  The AP processing CPU core and the OL processing CPU core may each be one or more.

  Next, the internal configuration of the lightweight scheduler LS32 in FIG. 1 will be described in detail with reference to FIG.

  The lightweight scheduler LS32 includes a time division multiplexing unit 110 for executing a plurality of OL tasks while switching in a time division manner, an AP communication unit 120 for performing communication with the AP processing CPU core side, and existing OL tasks. An OL task table 160 for management, a current OL task variable 150 indicating an OL task that is currently being executed, an OL task queue 140 that indicates an OL task that is currently waiting to be executed, and exclusive control when operating the OL task table OL task table lock variable 170 is included.

  The time division multiplexing unit 110 includes a timer 111 that notifies that a predetermined time has elapsed, and a time division multiplexing control unit 112 that switches an OL task based on a notification from the timer 111. The AP communication unit 120 includes an LS side reception unit 121 that receives communication from the AP side, and an LS side transmission unit 122 that transmits communication to the AP side.

  The LS 32 includes various means called from the time division multiplexing control unit 112, the LS side reception unit 121, and the OL tasks 310 and 311. The various means to be called include a context saving unit 131 that saves the context of the OL task that has been executed so far, a context restoration unit 132 that restores the context of the OL task to be executed and restarts the OL task, A new context selection means 133 for selecting an OL task to be executed next from the OL task queue 140; an OL task control means 134 for controlling the start and end of the OL task based on an instruction from the AP side; And OL task service means 135 for processing inter-thread communication in the OL task, cache control, and OL task end request.

  Here, FIG. 7 shows an example of a service function provided by the OL task service unit 135 for the OL task. These are expressed as machine instructions held by the CPU cores (40, 41, 42) in the multi-core SoC 10, for example, exchange instructions (XCHG etc.) for exchanging one word in the CPU register and one word in the memory atomically. Service functions that can be easily realized by using a cache control instruction or the like of a coprocessor attached to the CPU core. A programmer develops an OL program using these service functions. Further, if necessary, these service functions are implemented as inline functions, so that the runtime overhead can be further reduced.

  In the OL task table 160, one entry (OL task table entry) is registered for each OL task. This OL task table entry has fields as shown in FIG. In FIG. 3, the fields of the OL task table entry include an OL task ID field 161 for setting an integer value for uniquely identifying the OL task, an ID field 163 of the AP task that generated the OL task, and the AP task. AP OS ID field 162 for setting the identification ID of the OS on which the OS is operating, a status field 164 for setting information indicating whether the OL task is operating or not, and all the OL tasks are using A context field 165 for setting registers, special registers, etc., a time slice field 166 for defining the continuous execution time of the OL task, a semaphore field 167 for synchronizing the OL task and the AP task, and its OL Task program memory area This is a memory area information field 168 that holds information about the area and the working memory area.

  Here, the AP OS ID field 162 is an integer value for identifying the AP OS 20 in FIG. In the example of FIG. 1, since there is only one AP OS 20 in the system, there is no need for this ID. However, the multi-core SoC 10 has a large number of CPU cores, and a plurality of AP OSs 20 operate on that. In preparation for this, an ID for identifying the AP OS 20 is registered as shown in FIG.

  The AP task ID field 163 may be an ID for identifying a plurality of tasks in the AP OS 20, and normally the task ID used by the OS is used as it is.

  The AP communication unit 120 is oppositely connected to an AP side LS communication unit 240 described later.

  Next, the internal configuration of the OL remote control unit 22 located on the AP OS 20 in FIG. 1 will be described in detail with reference to FIG.

  The OL remote control unit 22 includes an AP task interface unit 230 that serves as an interface for the AP task to control the OL task, and an LS communication unit 240 that performs communication with the OL processing CPU core side.

  Further, the AP task interface unit 230 is assumed to be called from the AP task, and the LS initialization unit 231 for performing initial setting so that the LS 32 can operate on the OL processing CPU core, and thereby on the LS 32 in operation. A new offload processing program is newly loaded and set up in an executable state. OL program setup means 232, OL task setup means 233 for starting execution of the OL program set up by OL program setup means 232, and OL task start means 233 are started. OL task end waiting means 234 for waiting for the end of the completed OL task, OL task forcible end means 235 for forcibly ending without waiting for the voluntary end of the OL task, and reloading the OL task that has once ended O to return to the initial state Task reinitialization means 236, including the means of the OL program discarding means 237 to release resources to discard OL loaded program.

The LS communication unit 240 includes an AP-side transmission unit 241 and an AP-side reception unit 242 that perform transmission to the LS side and reception from the LS side, respectively, and the LS-side reception unit 121 and the LS-side transmission unit 122 respectively. Connected oppositely.

(Description of the operation of the first embodiment)
Next, the overall operation of the present embodiment will be described in detail with reference to the flowcharts of FIGS.

  First, a series of operations in which the AP task (0) 210 executes the OL task (0) 310 will be described with reference to FIG.

  Initially, the lightweight scheduler LS32 is not operating on the OL processing CPU core.

  Here, when the AP task (0) 210 calls the LS initialization unit 231 of the AP task interface unit 230 in the OL remote control unit 22 (step S101), the LS initialization unit 231 executes the LS32 program OL. The CPU core for processing is loaded into an accessible memory area (step S102), and each OL processing CPU core is instructed to start execution from the entry address of the LS32 program (step S103).

  When the LS 32 starts execution from the entry address, one of the OL processing CPU cores initializes the OL task table 160, the OL task queue 140, and the current OL task variable 150 (step S104). Then, it waits for an instruction from the AP side (step S105). The other CPU cores for the OL processing core immediately wait for an instruction from the AP side.

  When the AP task (0) 210 calls the OL program setup unit 232 of the AP task interface unit 230 in the OL remote control unit 22 (step S106), the OL program setup unit 232 reads the OL task table lock variable. 170 is locked to acquire exclusive access to the OL task table 160, and the OL task (0) 310 is loaded into a memory area accessible to the OL processing CPU core, and the OL task (0) 310 is processed. A working memory area is reserved (step S107). Subsequently, the OL program setup means 232 creates a new OL task table entry in the OL task table 160, and sets each field of the OL task table entry as follows (step S108).

(A) OL task ID field 161 = unique value assigned to the OL task (0) 310 by the OL program setup means 232
(B) AP OS ID field 162 = a value identifying the type of OS on which the AP task is operating.
(C) AP task ID field 163 = task ID in AP OS of AP task (0) 210.
(D) Status field 164 = initial state.
(E) Memory area information field 168 = information on memory area and working memory area loaded with OL task (0) 310.

  Subsequently, the OL program setup means 232 unlocks the OL task table lock variable 170 to release the exclusive access right, and returns the value of the OL task ID field 161 to the calling AP task (0) 210 as a return value. Return control. The value of the OL task ID field 161 is held inside the AP task (0) 210, and is passed as an argument when calling each means in the AP task interface unit 230 thereafter.

  Next, when the OL task start means 233 of the AP task interface unit 230 is called using the value of the OL task ID field 161 set by the AP task (0) 210 as an argument (step S109), the OL task start means 233 An entry corresponding to the value of the OL task ID field 161 set from the task table 160 is found, and the next field in the entry is set as follows (step S110).

(A) Context field 165 = register value for starting OL task (0) 310.
In particular, the program counter is the entry address of the OL task (0) 310, and if necessary, an appropriate address value in the OL task working memory area secured as a stack pointer or data pointer is given.
(B) Time slice field 166 = A value obtained by dividing the continuous execution time of the OL task (0) 310 by the operation period of the timer 111 (the reciprocal of the operation frequency).
When the OL task continues execution beyond this continuous execution time, the processing is temporarily interrupted by the time division multiplexing control unit 112. In a scene where a plurality of OL tasks operate simultaneously on the CPU core for OL processing, it is possible to give priority to these OL tasks by giving a longer continuous execution time to the OL task to be processed with higher priority. .
(C) Semaphore field 167 = initial value zero.

  After setting these fields, the OL task starting means 233 sends the OL task ID value and the information of the processing request type “OL task start” to the LS 32 side through the AP side transmission unit 241 of the LS communication unit 240 (step S111). . The AP processing CPU core returns control to the calling AP task (0) 210.

  On the other hand, the LS-side receiving unit 121 on the LS32 side receives the information transmitted from the AP-side transmitting unit 241, knows that the processing request type is “OL task start”, and performs the following processing as the processing corresponding thereto. Do. That is, an entry corresponding to the specified OL task ID value is searched from the OL task table 160, the status field 164 in the entry is set to “in-execution state”, and synchronization (barrier between all CPU cores for OL processing is set. After synchronization, the value of the context field 165 in the entry of the OL task table 160 is set in the register of each CPU core for OL processing to restore the context (step S112).

  As a result, the subsequent processing of the AP task (0) 210 is performed in the AP processing CPU core, and the processing of the OL task (0) 310 (step S113) is performed in parallel in the OL processing CPU core.

  Next, the AP task (0) 210 waits for the end of the OL task (0) 310 that has started, and waits for the OL task to end in the AP task interface unit 230 with the OL task ID value of the OL task (0) 310 as an argument. The means 234 is called (step S114). Then, the OL task end waiting unit 234 finds an entry corresponding to the OL task ID value from the OL task table 160, and performs a semaphore DOWN operation (sem_down) on the semaphore field 167 in the entry (step S115).

  On the other hand, the OL task (0) 310 side stores the processing result in an area on the memory 50 shared between the AP task (0) 210 and the OL task (step S116), and then the OL of the LS32 An OL task end request is sent to the task service means 135 (step S117).

  Then, the OL task service unit 135 of the LS 32 identifies an entry in the OL task table 160 from the value of the current OL task variable 150, and sets the status field 164 in the entry to “end state”. Furthermore, the OL task service unit 135 uses the AP OS (0) 210 that has started the OL task (0) 310 based on the value of the AP OS ID field 162 in the OL task table 160 entry. And the OL task ID value (the value of the OL task ID field 161 in the entry of the OL task table 160) and the information of the processing request type “OL task end” are sent to the AP OS 20 through the LS side transmission unit 122 ( Steps S118 and S119).

  Then, the AP side receiving unit 242 of the LS communication unit 240 receives this information, knows that the processing request type is “OL task end”, and performs the following processing as processing corresponding thereto. That is, an entry corresponding to the specified OL task ID value is found from the OL task table 160, and a semaphore UP operation (sem_up) is performed on the semaphore field 167 in the entry (step S120).

  By these two semaphore operations, the AP task (0) 210 and the OL task (0) 310 are synchronized, and the AP task (0) 210 resumes the operation immediately after the semaphore DOWN operation. The AP task (0) 210 reads the data from the shared area on the memory 50, and acquires the result of the process offloaded to the OL task (0) 310 (step S121).

  Here, when the AP task (0) 210 calls the OL task forced termination means 235 of the AP task interface unit 230 using the OL task ID value as an argument, the OL task forced termination means 235 executes the following steps. Attempts to forcibly terminate the existing OL task.

  As a first stage, an OL task forced termination request is transmitted to the LS 32 side by communication. Specifically, the OL task ID value of the OL task (0) 310 and information of the processing request type “OL task forced termination” are sent to the LS 32 side through the AP side transmission unit 241. On the LS 32 side, the LS-side receiving unit 121 receives this request, knows that the processing request type is “OL task forced termination”, and corresponds to the OL task (0) 310 from the OL task table 160 and the OL task queue 140. Delete the entry.

  If the LS32 side does not function normally due to an OL task runaway or the like, as a second step, the OL task forced termination means 235 of the AP task interface unit 230 resets each CPU core for OL processing. The OL task is stopped by calling. In this case, if an OL task other than the OL task (0) 310 is being executed in the OL processing CPU core, all of them including the OL task (0) 310 are stopped. Therefore, priority is given to the forced termination in the first stage mechanism, and this second stage treatment should be limited to emergency use.

  When the AP task (0) 210 calls the OL task reinitialization means 236 of the interface section 230 for the AP task with the OL task ID value of the OL task (0) 310 as an argument, the OL task reinitialization means 236 After the task table lock variable 170 is locked and exclusive access right to the OL task table 160 is obtained, an entry of the OL task in the OL task table 160 is searched, and the status field 164 in the entry is set to “initial state”. And the OL task table lock variable 170 is unlocked. As a result, the OL task (0) 310 returns to the initial state, and when the AP task (0) 210 calls the OL task start means 233, the OL task (0) 310 can be executed again. .

  Finally, when the AP task (0) 210 calls the OL program discarding unit 237 of the AP task interface unit 230 using the OL task ID value as an argument (step S122), the OL program discarding unit 237 sets the OL task table lock variable 170. After the exclusive access right to the OL task table 160 is obtained by locking, the entry of the OL task in the OL task table 160 is searched. Next, the OL program discarding unit 237 releases the memory area reserved for the OL task based on the value of the memory area information in the OL task table entry. Further, the OL program discarding unit 237 deletes the OL task table entry from the OL task table 160, and finally unlocks the OL task table lock variable 170 to return the exclusive access right (step S123).

  FIG. 5 shows an operation when the AP task (0) 210 calls the OL program discarding unit 237 of the AP task interface unit 230 using the OL task ID value as an argument.

  Here, the operation of communication between the OL remote control unit 22 and the lightweight scheduler LS32 will be described.

  The internal structure of this communication is not an essential feature of the present embodiment. It is possible to transmit two fixed-length integer values to a designated communication partner CPU core and call a pre-registered handler on the partner CPU core side. Any communication method can be used. As one implementation method, the inter-core interrupt mechanism 45 shown in FIG. 1 and the inter-core shared memory area on the memory 50 are used, and the integer value to be transmitted to the other party is stored in the shared memory area, and then the inter-core interrupt is performed. A mechanism may be considered in which an interrupt is generated in the partner core by the mechanism 45, a value stored in the shared memory area is read by the interrupt handler of the partner core, and a pre-registered handler function is called using the value as an argument.

  Next, with reference to FIG. 6 and FIG. 2, the operation of the time division multiplex processing when there are a plurality of OL tasks on the OL processing CPU core will be described. Here, a case will be described in which three tasks OL tasks (0) to (2) exist and the OL task (0) is currently being executed.

  Since the OL task (0) is currently being executed, the time slice value of the OL task (0) is set as an initial value in the timer 111 of the time division multiplexing unit 110. When the predetermined time elapses, the counter of the decrementing timer 111 reaches zero (step S201), and the timer 111 notifies the time division multiplexing control unit 112 of the time division multiplexing unit 110 (step S202). ).

  The time division multiplexing control unit 112 first calls the context saving unit 131. The context saving unit 131 checks the current OL task variable 150. If a valid OL task is stored in the current OL task variable 150, a set of contexts such as a register of the OL task (0) executed by each of the OL processing CPU cores so far is stored in the OL task (0). Is stored in the context field 165 in the entry of the OL task table 160 (step S203).

  Next, the time division multiplexing control unit 112 calls the new context selection unit 133 and determines an OL task to be executed next. Various selection methods can be considered. Here, a simple FIFO method will be described. That is, the new context selection unit 133 selects the OL task at the head of the OL task queue 140 as the next context (step S204). In the example of FIG. 6, OL task (1) is selected. The new context selection means 133 removes the selected OL task (1) from the OL task queue 140 and sets it in the current OL task variable 150.

  Next, the time division multiplexing control unit 112 calls the context restoration unit 132. The context restoration means 132 refers to the entry for the OL task (1) in the OL task table 160 indicated by the current OL task variable 150, sets the value of the time slice field 166 therein to the timer 111 (step S205), In accordance with the contents of the context field 165 of the OL task table entry, registers and the like of each OL processing core are set. Finally, after synchronizing all the OL processing cores, execution in the register context is started. Thereby, the context of the OL task (1) is resumed (step S206).

  Thereafter, when the time slice time set above elapses, the counter of the timer 111 reaches zero (step S207), the notification from the timer 111 to the time division multiplexing control unit 112 (step S208), and the time The context switching operation by the division multiplexing control unit 112 is repeated (steps S209 to S212).

  If no valid OL task is stored in the current OL task variable 150 in the context saving unit 131, it is considered that there is no context to be saved. In that case, the time division multiplexing control unit 112 does not perform the context saving process, and proceeds to the next call of the new context selection unit 133.

  In addition, when the OL task queue 140 is empty, the new context selection unit 133 sets an invalid value (such as NULL) in the current OL task variable 150 because no new context exists. In that case, the subsequent context restoration means 132 does not set the timer 111 or the new context in each OL processing core register. Each OL processing core shifts to the stopped state as it is, and then waits for notification of the start of the OL task from the AP processing core side.

  The above is the description of the operation for controlling a plurality of OL tasks by time division multiplexing, and a specific example of the flow is shown in FIG.

  In general, there are a plurality of OL processing CPU cores, and these CPU cores are provided with a task start instruction from the AP task side (see OL task start means 233) and timer 111 reaching zero (time division multiplexing from the timer 111). All CPU cores are switched simultaneously from OL task processing to LS processing or from LS processing to OL task processing. This is so-called gang scheduling, and is one of the features of the present embodiment for effectively performing fine parallel processing by the OL processing CPU core.

(Effects of the first embodiment)
Next, effects of the first embodiment described above will be described.

  In the present embodiment, a plurality of CPU cores of the multi-core SoC 10 (multi-core processor) are divided into two groups of AP processing CPU cores and OL processing CPU cores, and one AP processing CPU core is used for general applications. By operating the AP OS20 and placing the lightweight scheduler LS32 on the other OL processing CPU core, a special purpose program (OL task) that makes the most use of hardware resources such as the CPU core and cache function can be used for the OS. It can be run simultaneously with the application. An OL task that is a special purpose program can directly access hardware resources and specify the allocation time of those hardware resources to the OL task. Therefore, overhead during execution can be reduced, and execution time prediction is facilitated. This makes it possible to efficiently execute a plurality of threads that operate in close cooperation with each other.

  In other words, the OL task that operates on the CPU core for OL processing is not affected by the AP OS 20, and operates in a form that is very close to execution on the physical CPU core. Easy parallel execution environment is realized.

  In the present embodiment, the performance ratio of the AP processing and the OL processing can be arbitrarily changed by changing the dividing point between the AP processing core and the OL processing core. It is possible to apply the same type of multi-core SoC to these systems. Thereby, the effect of reduction of SoC development cost and shortening of a system development schedule is realizable.

  In other words, by making it possible to change the allocation of CPU cores on a multi-core processor by software according to the required processing capacity, it is possible to statically allocate CPU core resources to processing requests according to system specifications. . As a result, a system that was supported by multiple types of system LSIs with different specifications can be realized with a single type of multicore system LSI, or a variety of operation modes with different required performance can be achieved with a single product. Can be realized. As a result, by increasing the possibility of selling the system LSI, it is possible to promote an increase in production volume and to easily recover the development investment for the system LSI.

(Second Embodiment)
Next, a program parallel execution system according to a second embodiment of the present invention will be described in detail with reference to the drawings.

  Referring to FIGS. 8 and 9, the second embodiment introduces a mechanism for dynamically changing the assignment of cores in addition to the first embodiment.

  Referring to FIG. 8, in the second embodiment, the AP OS 20 includes an active core control unit 201 for changing the CPU core used by the AP OS 20, and the AP OS 20 itself has a CPU hot plug ( This embodiment is different from the first embodiment in that a HotPlug) function is provided.

  The hot plug function of a CPU is a new CPU core group used by the OS without terminating or restarting the OS when the OS on some CPU cores in the multi-core processor is running. This is a function that can add a CPU core or remove some CPU cores from the CPU core group in use by the OS. For example, Linux has an implementation having a CPU hot plug function.

  9, in addition to the first embodiment, the OL remote control unit 22 includes a dynamic configuration change unit 238 for instructing change of the CPU core used by the AP OS 20 and the lightweight scheduler LS32. I have.

  Since other components in the second embodiment are the same as those in the first embodiment shown in FIG. 1, the same reference numerals are given and description thereof is omitted.

(Description of operation of second embodiment)
The CPU core allocation dynamic change process will be described with reference to FIG.

  First, in the initial state, as shown in FIG. 10A, the AP OS 20 is operating using all CPU cores (AP cores (0) to (3)). Here, it is assumed that the dynamic configuration change unit 238 decides to operate the LS using two CPU cores.

  Then, the dynamic configuration change unit 238 instructs the active core control unit 201 in the AP OS 20 to release two of the CPU cores being used by the AP OS 20.

  The operating core control unit 201 separates the two CPU cores of the AP core (2) and the AP core (3) from the AP OS 20 by the CPU hot plug function, and stops these two CPU cores. This state is the state shown in FIG.

  Next, the dynamic configuration change unit 238 calls the LS initialization unit 231 included in the OL remote control unit 22 to perform the initialization process so that the lightweight scheduler LS32 operates on the two CPU cores separated and stopped. I do. This result is the state shown in FIG.

  In this way, the LS 32 using two CPU cores can be newly operated while the AP OS 20 is operating.

  Conversely, assume that the dynamic configuration change unit 238 decides to stop the LS and use all CPU cores in the AP OS 20 in the state of FIG.

  Then, the dynamic configuration change unit 238 first calls the OL task forcible termination unit 235 of the OL remote control unit 22 if necessary, and then calls the OL program discarding unit 237 of the OL remote control unit 22. The LS 32 and a set of OL tasks operating on the LS 32 are stopped and discarded. This state is the state shown in FIG.

  Next, the dynamic configuration changing unit 238 instructs the active core control unit 201 in the AP OS 20 to add the two CPU cores stopped by the above operation to the CPU core group being used by the AP OS 20. Send.

  The operating core control unit 201 adds these two CPU cores (AP core (2) and AP core (3)) by the CPU hot plug function, and sets the AP OS 20 to operate using all CPU cores. This result is the state shown in FIG.

  In this way, two of the CPU cores assigned to the LS 32 can be reassigned to the AP OS 20 side while the AP OS 20 is operating.

  In the above description, in multi-core SoC 10 having a total of four CPU cores, all four cores are assigned to AP OS 20 in the initial state, then two of them are assigned to LS 32, and all four cores are assigned to AP OS 20 again. An example was given. However, the present invention is not limited to this example. In the multi-core SoC 10 having any n CPU cores, the CPU described above is also used when one or more (n−1) CPU cores are allocated to the LS 32. It is possible to directly apply the core allocation dynamic change processing.

  Further, if not necessary, the power consumption of the entire multi-core SoC 10 can be reduced by stopping some CPU cores without assigning them to AP processing or OL processing.

(Effect of the second embodiment)
Next, effects of the second embodiment described above will be described.

  According to the second embodiment described above, in addition to the effects of the first embodiment, the OL processing core is allocated according to the dynamic change of the processing performance requirement while the system is operating, and the OL is executed. If the task is run and the processing request is eliminated, all the cores can be allocated for the AP OS, and the ability of the multi-core processor can be extracted more flexibly. As a result, the effect that one type of multi-core system LSI can be applied to various systems is realized.

  Next, a specific embodiment of the program parallel execution system will be described with reference to the drawings. This example shows how the LS 32 and the OL remote control unit 22 in the first embodiment are specifically configured.

  FIG. 11 is a block diagram showing an embodiment of LS32. A portion surrounded by a dotted line 321 is realized by hardware in the multi-core SoC 10. That is, the timer 111 is a hardware timer attached to the CPU core, and the base part that communicates with the AP communication unit 120 is realized by the parameter area 123 on the memory that holds the parameters to be transferred to and from the inter-core interrupt mechanism 45. The

  A portion surrounded by a dotted line 322 is realized as software on the CPU core. The time division multiplexing control unit 112 is realized using a timer interrupt handler, and the LS side receiving unit 121 is realized using an inter-core interrupt handler. The context handled by the time division multiplexing control unit 112 is a set of general-purpose registers of the CPU core and a status flag.

  A portion surrounded by a dotted line 323 is realized as a data structure or variable on the memory 50. These data structures are very common in computer processing, such as tables and queues (FIFO). Since the OL task queue 140 is not accessed from the AP processing core side, it is possible to improve the memory access performance for the data structure by arranging the OL task queue 140 on the local memory of the OL processing core. .

  FIG. 12 is a block diagram showing an embodiment of the OL remote control unit 22. The means 231 to 237 in the AP task interface unit 230 are described as AP processing core software. These are collected in the form of a library and linked to an application program and called. Similar to the AP communication unit 120 described above, the base unit of the LS communication unit 240 is realized by a parameter area 123 on a memory that holds parameters to be transferred to and from the inter-core interrupt mechanism 45.

  Although the present invention has been described with reference to the preferred embodiments and examples, the present invention is not necessarily limited to the above-described embodiments and examples, and various modifications can be made within the scope of the technical idea. Can be implemented.

  The present invention is an information processing apparatus using a multi-core processor having a plurality of processor cores of the same type, and in particular, an apparatus in which processing that requires high computing ability and real-time performance and other general-purpose processing are mixed in the system For example, it can be applied to system software such as a mobile phone, a car navigation system, a set top box, and a network control device. The present invention can also be applied to a personal computer or a general-purpose computer system equipped with a multi-core processor having a plurality of CPU cores of the same type.

10: Multi-core SoC
20: AP OS
21: AP task group 22: OL remote control unit 31: OL task group 32: LS (lightweight scheduler)
40, 41, 42: CPU core 45: Inter-core interrupt mechanism 46: SoC bus 47: Memory control unit 50: Memory 110: Time division multiplexing unit 111: Timer 112: Time division multiplexing control unit 120: Communication with AP Unit 121: LS side receiving unit 122: LS side transmitting unit 123: parameter area 131: context saving unit 132: context restoring unit 133: new context selecting unit 134: OL task control unit 135: OL task service unit 140: OL task queue 150: Current OL task variable 160: OL task table 170: OL task table lock variable 201: Active core control unit 230: AP task interface unit 231: LS initialization unit 232: OL program setup unit 233: OL task start unit 234 : OL task Ryo wait means 235: OL task abort means 236: OL task reinitializes means 237: OL program discarding part 238: dynamic configuration change unit 240: vs. LS communication unit 241: AP-side transmitting section 242: AP-side receiving section

Claims (20)

A program parallel execution system comprising a multi-core processor in which a plurality of processor cores are interconnected by a bus,
A plurality of processor cores are operated from an operating system and a first group of processor cores that operate a first application program on the operating system, and the first application without operating the operating system. Divided into a second group of processor cores for operating the second application program according to the request of
By performing communication between the first group of processor cores and the second group of processor cores, the first application program causes the second application program to be executed, or the second application A program parallel execution system comprising control means for performing control for receiving a processing result of a program. The control means is
A service that is called from the second application program or the second application program for at least one of synchronization, exclusive control between the second group of processor cores and cache control for the processor core of the second group The program parallel execution system according to claim 1, wherein a function is performed. The control means is
A lightweight scheduler for controlling execution of the second application program on the second group of processor cores;
A remote control unit communicating with the lightweight scheduler on the first group of processor cores;
The lightweight scheduler has a function of starting or terminating the second application on the second group of processor cores;
The remote control unit communicates using the lightweight scheduler, an inter-processor communication mechanism, and a memory variable, thereby instructing the start or end of the second application program from the processor core side of the first group. Has function,
The first application program requests the second application to perform a predetermined process by calling the remote control unit, and receives the processing result of the second application via the remote control unit. The program parallel execution system according to claim 1 or 2. The lightweight scheduler is
Operating the second application program including a plurality of tasks on the processor core of the second group;
4. The program according to claim 3, further comprising a function of saving or restoring an execution context of the task operating on the processor core of the second group, and a function of managing and switching the states of the plurality of tasks. Parallel execution system. The lightweight scheduler is
A time division multiplexing unit for executing a plurality of the tasks while switching in a time division manner;
The program parallel execution system according to claim 4, further comprising: a communication unit that communicates with the first group of processor cores. The lightweight scheduler is
A task table for managing existing tasks, a current OL task variable indicating a currently executing task, an OL task queue indicating a currently waiting task, and a task table used for exclusive control when operating the task table 6. The program parallel execution system according to claim 4, further comprising a lock variable. The lightweight scheduler is
From the task queue, a context saving unit that saves the context of the executed task that is called from the time division multiplexing unit or the communication unit, a context restoration unit that restores the context of the task to be executed and resumes the task, New context selection means for selecting a task to be executed next, task control means for controlling the start and end of a task based on an instruction from the first application program side, communication between threads in the task, and cache control 7. The program parallel execution system according to claim 6, further comprising OL task service means for processing a task end request. The remote control unit is
A task interface unit serving as an interface for the first application program to control the task, and a communication unit configured to communicate with the processor core of the second group;
The task interface unit is
Initializing means for performing initial setting so that the lightweight scheduler can operate on the second group of processor cores, and setting up means for newly loading the task on the running lightweight scheduler and setting it up to an executable state , Task start means for starting execution of the set-up task, task end wait means for waiting for completion of the started task, task forced end means for forcibly terminating the task, without reloading the task once finished 8. The program parallel execution system according to claim 3, further comprising: a task re-initialization unit that returns to an initial state; and a program discard unit that discards the loaded task and releases resources.   9. The system according to claim 1, further comprising a function of changing one or both of the number of processor cores of the first group and the number of processor cores of the second group during system operation. The program parallel execution system according to any one of the above. The operating system operated on the first group of processor cores has an addition / deletion function for dynamically adding or deleting the processor cores operating on the operating system,
10. The program parallel execution system according to claim 3, wherein the remote control unit has a function of initializing the second group of processor cores to start or end the lightweight scheduler. 11. . During system operation,
Using the processor core addition / deletion function, detaching a part of the processor cores constituting the first group of processor cores from the operating system,
The detached processor core is used as a second group of processor cores, and the lightweight scheduler is loaded on the second group of processor cores using the lightweight scheduler start function of the remote control unit to start the processor core. The program parallel execution system according to claim 10. During system operation,
After calling the lightweight scheduler termination function of the remote control unit, stop the processor core of the second group,
The program parallel execution system according to claim 10 or 11, wherein the stopped processor core is added to the operating system operation processor core using the processor core addition / deletion function. A program parallel execution method on a multi-core processor in which a plurality of processor cores are interconnected by a bus,
Operating an operating system on a first group of processor cores of the plurality of processor cores and operating a first application program on the operating system;
A second application program is operated by a request from the first application without running the operating system on a second group of processor cores of the plurality of processor cores,
The first application program is executed from the first application program by performing communication between the first group of processor cores and the second group of processor cores, or the first application program A program parallel execution method comprising: performing control for receiving a processing result of the second application program from   A service that is called from the second application program or the second application program for at least one of synchronization, exclusive control between the second group of processor cores and cache control for the processor core of the second group The program parallel execution method according to claim 13, wherein a function is performed. A lightweight scheduler for controlling execution of the second application program on the second group of processor cores;
A remote control communicating with the lightweight scheduler on the first group of processor cores;
The lightweight scheduler starts or terminates the second application on the second group of processor cores;
The remote control unit instructs the start or end of the second application program from the processor core side of the first group by communicating with the lightweight scheduler using an inter-processor communication mechanism and a memory variable. ,
The first application program requests a predetermined process to the second application by calling the remote control unit, and receives a processing result of the second application via the remote control unit. 15. The program parallel execution method according to claim 13 or 14. The lightweight scheduler is
Operating the second application program including a plurality of tasks on the processor core of the second group;
The program according to claim 15, further comprising a function of saving or restoring an execution context of the task operating on the second group of processor cores, and a function of managing and switching states of the plurality of tasks. Parallel execution method.   17. The system according to claim 9, further comprising a function of changing one or both of the number of processor cores of the first group and the number of processor cores of the second group during system operation. The program parallel execution method according to any one of the above. The operating system operated on the first group of processor cores has an addition / deletion function for dynamically adding or deleting the processor cores operating on the operating system,
18. The program parallel execution method according to claim 15, wherein the remote control unit has a function of initializing a processor core of the second group to start or end the lightweight scheduler. . During system operation,
Using the processor core addition / deletion function, detaching a part of the processor cores constituting the first group of processor cores from the operating system,
The detached processor core is used as a second group of processor cores, and the lightweight scheduler is loaded on the second group of processor cores using the lightweight scheduler start function of the remote control unit to start the processor core. The program parallel execution method according to claim 18. During system operation,
After calling the lightweight scheduler termination function of the remote control unit, stop the processor core of the second group,
The program parallel execution method according to claim 18 or 19, wherein the stopped processor core is added to the operating system operation processor core by using the processor core addition / deletion function.

Images