WO2011121730A1 - マルチコアプロセッサシステム、制御プログラム、および制御方法 - Google Patents

マルチコアプロセッサシステム、制御プログラム、および制御方法 Download PDF

Info

Publication number
WO2011121730A1
WO2011121730A1 PCT/JP2010/055711 JP2010055711W WO2011121730A1 WO 2011121730 A1 WO2011121730 A1 WO 2011121730A1 JP 2010055711 W JP2010055711 W JP 2010055711W WO 2011121730 A1 WO2011121730 A1 WO 2011121730A1
Authority
WO
WIPO (PCT)
Prior art keywords
interrupt request
software interrupt
request
interrupt
executed
Prior art date
Application number
PCT/JP2010/055711
Other languages
English (en)
French (fr)
Inventor
宏真 山内
浩一郎 山下
鈴木　貴久
康志 栗原
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to JP2012507955A priority Critical patent/JP5673672B2/ja
Priority to PCT/JP2010/055711 priority patent/WO2011121730A1/ja
Priority to CN201080065900.4A priority patent/CN102822802B/zh
Publication of WO2011121730A1 publication Critical patent/WO2011121730A1/ja
Priority to US13/628,709 priority patent/US9092255B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4812—Task transfer initiation or dispatching by interrupt, e.g. masked
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/20—Handling requests for interconnection or transfer for access to input/output bus
    • G06F13/24—Handling requests for interconnection or transfer for access to input/output bus using interrupt

Definitions

  • the present invention relates to a multi-core processor system, a control program, and a control method for controlling execution of interrupt processing.
  • CPU Central Processing Unit
  • the hardware interrupt request is an interrupt request generated from the peripheral device of the CPU to the CPU. Specifically, for example, when a user performs a fast-forward operation by a touch operation on a touch panel while a moving image is being played on a mobile phone, a hardware interrupt request is issued from the touch panel to the CPU.
  • a software interrupt request is an interrupt request generated due to a program being executed.
  • a hardware interrupt handler may call a software interrupt.
  • a hardware interrupt request when a hardware interrupt request is generated in the master CPU, the master CPU generates a software interrupt request.
  • a task that receives a software interrupt request may be assigned to the slave CPU.
  • a software interrupt handler interrupt processing
  • a software interrupt request is executed by the slave CPU using inter-processor interrupt communication.
  • the software interrupt handler of the software interrupt request is queued in the ready queue and waits for execution. In the ready queue, processing is executed in the order of waiting. Therefore, if many tasks are registered in the ready queue, there is a problem that the execution start of the software interrupt handler is delayed.
  • An object of the present invention is to provide a multi-core processor system, a control program, and a control method capable of speeding up the response time of a high-priority interrupt in order to solve the above-described problems caused by the prior art.
  • the first execution means for causing the interrupt processing of the software interrupt request to one core of the multi-core processor to wait and executing the waiting processing on the one core in the waiting order.
  • Second execution means for executing interrupt processing of a hardware interrupt request to the one core in preference to processing being executed in the one core, and whether the software interrupt request is a specific software interrupt request Determining means for determining whether or not the software interrupt request is determined to be the specific software interrupt request by the request determining means; and waiting for the interrupt processing of the software interrupt request by the first execution means
  • an execution control means for preferentially executing the second execution means.
  • the present multi-core processor system, control program, and control method have the effect of speeding up the response time of high-priority interrupts.
  • FIG. 3 is an explanatory diagram illustrating Example 1.
  • 6 is a flowchart (part 1) illustrating a control processing procedure by the multi-core processor system according to the first embodiment; 6 is a flowchart (No.
  • FIG. 10 is an explanatory diagram illustrating an execution state of a task that can be interrupted in the second embodiment.
  • FIG. 12 is an explanatory diagram (part 1) illustrating a task execution state in which interruption is disabled in the second embodiment.
  • FIG. 10 is an explanatory diagram (part 2) of a task that cannot be interrupted according to the second exemplary embodiment.
  • 12 is a flowchart illustrating a control processing procedure by the multi-core processor system according to the second embodiment.
  • the multi-core processor is a processor in which a plurality of cores are mounted. If a plurality of cores are mounted, a single processor having a plurality of cores may be used, or a processor group in which single core processors are arranged in parallel may be used. In the present embodiment, in order to simplify the explanation, a processor group in which single-core processors are arranged in parallel will be described as an example.
  • FIG. 1 is an explanatory diagram showing an example during video playback.
  • the case where the multi-core processor system 100 is a mobile phone is taken as an example.
  • player processing is being executed, and GUI (Graphic User Interface) processing is registered in the ready queue 141.
  • GUI Graphic User Interface
  • the slave CPU 102 is executing a moving image decoding process.
  • the ready queue 141 (or the ready queue 142) is a data structure for managing tasks in an executable state as is well known.
  • the task can be executed by extracting the context information of the task registered in the ready queue 141 (or the ready queue 142).
  • the context information is information indicating the internal state of the program and where the program is arranged on the memory.
  • FIG. 2 is an explanatory diagram showing an example in which a hardware interrupt request is generated.
  • a hardware interrupt request is generated from the I / O (Input / Output) device 103 (liquid crystal panel in FIG. 2).
  • the master CPU 101 detects the hardware interrupt request, the master OS 121 saves the player process in the ready queue 142 and executes a touch panel driver that is a hardware interrupt handler.
  • the master OS 121 identifies to which CPU the moving image decoding process to be interrupted is assigned.
  • the video decoding process is assigned to the slave CPU 102. Since the moving image decoding process is assigned to the slave CPU 102, the master OS 101 notifies the slave CPU 102 of a software interrupt request for calling a seek process through inter-processor interrupt communication.
  • the hypervisor 112 monitors communication between processors and detects the software interrupt request. When the hypervisor 112 detects the software interrupt request, the hypervisor 112 determines whether the seek process that is the software interrupt handler of the software interrupt request is a process with a high priority. The hypervisor 112 determines whether the request is a specific software interrupt request based on the priority of the seek process. Here, the hypervisor 112 determines that the seek process is a process with high priority. Thereafter, the hypervisor 112 generates a pseudo hardware interrupt request to the slave CPU 102. Specifically, a register value corresponding to a predetermined seek process is set in a register relating to a hardware interrupt in the slave CPU 102.
  • FIG. 3 is an explanatory diagram showing an example in which the seek process is immediately executed.
  • the slave CPU 102 specifies an address corresponding to the set value. Then, the slave OS 122 operating on the slave CPU 102 saves the moving image decoding process being executed at the head of the ready queue 142 and jumps to the specified address to execute the seek process.
  • the slave OS 122 puts the seek process on the ready queue 142 and waits for it as in the conventional case.
  • FIG. 4 is a block diagram showing hardware of the multi-core processor system 100.
  • the multi-core processor system 100 includes a master CPU 101, a slave CPU 102, a shared memory 104, and an I / O device 103. Each unit is connected by a bus 105.
  • the multi-core processor system 100 is exemplified as a mobile phone, but the multi-core processor system 100 is not limited to this, and examples thereof include a portable information terminal such as a cellular phone and an electronic book reader device, and a personal computer.
  • the master CPU 101 and the slave CPU 102 each have a core, a register, and a cache.
  • Each CPU register has a register relating to hardware interrupt (hereinafter, “hardware interrupt register”).
  • hardware interrupt register When a value is set in the hardware interrupt register, an address related to the interrupt processing is specified based on the set value, and the interrupt processing can be immediately executed by the CPU jumping to the address.
  • Each CPU has an interrupt vector table, and the interrupt vector table describes the correspondence between register values and interrupt processing addresses.
  • a value corresponding to the hardware interrupt request is set in the hardware interrupt register.
  • each CPU searches the set value from the interrupt vector table and identifies the corresponding address. Then, the CPU jumps to the specified address.
  • an address related to hardware interrupt processing but also an address related to software interrupt processing is described in the interrupt vector table.
  • a value that can be set in the hardware interrupt register is determined in advance for each hardware interrupt request and software interrupt request.
  • the master CPU 101 executes the hypervisor 111 and the master OS 121, and controls the entire multi-core processor system 100.
  • the master OS 121 includes a scheduler 131 that controls to which CPU a task is assigned and controls task switching in the master CPU 101.
  • the slave CPU 102 executes a hypervisor 112 and a slave OS 122.
  • the slave OS 122 includes a scheduler 132 that controls task switching in the slave CPU 102.
  • the hypervisor 111 and the hypervisor 112 are programs that directly operate on hardware such as the master CPU 101 and the slave CPU 102, respectively, and are programs stored in registers in the hardware.
  • the hypervisor 111 can execute a privileged instruction that directly refers to the master CPU 101, reads register information in the master CPU 101, and rewrites register information in the master CPU 101.
  • the hypervisor 112 can execute a privileged instruction that directly refers to a register in the slave CPU 102, reads register information in the slave CPU 102, and rewrites register information in the slave CPU 102.
  • the I / O device 103 is a device that can be directly operated by the user or a device that can be operated by the user via a network.
  • a keyboard a touch-enabled liquid crystal panel, a mouse, and the like can be given.
  • keys for inputting characters, numbers, various instructions, etc. are provided, and data is input.
  • a liquid crystal panel capable of touch operation the data is input, and characters, numbers, images, etc. are output.
  • the shared memory 104 is a memory shared by the multi-core processors, and stores a process table 151 and a use case table 500.
  • the shared memory 104 includes a ROM (Read Only Memory), a RAM (Random Access Memory), a flash ROM, and the like.
  • the flash ROM stores a program for each OS
  • the ROM stores an application program
  • the RAM is used as a work area for the master CPU 101 and the slave CPU 102.
  • the program stored in the shared memory 104 is loaded on each CPU, thereby causing each CPU to execute a coded process.
  • the process table 151 is information indicating which CPU a task is assigned to and which task the CPU is executing.
  • Each OS reads the process table 151 after the OS is started up and stores it in the cache of each CPU.
  • the scheduler 131 assigns a task, it registers it in the process table 151.
  • each scheduler registers in the process table 151 which task has been executed. Further, when each scheduler rewrites the process table 151, the scheduler updates the process table 151 stored in the caches of all CPUs by executing a snoop process.
  • the use case table 500 will be described with reference to FIG.
  • FIG. 5 is an explanatory diagram of an example of the use case table 500 according to the first embodiment.
  • the use case table 500 includes information indicating whether or not processing is forcibly executed at the time of interruption for each function, and information indicating whether or not the function can be interrupted during execution. For example, “forced jump” is described in FuncA, and “handler processing” is described in FuncB. That is, when FuncA is called as a software interrupt, the multicore processor system 100 immediately executes FuncA. On the other hand, when FuncB is called as a software interrupt, the multicore processor system 100 registers FuncB in the ready queue 142.
  • the function described as “forced jump” indicates that the process has high priority, and the function described as “handler process” does not have high priority (low priority). It shows that it is processing.
  • an interrupt process linked to a specific hardware interrupt request can be cited.
  • the seek process as shown in FIG. 3 is an interrupt process linked to the touch panel driver.
  • the specific hardware interrupt request is a hardware interrupt request generated by a user operation, for example.
  • examples of the user operation include a touch panel operation, a keyboard touch, and a mouse operation.
  • the use case table 500 is created in advance by the application designer at the time of design. Therefore, a process for which the designer wants to increase the priority may be registered in the use case table 500 as a process with a high priority.
  • the use case table 500 may be stored in the cache of each CPU when the multi-core processor system 100 is activated.
  • FIG. 6 is a block diagram illustrating the multi-core processor system 100.
  • Each CPU of the multi-core processor system 100 includes a first execution unit 601, a second execution unit 602, a request determination unit 603, a priority determination unit 604, and an execution control unit 605.
  • Each unit (first execution unit 601 to execution control unit 605) can cause each CPU to execute a program stored in the shared memory 104, for example.
  • the first execution unit 601 and the second execution unit 602 are programs provided in the OS (in this embodiment, the master OS 121 and the slave OS 122) operating on each CPU.
  • the request determination unit 603, the priority determination unit 604, and the execution control unit 605 are programs provided in the hypervisor (in the present embodiment, the hypervisor 111 and the hypervisor 112) that operate on each CPU.
  • the first execution unit 601 waits for the software interrupt handler of the software interrupt request, and executes the waiting processes in the waiting order.
  • the second execution unit 602 executes the hardware interrupt request software interrupt handler with priority over the processing being executed.
  • the request determination unit 603 determines whether the software interrupt request is a specific software interrupt request. In this embodiment, as to whether the software interrupt request is a specific software interrupt request, it is determined whether the software interrupt handler of the software interrupt request is a process with high priority.
  • the execution control unit 605 does not cause the first execution unit 601 to wait for the software interrupt handler of the software interrupt request, and the second control unit 605 The execution unit 602 executes the process with priority.
  • the priority determination unit 604 gives priority to the software interrupt of the software interrupt request that is being executed. It is determined based on a predetermined standard whether or not the execution of the handler is permitted.
  • the execution control unit 605 determines that the process being executed by the priority determination unit 604 does not permit execution of the software interrupt handler for the software interrupt request in preference to the process being executed, the execution process is performed. After completion or when switching tasks, the second execution unit 602 preferentially executes a software interrupt handler for a software interrupt request.
  • Example 1 and Example 2 will be described in detail with reference to the drawings.
  • a description will be given of whether the software interrupt handler is executed immediately or waits based on whether the software interrupt handler called by interprocessor interrupt communication is a function having a high priority.
  • the software interrupt handler is immediately executed based on whether or not the task being executed is permitted to interrupt, or the software interrupt handler is executed when the task being executed ends or when the task is switched. An example of determination will be described.
  • FIG. 7 is an explanatory diagram of the first embodiment.
  • the master OS 121 when a hardware interrupt request is generated to the master CPU 101 via the I / O device 103, the master OS 121 (2) immediately saves the task A being executed by the master CPU 101.
  • the master OS 121 executes (3) a hardware interrupt handler for the hardware interrupt request. Then, the master OS 121 uses the process table 151 to identify the CPU to which the task that receives the interrupt by the software interrupt handler called by the hardware interrupt handler is assigned. Here, the task that receives the interrupt is designated as task B, and the slave CPU 102 is identified as the CPU to which task B is assigned. Then, the master OS 121 notifies the slave CPU 102 of a software interrupt request through (4) inter-processor interrupt communication.
  • the hypervisor 112 monitors inter-processor communication and detects the software interrupt request. When the hypervisor 112 detects a software interrupt request, the hypervisor 112 searches the use case table 500 for a software interrupt handler of the detected software interrupt request, and determines whether the software interrupt handler is a process with high priority. Here, it is assumed that the software interrupt handler is a process with high priority.
  • the hypervisor 112 determines that the software interrupt handler is a process with high priority
  • the hypervisor 112 generates a pseudo hardware interrupt request to the slave CPU 102 (5).
  • Generating a pseudo hardware interrupt request indicates, for example, that the hypervisor 112 sets a value corresponding to the software interrupt handler in the hardware interrupt register in the register of the slave CPU 102.
  • the slave CPU 102 specifies an address corresponding to the set value using the interrupt vector table.
  • the slave OS 122 (6) saves the task B being executed to the head of the ready queue 142 and (7) executes the software interrupt handler by jumping to the specified address.
  • Control processing procedure by the multi-core processor system 100 according to the first embodiment 8 and 9 are flowcharts illustrating a control processing procedure performed by the multi-core processor system 100 according to the first embodiment.
  • a hardware interrupt request is generated in the master CPU 101.
  • the master CPU 101 detects a hardware interrupt request (step S801), and the master OS 121 operating on the master CPU 101 interrupts the task being executed and saves it in the ready queue 141 (step S802).
  • the master OS 121 executes a hardware interrupt handler for a hardware interrupt request (step S803), and uses the process table 151 to identify a CPU to which a task to receive an interrupt is assigned (step S804).
  • the master OS 121 determines whether or not the identified CPU is the master CPU 101 (step S805). If the identified CPU is the master CPU 101 (step S805: Yes), normal interrupt processing is executed (step S805). Step S806). On the other hand, when the master OS 121 determines that the identified CPU is not the master CPU 101 (step S805: No), inter-processor interrupt communication is performed with the identified CPU (step S807). Here, in the inter-processor interrupt communication, information on a function to be called to the specified CPU is added and a software interrupt request is notified.
  • the hypervisor 112 operating on the slave CPU 102 monitors the inter-processor communication and determines whether or not the inter-processor interrupt communication is detected (step S808). Note that the hypervisor 112 detects only inter-processor interrupt communication to the slave CPU 102. If the hypervisor 112 determines that no inter-processor interrupt communication has been detected (step S808: No), the process returns to step S808. That is, the hypervisor 112 can detect inter-processor interrupt communication by constantly monitoring inter-processor communication.
  • step S808: Yes the use case table 500 is used to determine whether the software interrupt handler for the software interrupt request is a process with high priority. (Step S809).
  • step S809: Yes a value related to the software interrupt request is set in the hardware interrupt register of the slave CPU 102 (step S810). ).
  • the slave CPU 102 detects a hardware interrupt request by setting a value in the hardware interrupt register (step S811). Although it is actually a software interrupt request, since the slave CPU 102 simply detects that a value is set in the hardware interrupt register, it does not determine whether it is a hardware interrupt request. .
  • the slave OS 122 operating on the slave CPU 102 interrupts the task being executed and saves it in the ready queue 142 (step S812). Then, the slave OS 122 executes the software interrupt handler for the software interrupt request (step S813), and proceeds to step S817.
  • the hypervisor 112 determines that the software interrupt handler of the software interrupt request is not a high priority process (step S809: No)
  • the software interrupt request is notified to the slave OS 122 (step S814).
  • the notification of the software interrupt request by the hypervisor 112 indicates notification of an instruction to be put on standby by being loaded on the ready queue 142.
  • the slave OS 122 registers the software interrupt handler in the ready queue 142 (step S815), and executes the software interrupt handler by executing the processes in the order registered in the ready queue 142 (step S816). ).
  • step S813 or step S816 the slave OS 122 determines whether or not the software interrupt handler has ended (step S817).
  • step S817: No the process returns to step S817.
  • step S817: Yes the slave OS 122 determines that the software interrupt handler has ended (step S817: Yes)
  • the hypervisor 112 operating on the slave CPU 102 constantly monitors the inter-processor communication, so that the hypervisor 112 detects the inter-processor interrupt communication.
  • the hypervisor 111 operating on the master CPU 101 performs inter-processor interrupt communication, and notifies the hypervisor 112 operating on the slave CPU 102 immediately before the execution, and then performs inter-processor interrupt communication. Also good.
  • the hypervisor 112 operating on the slave CPU 102 can detect inter-processor interrupt communication without constantly monitoring the hypervisor 112.
  • Example 2 In the second embodiment, a software interrupt handler with a high priority is immediately executed based on whether or not a running task permits interrupts, or when the running task is terminated or a task is switched, An example of determining whether to execute the software interrupt handler will be described.
  • ProcessID a flag indicating whether the task being executed has ended or whether switching of the task occurs. If ProcessID is 0, it indicates that the task is being executed, and if ProcessID is 1, it indicates that the task being executed has ended or task switching occurs.
  • FIG. 10 is an explanatory diagram of an example of a use case table according to the second embodiment.
  • the use case table 1000 includes information indicating whether or not processing is forcibly executed at the time of interruption for each function, information indicating whether or not the function can be interrupted during execution, and for each task. It has information indicating whether or not an interrupt can be made during execution. For example, FuncA is described as “forced jump” and “not interruptible”, and FuncB is described as “handler processing” and “interrupt enabled”.
  • task A is described as “-” and “interrupt enabled”
  • task B is described as “ ⁇ ” and “interrupt enabled”
  • task C is described as “ ⁇ ” and “interrupt disabled”. Is described.
  • a function is called as an interrupt handler, information indicating whether or not to forcibly execute processing at the time of an interrupt is not described in tasks A to B.
  • the use case table 1000 is stored in the shared memory 104.
  • the use case table 1000 may be stored in the cache of each CPU when the multi-core processor system 100 is activated.
  • FIG. 11 is an explanatory diagram showing an execution state of a task that can be interrupted in the second embodiment.
  • a task that receives a software interrupt called by a hardware interrupt handler is referred to as task B.
  • the master OS 121 (2) interrupts the task A and saves it in the ready queue 141, and (3) sets a hardware interrupt handler for the hardware interrupt request.
  • the master OS 121 identifies to which CPU the task B interrupted by the software interrupt handler called by the hardware interrupt handler is assigned.
  • the slave CPU 102 is specified.
  • the master OS 121 notifies the slave CPU 102 of a software interrupt request by (4) inter-processor interrupt communication.
  • the hypervisor 112 monitors the inter-processor communication and detects the inter-processor interrupt communication to the slave CPU 102. Then, the hypervisor 112 uses the use case table 1000 to determine whether or not the software interrupt handler for the software interrupt request is a process with high priority. Here, it is assumed that the software interrupt handler of the software interrupt request is a process with high priority.
  • the hypervisor 112 identifies a task being executed and uses the use case table 1000 to allow the task being executed to execute interrupt processing in preference to the task being executed. Determine whether. Here, it is determined that the task B is an interruptible task.
  • the hypervisor 112 (5) When it is determined that the task B is an interruptible task, the hypervisor 112 (5) generates a pseudo hardware interrupt request to the slave CPU 102. That is, a value corresponding to the software interrupt request is set in the hardware interrupt register. Then, the slave CPU 102 detects a hardware interrupt request by detecting that a value is set in the hardware interrupt register, and the slave OS 122 (6) saves the task B being executed to the ready queue 142, (7) The software interrupt handler for the software interrupt request is executed.
  • FIG. 12 is an explanatory diagram (part 1) showing an execution state of a task that cannot be interrupted in the second embodiment.
  • a task that receives a software interrupt called by a hardware interrupt handler is referred to as task C. Since (1) to (4) in FIG. 12 are the same as (1) to (4) in FIG. 11, description thereof is omitted.
  • the hypervisor 112 monitors the inter-processor communication and detects the inter-processor interrupt communication to the slave CPU 102. Then, the task being executed by the hypervisor 112 is identified, and the use case table 1000 is used to determine whether or not the task C being executed is an interruptible task. Here, it is determined that the task C is a task that cannot be interrupted. Then, the hypervisor 112 sets (5) ProcessID to 0. The slave OS 122 uses the process table 151 to determine whether task C has ended or whether task switching occurs.
  • FIG. 13 is an explanatory diagram (part 2) showing an execution state of a task that cannot be interrupted in the second embodiment.
  • the hypervisor 112 detects that the ProcessID has changed from 0 to 1, and generates a pseudo hardware interrupt request to the slave CPU 102.
  • the slave OS 122 executes (9) a software interrupt handler.
  • FIG. 14 is a flowchart of a control processing procedure performed by the multi-core processor system 100 according to the second embodiment.
  • the processing of the master CPU 101 is the same as the control processing procedure performed by the multi-core processor system 100 according to the first embodiment shown in FIG.
  • processing when the slave CPU 102 receives inter-processor interrupt communication from the master CPU 101 will be described.
  • the processing of the master CPU 101 is assumed to be steps S1401 to S1407 (same as steps S801 to S807 in FIG. 8 respectively).
  • the hypervisor 112 operating on the slave CPU 102 monitors inter-processor communication and determines whether or not inter-processor interrupt communication has been detected (step S1408). If the hypervisor 112 determines that no inter-processor interrupt communication has been detected (step S1408: NO), the process returns to step S1408. That is, the hypervisor 112 can detect inter-processor interrupt communication by constantly monitoring inter-processor communication.
  • step S1408 determines whether or not the software interrupt handler for the software interrupt request is a high-priority process using the use case table 1000. Is determined (step S1409).
  • step S1409: Yes determines whether the task being executed is an interruptible process (step S1410).
  • ProcessID 0 is set (step S1411), and the slave OS 122 has finished the task being executed, or the task It is determined whether or not switching has occurred (step S1417).
  • the process returns to step S1413.
  • ProcessID 1 is set (step S1418).
  • step S1411 the hypervisor 112 determines whether or not ProcessID is 1 (step S1412), and when it is determined that ProcessID is not 1 (step S1412: No), the process returns to step S1412. On the other hand, if it is determined that ProcessID is 1 (step S1412: Yes), a value related to the software interrupt request is set in the hardware interrupt register (step S1413).
  • the slave CPU 102 detects a hardware interrupt request (step S1414), and the slave OS 122 interrupts the task being executed and saves it in the ready queue 142 (step S1415).
  • the slave OS 122 executes a software interrupt handler (step S1416), and proceeds to step S1420.
  • step S1409 if the hypervisor 112 determines that the software interrupt handler is not a high priority process (step S1409: No), the hypervisor 112 notifies the slave OS 122 of a software interrupt request (step S1419).
  • the slave OS 122 loads the software interrupt handler on the ready queue 142 to cause the software interrupt handler to wait (step S1420), executes the waiting processes in the waiting order, and executes the software interrupt handler (step S1421).
  • step S1422 the slave OS 122 determines whether the software interrupt handler has ended (step S1422).
  • step S1422: No the process returns to step S1420.
  • step S1422: Yes the slave OS 122 determines that the software interrupt handler has ended (step S1422: Yes)
  • the interrupt response time can be obtained by executing the interrupt process of a specific software interrupt request with priority over the process being executed without waiting. Can be speeded up.
  • the specific software interrupt request is a software interrupt request linked to the specific hardware interrupt request, the response time of the interrupt from the external device can be increased.
  • the specific hardware interrupt request is a hardware interrupt request by a user operation
  • the response time of the interrupt by the user operation can be increased, and the user can operate without feeling stress due to the response time. it can.
  • the process being executed does not allow the interrupt process of the software interrupt request to be executed in preference to the process being executed, the process is executed after the process being executed ends or when a task is switched. causes interrupt processing to be executed. As a result, the response time of the interrupt can be increased without stopping the high-priority processing being executed.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

　ハイパーバイザ（１１２）が、プロセッサ間通信を監視し、ソフトウェア割り込み要求を検出すると、検出したソフトウェア割り込み要求のソフトウェア割込ハンドラが優先度の高い処理であるか否かを判断する。ハイパーバイザ（１１２）は、ソフトウェア割り込みハンドラが優先度の高い処理であると判断すると、（５）スレーブＣＰＵ（１０２）に対して疑似ハードウェア割り込み要求を発生させる。スレーブＯＳ（１２２）が、（６）実行中のタスクＢをレディキュー（１４２）の先頭に退避させ、（７）タスクＢに優先してソフトウェア割り込みハンドラを実行する。

Description

マルチコアプロセッサシステム、制御プログラム、および制御方法
　本発明は、割り込み処理の実行を制御するマルチコアプロセッサシステム、制御プログラム、および制御方法に関する。
　従来、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）の割り込み要求は、大きくハードウェア割り込み要求とソフトウェア割り込み要求の２つに分類することができる。ハードウェア割り込み要求は、ＣＰＵの周辺機器からＣＰＵに対して発生する割り込み要求である。具体的には、たとえば、携帯電話で動画再生中にタッチパネルで利用者がタッチ操作により早送り操作を行った場合、タッチパネルからＣＰＵへのハードウェア割り込み要求となる。ソフトウェア割り込み要求は、実行中のプログラムに起因して発生する割り込み要求である。
　ハードウェア割り込み要求では、該ＣＰＵ上で動作するＯＳは、実行中のタスクを退避させ、該ハードウェア割り込み要求のハードウェア割り込みハンドラ（割り込み処理）をすぐに実行する。また、ハードウェア割り込みハンドラがソフトウェア割り込みを呼び出す場合がある。
　また、マルチコアプロセッサシステムにおいて、マスタＣＰＵにハードウェア割り込み要求が発生する場合、マスタＣＰＵはソフトウェア割り込み要求を発生させる。このときソフトウェア割り込み要求を受けるタスクがスレーブＣＰＵに割り当てられている場合がある。該タスクがスレーブＣＰＵに割り当てられている場合、プロセッサ間割り込み通信を用いてスレーブＣＰＵでソフトウェア割り込み要求のソフトウェア割り込みハンドラ（割り込み処理）を実行させる。
高橋浩和、小田逸郎、山幡為佐久著　「Ｌｉｎｕｘ　カーネル　解読室　２．６」　ソフトバンククリエイティブ株式会社出版　２００６年１１月３０日　ｐ．６２－６３
　しかしながら、プロセッサ間割り込み通信によりソフトウェア割り込み要求が発生すると、ソフトウェア割り込み要求のソフトウェア割り込みハンドラはレディキューにキューイングされることで実行を待機する。レディキューでは待機順に処理が実行されるため、レディキュー上にタスクが多く登録されていると、ソフトウェア割り込みハンドラの実行開始が遅くなるという問題点があった。
　すなわち、ソフトウェア割り込みハンドラが呼び出されてから実行開始されるまでは、ハードウェア割り込みハンドラが呼び出されてから実行開始されるまでに比べて遅いという問題点があり、割り込みの応答が遅いという問題点があった。
　本発明は、上述した従来技術による問題点を解消するため、優先度の高い割り込みの応答時間を高速化させることができるマルチコアプロセッサシステム、制御プログラム、および制御方法を提供することを目的とする。
　本実施形態の一観点によれば、マルチコアプロセッサのうちの一のコアへのソフトウェア割り込み要求の割り込み処理を待機させ、待機中の処理を待機順に前記一のコアで実行する第１の実行手段と、前記一のコアへのハードウェア割り込み要求の割り込み処理を前記一のコアで実行中の処理に優先して実行する第２の実行手段と、前記ソフトウェア割り込み要求が特定のソフトウェア割り込み要求であるか否かを要求判断する判断手段と、前記要求判断手段により前記ソフトウェア割り込み要求が前記特定のソフトウェア割り込み要求であると判断された場合、前記ソフトウェア割り込み要求の割り込み処理を前記第１の実行手段により待機させず、前記第２の実行手段により優先して実行させる実行制御手段と、を備えるマルチコアプロセッサシステムを提供する。
　本マルチコアプロセッサシステム、制御プログラム、および制御方法によれば、優先度の高い割り込みの応答時間を高速化させることができるという効果を奏する。
動画再生中の一例を示す説明図である。 ハードウェア割り込み要求が発生した例を示す説明図である。 シーク処理が直ちに実行される例を示す説明図である。 マルチコアプロセッサシステムのハードウェアを示すブロック図である。 実施例１にかかるユースケーステーブルの一例を示す説明図である。 マルチコアプロセッサシステムを示すブロック図である。 実施例１を示す説明図である。 実施例１にかかるマルチコアプロセッサシステムによる制御処理手順を示すフローチャート（その１）である。 実施例１にかかるマルチコアプロセッサシステムによる制御処理手順を示すフローチャート（その２）である。 実施例２にかかるユースケーステーブルの一例を示す説明図である。 実施例２において割り込み可のタスクが実行状態を示す説明図である。 実施例２において割り込み不可のタスクが実行状態を示す説明図（その１）である。 実施例２において割り込み不可のタスクが実行状態を示す説明図（その２）である。 実施例２にかかるマルチコアプロセッサシステムによる制御処理手順を示すフローチャートである。
　以下に添付図面を参照して、マルチコアプロセッサシステム、制御プログラム、および制御方法の好適な実施の形態を詳細に説明する。なお、本実施の形態のマルチコアプロセッサシステムにおいて、マルチコアプロセッサとは、コアが複数搭載されたプロセッサである。コアが複数搭載されていれば、複数のコアが搭載された単一のプロセッサでもよく、シングルコアのプロセッサが並列されているプロセッサ群でもよい。なお、本実施の形態では、説明を単純化するため、シングルコアのプロセッサが並列されているプロセッサ群を例に挙げて説明する。
　図１は、動画再生中の一例を示す説明図である。図１では、マルチコアプロセッサシステム１００が携帯電話の場合を例に挙げている。マスタＣＰＵ１０１ではプレーヤー処理が実行中であり、ＧＵＩ（Ｇｒａｐｈｉｃ　Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）処理がレディキュー１４１に登録されている。一方、スレーブＣＰＵ１０２では動画デコード処理が実行中である。
　ここで、レディキュー１４１（またはレディキュー１４２）とは、周知のように実行可能状態のタスクを管理するためのデータ構造である。レディキュー１４１（またはレディキュー１４２）に登録されているタスクのコンテキスト情報を取り出すことで、タスクを実行することができる。コンテキスト情報はプログラムの内部状態やプログラムがメモリ上のどこに配置されたかを示す情報である。
　図２は、ハードウェア割り込み要求が発生した例を示す説明図である。図２では、利用者が動画に対して早送りをしたため、Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）デバイス１０３（図２では液晶パネル）からハードウェア割り込み要求が発生する。マスタＣＰＵ１０１が該ハードウェア割り込み要求を検出すると、マスタＯＳ１２１が、プレーヤー処理をレディキュー１４２に退避させ、ハードウェア割り込みハンドラであるタッチパネルドライバを実行する。
　つぎに、マスタＯＳ１２１がタッチパネルドライバからソフトウェア割り込み要求によりシーク処理を実行させようとすると、マスタＯＳ１２１が割り込み対象である動画デコード処理がどのＣＰＵに割り当てられているかを特定する。
　ここで、動画デコード処理は、スレーブＣＰＵ１０２に割り当てられていると特定される。マスタＯＳ１２１は、動画デコード処理がスレーブＣＰＵ１０２に割り当てられているため、マスタＣＰＵ１０１が、プロセッサ間割り込み通信によりシーク処理を呼び出すソフトウェア割り込み要求をスレーブＣＰＵ１０２へ通知する。
　ハイパーバイザ１１２はプロセッサ間通信を監視し、該ソフトウェア割り込み要求を検出する。ハイパーバイザ１１２は、該ソフトウェア割り込み要求を検出すると、該ソフトウェア割り込み要求のソフトウェア割り込みハンドラであるシーク処理が優先度の高い処理であるか否かを判断する。なお、ハイパーバイザ１１２は、シーク処理の優先度に基づいて、特定のソフトウェア割り込み要求であるか否かを判断する。ここでは、ハイパーバイザ１１２はシーク処理は優先度の高い処理であると判断する。その後ハイパーバイザ１１２は、スレーブＣＰＵ１０２に対して疑似ハードウェア割り込み要求を発生させる。具体的には、あらかじめ定められているシーク処理に対応するレジスタ値をスレーブＣＰＵ１０２内のハードウェア割り込みに関するレジスタに設定する。
　図３は、シーク処理が直ちに実行される例を示す説明図である。スレーブＣＰＵ１０２は、スレーブＣＰＵ１０２内のハードウェア割り込みに関するレジスタに値が設定されると、該設定された値に対応するアドレスを特定する。そして、スレーブＣＰＵ１０２上で動作するスレーブＯＳ１２２が、実行中の動画デコード処理をレディキュー１４２の先頭に退避させ、該特定したアドレスにジャンプすることでシーク処理を実行する。
　これにより、シーク処理が即座に実行され、優先度の高い処理に関する応答性を向上させることができる。なお、もしシーク処理が優先度の低い処理であれば、従来と同様にスレーブＯＳ１２２がレディキュー１４２に該シーク処理を積むことで待機させる。
（マルチコアプロセッサシステム１００のハードウェア）
　図４は、マルチコアプロセッサシステム１００のハードウェアを示すブロック図である。図４において、マルチコアプロセッサシステム１００は、マスタＣＰＵ１０１と、スレーブＣＰＵ１０２と、共有メモリ１０４と、Ｉ／Ｏデバイス１０３と、を有している。また、各部は、バス１０５によって接続されている。図１ではマルチコアプロセッサシステム１００が携帯電話を例に挙げているが、これに限らず、マルチコアプロセッサシステム１００は携帯電話や電子ブックリーダーデバイスなどの携帯情報端末やパーソナルコンピュータが例として挙げられる。
　マスタＣＰＵ１０１とスレーブＣＰＵ１０２とは、それぞれコアとレジスタとキャッシュとを有している。各ＣＰＵのレジスタには、ハードウェア割り込みに関するレジスタ（以下、「ハードウェア割り込みレジスタ」）を有している。ハードウェア割り込みレジスタが値を設定されると、該設定された値に基づいて割り込み処理に関するアドレスが特定され、ＣＰＵが該アドレスにジャンプすることで該割り込み処理をすぐに実行することができる。
　各ＣＰＵには割り込みベクターテーブルを有し、該割り込みベクターテーブルにはレジスタの値と割り込み処理のアドレスとの対応関係が記述されている。ハードウェア割り込み要求では、ハードウェア割り込みレジスタに該ハードウェア割り込み要求に対応する値を設定する。各ＣＰＵは該ＣＰＵが有するハードウェア割り込みレジスタに値が設定されると、各ＣＰＵは割り込みベクターテーブルから設定された値を検索し、対応するアドレスを特定する。そして、該ＣＰＵは特定したアドレスにジャンプする。
　また、本実施の形態では、割り込みベクターテーブルにハードウェア割り込み処理に関するアドレスだけでなく、ソフトウェア割り込み処理に関するアドレスも記述されている。そして、ハードウェア割り込み要求およびソフトウェア割り込み要求ごとにハードウェア割り込みレジスタに設定可能な値があらかじめ決定されている。
　マスタＣＰＵ１０１はハイパーバイザ１１１とマスタＯＳ１２１を実行し、マルチコアプロセッサシステム１００の全体の制御を司る。マスタＯＳ１２１は、タスクをどのＣＰＵに割り当てるかを制御し、マスタＣＰＵ１０１でのタスクの切り替えを制御するスケジューラ１３１を備えている。スレーブＣＰＵ１０２はハイパーバイザ１１２とスレーブＯＳ１２２を実行する。スレーブＯＳ１２２は、スレーブＣＰＵ１０２でのタスクの切り替えを制御するスケジューラ１３２を備えている。
　つぎに、ハイパーバイザ１１１とハイパーバイザ１１２とは、それぞれマスタＣＰＵ１０１とスレーブＣＰＵ１０２などのハードウェア上で直接動作するプログラムであり、該ハードウェア内のレジスタに記憶されているプログラムである。ハイパーバイザ１１１は、マスタＣＰＵ１０１を直接参照したり、マスタＣＰＵ１０１内のレジスタの情報を読み出したり、マスタＣＰＵ１０１内のレジスタの情報を書き換えたりする特権命令を実施することができる。ハイパーバイザ１１２は、スレーブＣＰＵ１０２内のレジスタを直接参照したり、スレーブＣＰＵ１０２内のレジスタの情報を読み出したり、スレーブＣＰＵ１０２内のレジスタの情報を書き換えたりする特権命令を実施することができる。
　Ｉ／Ｏデバイス１０３は、ユーザが直接操作可能なデバイスや、ネットワークを介してユーザが操作可能なデバイスである。たとえば、キーボードやタッチ操作可能な液晶パネルやマウスなどが挙げられる。たとえば、キーボードであれば、文字、数字、各種指示などの入力のためのキーを備え、データの入力を行う。たとえば、タッチ操作可能な液晶パネルであれば、該データの入力を行い、文字、数字、画像などの出力を行う。
　共有メモリ１０４は、マルチコアプロセッサに共有されるメモリであり、プロセステーブル１５１とユースケーステーブル５００とを記憶している。共有メモリ１０４は、具体的には、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）と、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）と、フラッシュＲＯＭなどを備えている。
　たとえば、フラッシュＲＯＭが各ＯＳのプログラムを記憶し、ＲＯＭがアプリケーションプログラムを記憶し、ＲＡＭがマスタＣＰＵ１０１とスレーブＣＰＵ１０２のワークエリアとして使用される。共有メモリ１０４に記憶されているプログラムは、各ＣＰＵにロードされることで、コーディングされている処理を該各ＣＰＵに実行させることとなる。
　プロセステーブル１５１とは、タスクがどのＣＰＵに割り当てられているか、ＣＰＵがどのタスクを実行中であるかを示す情報である。各ＯＳは該ＯＳが起動後にプロセステーブル１５１を読み出して各ＣＰＵのキャッシュに記憶しておく。スケジューラ１３１はタスクを割り当てるとプロセステーブル１５１に登録する。各スケジューラはタスクスイッチが発生するとプロセステーブル１５１にどのタスクが実行状態になったかを登録する。また、各スケジューラはプロセステーブル１５１を書き換えると、スヌープ処理を実行することで、全ＣＰＵのキャッシュに記憶されているプロセステーブル１５１を更新する。つぎに、ユースケーステーブル５００について図５を用いて説明する。
　図５は、実施例１にかかるユースケーステーブル５００の一例を示す説明図である。ユースケーステーブル５００は、関数ごとに割り込み時に強制的に処理を実行させるか否かを示す情報と、該関数が実行中に割り込みができるか否かを示す情報である。たとえば、ＦｕｎｃＡには「強制ジャンプ」と記述され、ＦｕｎｃＢには「ハンドラ処理」と記述されている。すなわち、ソフトウェア割り込みとしてＦｕｎｃＡが呼び出されると、マルチコアプロセッサシステム１００では、ＦｕｎｃＡを直ちに実行させる。一方、ソフトウェア割り込みとしてＦｕｎｃＢが呼び出されると、マルチコアプロセッサシステム１００では、ＦｕｎｃＢをレディキュー１４２に登録する。
　本実施の形態では、「強制ジャンプ」と記述されている関数は優先度の高い処理であることを示し、「ハンドラ処理」と記述されている関数は優先度の高くない（優先度の低い）処理であることを示している。
　優先度の高い割り込み処理としては、たとえば、特定のハードウェア割り込み要求に連動する割り込み処理が挙げられる。たとえば、図３で示したようなシーク処理はタッチパネルドライバに連動する割り込み処理である。特定のハードウェア割り込み要求とは、たとえば、ユーザ操作によって発生するハードウェア割り込み要求である。ここで、ユーザ操作とは、たとえば、タッチパネル操作、キーボードタッチ、マウス操作、などが挙げられる。
　また、ユースケーステーブル５００はアプリケーションの設計者があらかじめ設計時に作成することとする。よって、設計者が優先度を高くしたい処理を優先度の高い処理としてユースケーステーブル５００に登録してもよい。
　また、ユースケーステーブル５００で割り込み時に強制的に処理を実行させるか否かを示す情報が「強制ジャンプ」と記述されている関数のアドレスは上述の割り込みベクターテーブルに登録されていることとする。なお、ユースケーステーブル５００はマルチコアプロセッサシステム１００が起動されると共に各ＣＰＵのキャッシュに記憶させることとしてよい。
（マルチコアプロセッサシステム１００）
　図６は、マルチコアプロセッサシステム１００を示すブロック図である。マルチコアプロセッサシステム１００の各ＣＰＵは、第１の実行部６０１と、第２の実行部６０２と、要求判断部６０３と、優先判断部６０４と、実行制御部６０５と、を含む。各部（第１の実行部６０１～実行制御部６０５）は、たとえば、共有メモリ１０４に記憶されたプログラムを各ＣＰＵに実行させることができる。第１の実行部６０１と、第２の実行部６０２は、各ＣＰＵ上で動作するＯＳ（本実施の形態ではマスタＯＳ１２１およびスレーブＯＳ１２２）に備えられたプログラムである。要求判断部６０３と、優先判断部６０４と、実行制御部６０５は、各ＣＰＵ上で動作するハイパーバイザ（本実施の形態ではハイパーバイザ１１１およびハイパーバイザ１１２）に備えられたプログラムである。
　第１の実行部６０１は、ソフトウェア割り込み要求のソフトウェア割り込みハンドラを待機させ、待機中の処理を待機順に実行する。
　第２の実行部６０２は、ハードウェア割り込み要求のソフトウェア割り込みハンドラを実行中の処理に優先して実行する。
　要求判断部６０３は、ソフトウェア割り込み要求が特定のソフトウェア割り込み要求であるか否かを判断する。本実施の形態では、ソフトウェア割り込み要求が特定のソフトウェア割り込み要求であるか否かについては、ソフトウェア割り込み要求のソフトウェア割り込みハンドラが、優先度の高い処理であるか否かを判断している。
　実行制御部６０５は、要求判断部６０３によりソフトウェア割り込み要求が特定のソフトウェア割り込み要求であると判断された場合、ソフトウェア割り込み要求のソフトウェア割り込みハンドラを第１の実行部６０１により待機させず、第２の実行部６０２により優先して実行させる。
　また、優先判断部６０４は、要求判断部６０３によりソフトウェア割り込み要求が特定のソフトウェア割り込み要求であると判断された場合、実行中の処理が該実行中の処理に優先してソフトウェア割り込み要求のソフトウェア割り込みハンドラを実行することを許可しているか否かを所定基準に基づいて判断する。
　実行制御部６０５は、優先判断部６０４により実行中の処理が実行中の処理に優先してソフトウェア割り込み要求のソフトウェア割り込みハンドラを実行することを許可していないと判断した場合、実行中の処理が終了後もしくはタスクの切り替え時に、ソフトウェア割り込み要求のソフトウェア割り込みハンドラを第２の実行部６０２により優先して実行させる。
　以上を踏まえて図を用いて実施例１および実施例２を詳細に説明する。まず、実施例１では、プロセッサ間割り込み通信により呼び出されるソフトウェア割り込みハンドラが優先度の高い関数であるか否かに基づいて該ソフトウェア割り込みハンドラを直ちに実行させるか、待機させるかについて説明する。つぎに、実施例２では、実行中のタスクが割り込みを許可しているか否かに基づいてソフトウェア割り込みハンドラを直ちに実行させるか、該実行中のタスクが終了またはタスクの切り替え時に該ソフトウェア割り込みハンドラを判断する例について説明する。
（実施例１）
　図７は、実施例１を示す説明図である。まず、（１）Ｉ／Ｏデバイス１０３を介してハードウェア割り込みの要求がマスタＣＰＵ１０１に対して発生すると、マスタＯＳ１２１が（２）マスタＣＰＵ１０１で実行中のタスクＡを直ちに退避させる。
　そして、マスタＯＳ１２１が、（３）該ハードウェア割り込み要求のハードウェア割り込みハンドラを実行する。そして、ハードウェア割り込みハンドラが呼び出すソフトウェア割り込みハンドラにより割り込みを受けるタスクが割り当てられているＣＰＵをマスタＯＳ１２１がプロセステーブル１５１を用いて特定する。ここで、該割り込みを受けるタスクをタスクＢとし、タスクＢが割り当てられているＣＰＵとしてスレーブＣＰＵ１０２が特定される。そして、マスタＯＳ１２１が、（４）プロセッサ間割り込み通信によりソフトウェア割り込み要求をスレーブＣＰＵ１０２へ通知する。
　ハイパーバイザ１１２は、プロセッサ間通信を監視し、該ソフトウェア割り込み要求を検出する。ハイパーバイザ１１２は、ソフトウェア割り込み要求を検出すると、ユースケーステーブル５００から検出したソフトウェア割り込み要求のソフトウェア割り込みハンドラを検索し、該ソフトウェア割り込みハンドラが優先度の高い処理であるか否かを判断する。ここでは、ソフトウェア割り込みハンドラは優先度の高い処理であるとする。
　ハイパーバイザ１１２は、ソフトウェア割り込みハンドラが優先度の高い処理であると判断すると、（５）スレーブＣＰＵ１０２に対して疑似ハードウェア割り込み要求を発生させる。疑似ハードウェア割り込み要求を発生させるとは、たとえば、ハイパーバイザ１１２がスレーブＣＰＵ１０２のレジスタ内でハードウェア割り込みレジスタにソフトウェア割り込みハンドラに対応する値を設定することを示している。スレーブＣＰＵ１０２は設定された値に対応するアドレスを割り込みベクターテーブルを用いて特定する。そして、スレーブＯＳ１２２が、（６）実行中のタスクＢをレディキュー１４２の先頭に退避させ、（７）特定されたアドレスにジャンプすることでソフトウェア割り込みハンドラを実行する。
（実施例１にかかるマルチコアプロセッサシステム１００による制御処理手順）
　図８および図９は、実施例１にかかるマルチコアプロセッサシステム１００による制御処理手順を示すフローチャートである。ここでは、マスタＣＰＵ１０１にハードウェア割り込み要求が発生した場合を例に説明する。まず、マスタＣＰＵ１０１が、ハードウェア割り込み要求を検出し（ステップＳ８０１）、マスタＣＰＵ１０１上で動作するマスタＯＳ１２１が、実行中のタスクを中断してレディキュー１４１に退避させる（ステップＳ８０２）。そして、マスタＯＳ１２１が、ハードウェア割り込み要求のハードウェア割り込みハンドラを実行し（ステップＳ８０３）、プロセステーブル１５１を用いて割り込みを受けるタスクが割り当てられているＣＰＵを特定する（ステップＳ８０４）。
　つぎに、マスタＯＳ１２１が、特定したＣＰＵがマスタＣＰＵ１０１であるか否かを判断し（ステップＳ８０５）、特定したＣＰＵがマスタＣＰＵ１０１であれば（ステップＳ８０５：Ｙｅｓ）、通常の割り込み処理を実行する（ステップＳ８０６）。一方、マスタＯＳ１２１が、特定したＣＰＵがマスタＣＰＵ１０１でないと判断した場合（ステップＳ８０５：Ｎｏ）、特定したＣＰＵへプロセッサ間割り込み通信を実施する（ステップＳ８０７）。ここで、プロセッサ間割り込み通信では、特定されたＣＰＵに呼び出す関数に関する情報を付与してソフトウェア割り込み要求を通知する。
　一方、スレーブＣＰＵ１０２上で動作するハイパーバイザ１１２は、プロセッサ間通信を監視し、プロセッサ間割り込み通信を検出したか否かを判断する（ステップＳ８０８）。なお、ハイパーバイザ１１２は、スレーブＣＰＵ１０２へのプロセッサ間割り込み通信のみを検出している。ハイパーバイザ１１２が、プロセッサ間割り込み通信を検出していないと判断した場合（ステップＳ８０８：Ｎｏ）、ステップＳ８０８へ戻る。すなわち、ハイパーバイザ１１２は常時プロセッサ間通信を監視することにより、プロセッサ間割り込み通信を検出することができる。
　ハイパーバイザ１１２が、プロセッサ間割り込み通信を検出したと判断した場合（ステップＳ８０８：Ｙｅｓ）、ユースケーステーブル５００を用いてソフトウェア割り込み要求のソフトウェア割り込みハンドラが優先度の高い処理であるか否かを判断する（ステップＳ８０９）。ハイパーバイザ１１２が、ソフトウェア割り込み要求のソフトウェア割り込みハンドラが優先度の高い処理であると判断した場合（ステップＳ８０９：Ｙｅｓ）、スレーブＣＰＵ１０２のハードウェア割り込みレジスタにソフトウェア割り込み要求に関する値を設定する（ステップＳ８１０）。
　つぎに、スレーブＣＰＵ１０２が、ハードウェア割り込みレジスタに値が設定されることで、ハードウェア割り込み要求を検出する（ステップＳ８１１）。なお、実際にはソフトウェア割り込み要求であるが、スレーブＣＰＵ１０２は単にハードウェア割り込みレジスタに値が設定されることを検出するだけであるため、ハードウェア割り込み要求であるか否かに関しては判断していない。スレーブＣＰＵ１０２上で動作するスレーブＯＳ１２２が、実行中のタスクを中断してレディキュー１４２へ退避させる（ステップＳ８１２）。そして、スレーブＯＳ１２２が、ソフトウェア割り込み要求のソフトウェア割り込みハンドラを実行し（ステップＳ８１３）、ステップＳ８１７へ移行する。
　一方、ハイパーバイザ１１２が、ソフトウェア割り込み要求のソフトウェア割り込みハンドラが優先度の高い処理でないと判断した場合（ステップＳ８０９：Ｎｏ）、ソフトウェア割り込み要求をスレーブＯＳ１２２へ通知する（ステップＳ８１４）。ここで、ハイパーバイザ１１２がソフトウェア割り込み要求を通知するとは、レディキュー１４２に積むことで待機させる指示を通知することを示している。スレーブＯＳ１２２は、該通知を受け付けると、ソフトウェア割り込みハンドラをレディキュー１４２へ登録し（ステップＳ８１５）、レディキュー１４２に登録されている順に処理を実行することにより、ソフトウェア割り込みハンドラを実行する（ステップＳ８１６）。
　ステップＳ８１３またはステップＳ８１６のつぎに、スレーブＯＳ１２２が、該ソフトウェア割り込みハンドラが終了したか否かを判断する（ステップＳ８１７）。スレーブＯＳ１２２が、ソフトウェア割り込みハンドラが終了していないと判断した場合（ステップＳ８１７：Ｎｏ）、ステップＳ８１７に戻る。一方、スレーブＯＳ１２２が、ソフトウェア割り込みハンドラが終了したと判断した場合（ステップＳ８１７：Ｙｅｓ）、マスタＣＰＵ１０１にソフトウェア割り込みハンドラの完了を通知する（ステップＳ８１８）。
　また、本実施の形態では、スレーブＣＰＵ１０２上で動作するハイパーバイザ１１２が常時プロセッサ間通信を監視することで、ハイパーバイザ１１２はプロセッサ間割り込み通信を検出している。また、たとえば、マスタＣＰＵ１０１上で動作するハイパーバイザ１１１がプロセッサ間割り込み通信を実施することを、実施直前にスレーブＣＰＵ１０２上で動作するハイパーバイザ１１２に通知し、その後、プロセッサ間割り込み通信を実施してもよい。これにより、スレーブＣＰＵ１０２上で動作するハイパーバイザ１１２は常時監視することなく、ハイパーバイザ１１２はプロセッサ間割り込み通信を検出することができる。
（実施例２）
　実施例２では、実行中のタスクが割り込みを許可しているか否かに基づいて優先度の高いソフトウェア割り込みハンドラを直ちに実行させるか、該実行中のタスクが終了またはタスクの切り替えが発生する時に、該ソフトウェア割り込みハンドラを実行させるかを判断する例について説明する。
　ここで、実施例２では、実行中のタスクが割り込みを許可していない場合において、実行中のタスクが終了したか否かまたはタスクの切り替えが発生するか否かを示すフラグをＰｒｏｃｅｓｓＩＤとする。ＰｒｏｃｅｓｓＩＤが０であれば、タスクが実行中であることを示し、ＰｒｏｃｅｓｓＩＤが１であれば実行中のタスクが終了したもしくはタスクの切り替えが発生することを示す。
　図１０は、実施例２にかかるユースケーステーブルの一例を示す説明図である。ユースケーステーブル１０００では、関数ごとに割り込み時に強制的に処理を実行させるか否かを示す情報と、該関数が実行中に割り込みができるか否かを示す情報を有し、さらに、タスクごとに実行中に割り込みができるか否かを示す情報を有している。たとえば、ＦｕｎｃＡは、「強制ジャンプ」で、「割り込み不可」と記述され、ＦｕｎｃＢは、「ハンドラ処理」で、「割り込み可」と記述されている。
　さらに、たとえば、タスクＡは、「－」で、「割り込み可」と記述され、タスクＢは、「－」で、「割り込み可」と記述され、タスクＣは、「－」で、「割り込み不可」と記述されている。なお、本実施の形態では、割り込みハンドラとして関数のみが呼び出されることとしているため、タスクＡ～タスクＢには割り込み時に強制的に処理を実行させるか否かを示す情報が記述されていない。
　たとえば、タスクＡが実行中にソフトウェア割り込みが発生したら、タスクＡに関する実行中に割り込みができるか否かを示す情報は「割り込み可」であるため、タスクＡを退避させてソフトウェア割り込みハンドラを呼び出して実行する。一方、タスクＣに関する実行中に割り込みができるか否かを示す情報が「割り込み不可」である。タスクＣが実行中にソフトウェア割り込みが発生した場合、タスクＣの実行が終了してからもしくはタスクの切り替えが発生するときに、ソフトウェア割り込みハンドラを呼び出して実行する。なお、実施例２においては、共有メモリ１０４にユースケーステーブル１０００が記憶されている。ユースケーステーブル１０００はマルチコアプロセッサシステム１００が起動されると共に各ＣＰＵのキャッシュに記憶させることとしてよい。
　図１１は、実施例２において割り込み可のタスクが実行状態を示す説明図である。図１１では、ハードウェア割り込みハンドラが呼び出すソフトウェア割り込みを受けるタスクをタスクＢとする。まず、（１）マスタＣＰＵ１０１に対してハードウェア割り込み要求が発生すると、マスタＯＳ１２１が（２）タスクＡを中断してレディキュー１４１に退避させ、（３）ハードウェア割り込み要求のハードウェア割り込みハンドラを実行する。そして、マスタＯＳ１２１が、ハードウェア割り込みハンドラが呼び出すソフトウェア割り込みハンドラにより割り込みされるタスクＢがいずれのＣＰＵに割り当てられているかを特定する。ここでは、タスクＢがスレーブＣＰＵ１０２で実行中であるため、スレーブＣＰＵ１０２が特定される。
　マスタＯＳ１２１が、（４）プロセッサ間割り込み通信によりソフトウェア割り込み要求をスレーブＣＰＵ１０２に通知する。ハイパーバイザ１１２はプロセッサ間通信を監視し、スレーブＣＰＵ１０２への該プロセッサ間割り込み通信を検出する。そして、ハイパーバイザ１１２がユースケーステーブル１０００を用いてソフトウェア割り込み要求のソフトウェア割り込みハンドラが優先度の高い処理であるか否かを判断する。ここでは、ソフトウェア割り込み要求のソフトウェア割り込みハンドラが優先度の高い処理であるとする。
　つぎに、ハイパーバイザ１１２が、実行中のタスクを特定し、ユースケーステーブル１０００を用いて該実行中のタスクが該実行中のタスクに優先して割り込み処理を実行させることを許可しているか否かを判断する。ここで、タスクＢは割り込み可能なタスクであると判断される。
　タスクＢが割り込み可能なタスクであると判断されると、ハイパーバイザ１１２が、（５）スレーブＣＰＵ１０２に対して疑似ハードウェア割り込み要求を発生する。すなわち、ハードウェア割り込みレジスタにソフトウェア割り込み要求に対応する値を設定する。そして、スレーブＣＰＵ１０２がハードウェア割り込みレジスタに値が設定されることを検出することにより、ハードウェア割り込み要求を検出し、スレーブＯＳ１２２が、（６）実行中のタスクＢをレディキュー１４２へ退避させ、（７）ソフトウェア割り込み要求のソフトウェア割り込みハンドラを実行する。
　図１２は、実施例２において割り込み不可のタスクが実行状態を示す説明図（その１）である。図１２では、ハードウェア割り込みハンドラが呼び出すソフトウェア割り込みを受けるタスクをタスクＣとする。図１２の（１）～（４）については図１１の（１）～（４）と同一であるため、説明を省略する。
　ハイパーバイザ１１２はプロセッサ間通信を監視し、スレーブＣＰＵ１０２への該プロセッサ間割り込み通信を検出する。そして、ハイパーバイザ１１２が実行中のタスクを特定し、ユースケーステーブル１０００を用いて該実行中のタスクＣが割り込み可能なタスクであるか否かを判断する。ここで、タスクＣは割り込み不可のタスクであると判断される。そして、ハイパーバイザ１１２が、（５）ＰｒｏｃｅｓｓＩＤを０に設定する。スレーブＯＳ１２２がプロセステーブル１５１を用いてタスクＣが終了したかもしくはタスクの切り替えが発生するか否かを判断する。
　図１３は、実施例２において割り込み不可のタスクが実行状態を示す説明図（その２）である。（６）タスクＣが終了するもしくはタスクの切り替えが発生すると、スレーブＯＳ１２２は、タスクＣの終了を検出し、（７）ＰｒｏｃｅｓｓＩＤ＝１に設定する。ハイパーバイザ１１２は、（８）０から１へＰｒｏｃｅｓｓＩＤが変化したことを検出し、スレーブＣＰＵ１０２に対して疑似ハードウェア割り込み要求を発生させる。そして、該疑似ハードウェア割り込み要求が発生すると、スレーブＯＳ１２２が、（９）ソフトウェア割り込みハンドラを実行する。
（実施例２にかかるマルチコアプロセッサシステム１００による制御処理手順）
　図１４は、実施例２にかかるマルチコアプロセッサシステム１００による制御処理手順を示すフローチャートである。マスタＣＰＵ１０１の処理については図８で示した実施例１にかかるマルチコアプロセッサシステム１００による制御処理手順と同一であるため、図示せず説明を省略する。ここでは、マスタＣＰＵ１０１からプロセッサ間割り込み通信をスレーブＣＰＵ１０２が受けた場合の処理について説明する。なお、マスタＣＰＵ１０１の処理についてはステップＳ１４０１～ステップＳ１４０７（それぞれ図８のステップＳ８０１～ステップＳ８０７と同一）とする。
　まず、スレーブＣＰＵ１０２上で動作するハイパーバイザ１１２は、プロセッサ間通信を監視し、プロセッサ間割り込み通信を検出したか否かを判断する（ステップＳ１４０８）。ハイパーバイザ１１２が、プロセッサ間割り込み通信を検出していないと判断した場合（ステップＳ１４０８：Ｎｏ）、ステップＳ１４０８へ戻る。すなわち、ハイパーバイザ１１２は常時プロセッサ間通信を監視することにより、プロセッサ間割り込み通信を検出することができる。
　一方、ハイパーバイザ１１２が、プロセッサ間割り込み通信を検出したと判断した場合（ステップＳ１４０８：Ｙｅｓ）、ユースケーステーブル１０００を用いてソフトウェア割り込み要求のソフトウェア割り込みハンドラは優先度の高い処理であるか否かを判断する（ステップＳ１４０９）。ハイパーバイザ１１２が、ソフトウェア割り込みハンドラは優先度の高い処理であると判断した場合（ステップＳ１４０９：Ｙｅｓ）、実行中のタスクは割り込み可能なプロセスか否かを判断する（ステップＳ１４１０）。
　ハイパーバイザ１１２が、実行中のタスクは割り込み可能なプロセスでないと判断した場合（ステップＳ１４１０：Ｎｏ）、ＰｒｏｃｅｓｓｓＩＤ＝０とし（ステップＳ１４１１）、スレーブＯＳ１２２が、実行中のタスクが終了したか、またはタスクの切り替えが発生したか否かを判断する（ステップＳ１４１７）。スレーブＯＳ１２２が、該タスクが実行中であると判断した場合（ステップＳ１４１７：Ｎｏ）、ステップＳ１４１３に戻る。一方、スレーブＯＳ１２２が、実行中のタスクが終了した、またはタスクの切り替えが発生したと判断した場合（ステップＳ１４１７：Ｙｅｓ）、ＰｒｏｃｅｓｓＩＤ＝１とする（ステップＳ１４１８）。
　また、ステップＳ１４１１のつぎに、ハイパーバイザ１１２が、ＰｒｏｃｅｓｓＩＤが１か否かを判断し（ステップＳ１４１２）、ＰｒｏｃｅｓｓＩＤが１でないと判断した場合（ステップＳ１４１２：Ｎｏ）、ステップＳ１４１２へ戻る。一方、ＰｒｏｃｅｓｓＩＤが１であると判断した場合（ステップＳ１４１２：Ｙｅｓ）、ハードウェア割り込みレジスタにソフトウェア割り込み要求に関する値を設定する（ステップＳ１４１３）。
　スレーブＣＰＵ１０２が、ハードウェア割り込み要求を検出し（ステップＳ１４１４）、スレーブＯＳ１２２が、実行中のタスクを中断してレディキュー１４２に退避させる（ステップＳ１４１５）。つぎに、スレーブＯＳ１２２が、ソフトウェア割り込みハンドラを実行し（ステップＳ１４１６）、ステップＳ１４２０へ移行する。
　一方、ステップＳ１４０９において、ハイパーバイザ１１２が、ソフトウェア割り込みハンドラは優先度の高い処理でないと判断した場合（ステップＳ１４０９：Ｎｏ）、ソフトウェア割り込み要求をスレーブＯＳ１２２に通知する（ステップＳ１４１９）。スレーブＯＳ１２２が、ソフトウェア割り込みハンドラをレディキュー１４２に積むことで、ソフトウェア割り込みハンドラを待機させ（ステップＳ１４２０）、待機中の処理を待機順に実行し、ソフトウェア割り込みハンドラを実行する（ステップＳ１４２１）。
　ステップＳ１４１６またはステップＳ１４２１のつぎに、スレーブＯＳ１２２が、ソフトウェア割り込みハンドラが終了したか否かを判断する（ステップＳ１４２２）。スレーブＯＳ１２２が、ソフトウェア割り込みハンドラが終了していないと判断した場合（ステップＳ１４２２：Ｎｏ）、ステップＳ１４２０へ戻る。一方、スレーブＯＳ１２２が、ソフトウェア割り込みハンドラが終了したと判断した場合（ステップＳ１４２２：Ｙｅｓ）、マスタＣＰＵ１０１に完了を通知する（ステップＳ１４２３）。
　以上説明したように、マルチコアプロセッサシステム、制御プログラム、および制御方法によれば、特定のソフトウェア割り込み要求の割り込み処理を待機させずに実行中の処理に優先して実行させることにより、割り込みの応答時間を高速化することができる。
　また、特定のソフトウェア割り込み要求が特定のハードウェア割り込み要求に連動するソフトウェア割り込み要求であることにより、外部デバイスから割り込みの応答時間を高速化することができる。
　また、特定のハードウェア割り込み要求がユーザ操作によるハードウェア割り込み要求であることにより、ユーザ操作による割り込みの応答時間を高速化することができ、ユーザが応答時間によるストレスを感じることなく操作することができる。
　また、実行中の処理が該実行中の処理に優先してソフトウェア割り込み要求の割り込み処理を実行させることを許可していない場合、実行中の処理が終了後もしくはタスクの切り替えが発生するときに該割り込み処理を実行させる。これにより、優先度の高い実行中の処理を止めることなく、割り込みの応答時間を高速化できる。
　１００　マルチコアプロセッサシステム
　６０１　第１の実行部
　６０２　第２の実行部
　６０３　要求判断部
　６０４　優先判断部
　６０５　実行制御部

Claims (6)

  1. 　マルチコアプロセッサのうちの一のコアへのソフトウェア割り込み要求の割り込み処理を待機させ、待機中の処理を待機順に前記一のコアで実行する第１の実行手段と、
    　前記一のコアへのハードウェア割り込み要求の割り込み処理を前記一のコアで実行中の処理に優先して実行する第２の実行手段と、
    　前記ソフトウェア割り込み要求が特定のソフトウェア割り込み要求であるか否かを判断する要求判断手段と、
    　前記要求判断手段により前記ソフトウェア割り込み要求が前記特定のソフトウェア割り込み要求であると判断された場合、前記ソフトウェア割り込み要求の割り込み処理を前記第１の実行手段により待機させず、前記第２の実行手段により優先して実行させる実行制御手段と、
    　を備えることを特徴とするマルチコアプロセッサシステム。
  2. 　前記特定のソフトウェア割り込み要求が、特定のハードウェア割り込み要求に連動するソフトウェア割り込み要求であることを特徴とする請求項１に記載のマルチコアプロセッサシステム。
  3. 　前記特定のハードウェア割り込み要求が、ユーザ操作によって発生するハードウェア割り込み要求であることを特徴とする請求項２に記載のマルチコアプロセッサシステム。
  4. 　前記要求判断手段により前記ソフトウェア割り込み要求が前記特定のソフトウェア割り込み要求であると判断された場合、前記実行中の処理が該実行中の処理に優先して前記ソフトウェア割り込み要求の割り込み処理を実行することを許可しているか否かを特定の基準に基づいて判断する優先判断手段と、を備え、
    　前記実行制御手段は、
    　前記優先判断手段により前記実行中の処理が前記実行中の処理に優先して前記ソフトウェア割り込み要求の割り込み処理を実行することを許可していないと判断した場合、前記一のコアで実行中の処理が終了後もしくは処理の切り替えを行う際に、前記ソフトウェア割り込み要求の割り込み処理を前記第２の実行手段により優先して実行させることを特徴とする請求項１～３のいずれか一つに記載のマルチコアプロセッサシステム。
  5. 　マルチコアプロセッサのうちの一のコアへのソフトウェア割り込み要求の割り込み処理を待機させ、待機中の処理を待機順に前記一のコアで実行する第１の実行工程と、前記一のコアへのハードウェア割り込み要求の割り込み処理を前記一のコアで実行中の処理に優先して実行する第２の実行工程とを備える前記一のコアに、
    　前記ソフトウェア割り込み要求が特定のソフトウェア割り込み要求であるか否かを判断する要求判断工程と、
    　前記要求判断工程により前記ソフトウェア割り込み要求が前記特定のソフトウェア割り込み要求であると判断された場合、前記ソフトウェア割り込み要求の割り込み処理を前記第１の実行工程により待機させず、前記第２の実行工程により優先して実行させる実行制御工程と、
    　を実行させることを特徴とする制御プログラム。
  6. 　マルチコアプロセッサのうちの一のコアへのソフトウェア割り込み要求の割り込み処理を待機させ、待機中の処理を待機順に前記一のコアで実行する第１の実行工程と、前記一のコアへのハードウェア割り込み要求の割り込み処理を前記一のコアで実行中の処理に優先して実行する第２の実行工程とを備える前記一のコアが、
    　前記ソフトウェア割り込み要求が特定のソフトウェア割り込み要求であるか否かを要求判断する判断工程と、
    　前記要求判断工程により前記ソフトウェア割り込み要求が前記特定のソフトウェア割り込み要求であると判断された場合、前記ソフトウェア割り込み要求の割り込み処理を前記第１の実行工程により待機させず、前記第２の実行工程により優先して実行させる実行制御工程と、
    　を実行することを特徴とする制御方法。
PCT/JP2010/055711 2010-03-30 2010-03-30 マルチコアプロセッサシステム、制御プログラム、および制御方法 WO2011121730A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2012507955A JP5673672B2 (ja) 2010-03-30 2010-03-30 マルチコアプロセッサシステム、制御プログラム、および制御方法
PCT/JP2010/055711 WO2011121730A1 (ja) 2010-03-30 2010-03-30 マルチコアプロセッサシステム、制御プログラム、および制御方法
CN201080065900.4A CN102822802B (zh) 2010-03-30 2010-03-30 多核处理器系统以及控制方法
US13/628,709 US9092255B2 (en) 2010-03-30 2012-09-27 Multi-core processor system, computer product, and control method for interrupt execution

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/055711 WO2011121730A1 (ja) 2010-03-30 2010-03-30 マルチコアプロセッサシステム、制御プログラム、および制御方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/628,709 Continuation US9092255B2 (en) 2010-03-30 2012-09-27 Multi-core processor system, computer product, and control method for interrupt execution

Publications (1)

Publication Number Publication Date
WO2011121730A1 true WO2011121730A1 (ja) 2011-10-06

Family

ID=44711520

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/055711 WO2011121730A1 (ja) 2010-03-30 2010-03-30 マルチコアプロセッサシステム、制御プログラム、および制御方法

Country Status (4)

Country Link
US (1) US9092255B2 (ja)
JP (1) JP5673672B2 (ja)
CN (1) CN102822802B (ja)
WO (1) WO2011121730A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2687969A3 (en) * 2012-07-16 2015-11-11 Samsung Electronics Co., Ltd Electronic apparatus and control method of the same
US9355506B2 (en) 2014-06-27 2016-05-31 Continental Automotive France Method for managing fault messages of a motor vehicle

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2514126A (en) * 2013-05-14 2014-11-19 Ibm Interruption of chip component managing tasks
CN103559085B (zh) * 2013-10-21 2016-10-05 福建星网锐捷通讯股份有限公司 一种嵌入式系统中进行中断以及临界事件管理操作的方法
US9841993B2 (en) * 2013-12-27 2017-12-12 Hitachi, Ltd. Realtime hypervisor with priority interrupt support
US9661339B2 (en) * 2014-01-21 2017-05-23 Intel Corporation Multi-core architecture for low latency video decoder
US10083134B2 (en) * 2015-11-28 2018-09-25 International Business Machines Corporation Configurable processor interrupts for allowing an application to independently handle interrupts
DE102016003362A1 (de) * 2016-03-18 2017-09-21 Giesecke+Devrient Currency Technology Gmbh Einrichtung und Verfahren zur Auswertung von Sensordaten für ein Wertdokument
US10747565B2 (en) * 2017-04-18 2020-08-18 Amazon Technologies, Inc. Virtualization of control and status signals
CN109800073B (zh) * 2019-01-28 2021-06-18 Oppo广东移动通信有限公司 实时进程的调度方法、装置、终端及存储介质
US10692519B1 (en) * 2019-03-04 2020-06-23 Microsoft Tchnology Licensing, LLC Adjustable seek energy settings in storage device systems
US11726823B2 (en) 2020-02-06 2023-08-15 Samsung Electronics Co., Ltd. Electronic device having heterogeneous processors and method of processing task using the heterogeneous processors

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11272632A (ja) * 1998-03-19 1999-10-08 Sharp Corp マルチプロセッサシステム
JP2000056986A (ja) * 1998-04-16 2000-02-25 Sun Microsyst Inc ソフトウエア割り込み機構
JP2003044291A (ja) * 2001-07-30 2003-02-14 Mitsubishi Electric Corp リアルタイムオペレーティングシステムシミュレータ及びリアルタイムオペレーティングシステムシミュレーション方法及びプログラム及びプログラムを記録するコンピュータ読み取り可能な記録媒体
JP2007141155A (ja) * 2005-11-22 2007-06-07 Hitachi Kokusai Electric Inc マルチコアプロセッサにおけるマルチコア制御方法

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6845419B1 (en) 2000-01-24 2005-01-18 Freescale Semiconductor, Inc. Flexible interrupt controller that includes an interrupt force register
US7080178B2 (en) * 2004-02-09 2006-07-18 Arm Limited Interrupt pre-emption and ordering within a data processing system
US7206884B2 (en) * 2004-02-11 2007-04-17 Arm Limited Interrupt priority control within a nested interrupt system
JP4148223B2 (ja) * 2005-01-28 2008-09-10 セイコーエプソン株式会社 プロセッサおよび情報処理方法
JP4247228B2 (ja) 2005-11-28 2009-04-02 株式会社日立製作所 ヘテロマルチプロセッサシステムおよびそのｏｓ構成方法
GB2454885B (en) * 2007-11-21 2012-06-06 Advanced Risc Mach Ltd Interrupt jitter suppression
JP2009301116A (ja) * 2008-06-10 2009-12-24 Yokogawa Electric Corp 割り込み装置及びこれを備えた割り込みシステム
JP5353227B2 (ja) 2008-12-24 2013-11-27 富士通株式会社 性能測定プログラム及び性能測定方法並びに性能測定機能を有する情報処理装置。

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11272632A (ja) * 1998-03-19 1999-10-08 Sharp Corp マルチプロセッサシステム
JP2000056986A (ja) * 1998-04-16 2000-02-25 Sun Microsyst Inc ソフトウエア割り込み機構
JP2003044291A (ja) * 2001-07-30 2003-02-14 Mitsubishi Electric Corp リアルタイムオペレーティングシステムシミュレータ及びリアルタイムオペレーティングシステムシミュレーション方法及びプログラム及びプログラムを記録するコンピュータ読み取り可能な記録媒体
JP2007141155A (ja) * 2005-11-22 2007-06-07 Hitachi Kokusai Electric Inc マルチコアプロセッサにおけるマルチコア制御方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2687969A3 (en) * 2012-07-16 2015-11-11 Samsung Electronics Co., Ltd Electronic apparatus and control method of the same
US9355506B2 (en) 2014-06-27 2016-05-31 Continental Automotive France Method for managing fault messages of a motor vehicle

Also Published As

Publication number Publication date
US9092255B2 (en) 2015-07-28
US20130024589A1 (en) 2013-01-24
CN102822802A (zh) 2012-12-12
JP5673672B2 (ja) 2015-02-18
CN102822802B (zh) 2016-08-03
US20150081942A9 (en) 2015-03-19
JPWO2011121730A1 (ja) 2013-07-04

Similar Documents

Publication Publication Date Title
JP5673672B2 (ja) マルチコアプロセッサシステム、制御プログラム、および制御方法
CN105074666B (zh) 执行在具有不同指令集架构的处理器上的操作系统
US9207943B2 (en) Real time multithreaded scheduler and scheduling method
JP2006243865A (ja) プロセッサおよび情報処理方法
US9164799B2 (en) Multiprocessor system
US7366814B2 (en) Heterogeneous multiprocessor system and OS configuration method thereof
JP4609113B2 (ja) プロセッサ
JPWO2011104823A1 (ja) マルチコアプロセッサシステム、スレッド制御方法、およびスレッド制御プログラム
EP4386554A1 (en) Instruction distribution method and device for multithreaded processor, and storage medium
US20180267829A1 (en) Method for configuring an it system, corresponding computer program and it system
EP2546744B1 (en) Software control device, software control method, and software control program
JP5862722B2 (ja) マルチコアプロセッサシステム、マルチコアプロセッサシステムの制御方法、およびマルチコアプロセッサシステムの制御プログラム
CN113032154B (zh) 一种虚拟cpu的调度方法、装置、电子设备及存储介质
US7702836B2 (en) Parallel processing device and exclusive control method
JP5376042B2 (ja) マルチコアプロセッサシステム、スレッド切り替え制御方法、およびスレッド切り替え制御プログラム
US10121001B1 (en) System and method for monolithic scheduling in a portable computing device using a hypervisor
JP5017784B2 (ja) プロセッサ及びこのプロセッサ適用される割込み処理制御方法
US20140201505A1 (en) Prediction-based thread selection in a multithreading processor
JP4389797B2 (ja) プロセッサおよび情報処理方法
JP3022398B2 (ja) 仮想計算機方式
KR20190027460A (ko) 멀티 프로세서를 방식의 정지영상 처리 장치 및 방법
JP5601414B2 (ja) マルチコアプロセッサシステム、制御方法、および制御プログラム
JP2014017013A (ja) マルチコアプロセッサシステム、マルチコアプロセッサシステムの制御方法、およびマルチコアプロセッサシステムの制御プログラム
JP2016151917A (ja) 情報処理装置、情報処理制御方法および情報処理装置制御プログラム
JP2014059611A (ja) プロセッサおよびデバッグ装置

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201080065900.4

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10848909

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2012507955

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10848909

Country of ref document: EP

Kind code of ref document: A1