WO2012124125A1 - システムおよびスケジューリング方法 - Google Patents

システムおよびスケジューリング方法 Download PDF

Info

Publication number
WO2012124125A1
WO2012124125A1 PCT/JP2011/056468 JP2011056468W WO2012124125A1 WO 2012124125 A1 WO2012124125 A1 WO 2012124125A1 JP 2011056468 W JP2011056468 W JP 2011056468W WO 2012124125 A1 WO2012124125 A1 WO 2012124125A1
Authority
WO
WIPO (PCT)
Prior art keywords
processing
accelerator
cpu
value
time
Prior art date
Application number
PCT/JP2011/056468
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 PCT/JP2011/056468 priority Critical patent/WO2012124125A1/ja
Priority to JP2013504498A priority patent/JP5772948B2/ja
Publication of WO2012124125A1 publication Critical patent/WO2012124125A1/ja
Priority to US14/027,712 priority patent/US9672076B2/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/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5094—Allocation of resources, e.g. of the central processing unit [CPU] where the allocation takes into account power or heat criteria
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234—Power saving characterised by the action undertaken
    • G06F1/3293—Power saving characterised by the action undertaken by switching to a less power-consuming processor, e.g. sub-CPU
    • 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/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5044—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering hardware capabilities
    • 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/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/508—Monitor
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Definitions

  • the present invention relates to a system and a scheduling method for selecting a processor or an accelerator as an execution destination suitable for processing.
  • the system is provided with a general-purpose processor, and a number of processes are executed by the processor.
  • a dedicated processing circuit called a hardware engine or accelerator is provided in the system. This accelerator is used for specific processing.
  • processors are highly versatile, but inferior to accelerators in terms of power consumption and processing performance. For this reason, high performance and low power consumption can be realized by effectively utilizing the accelerator.
  • a single process if this single process can be executed by an accelerator, the execution by the accelerator is superior in terms of power and performance.
  • Patent Document 1 When the technology of Patent Document 1 newly requests processing from an accelerator, the processing will be requested based on the expected processing time of processing that is currently waiting for processing by the accelerator, and the expected processing time and start time of the processing that is being requested by the accelerator. The end time of the process is estimated. If the accelerator does not finish processing by the expected time, the processing is performed by the processor.
  • a processing time index value is set for each process that can be executed by the accelerator, and the process is first executed by the processor. Then, when an index value that does not end the processing in the processor within the set processing time is not satisfied, the processing is executed by the accelerator.
  • this optimum operating point always changes depending on the situation such as the remaining battery level. Assuming use in a portable terminal, if the remaining battery level is abundant, even if the power consumption increases, the processing giving priority to the performance may be sufficient. However, when the remaining amount of the battery is decreasing, it is desired to suppress the power consumption as much as possible so that the driving with the battery can be continued until the battery of the portable terminal is charged.
  • the disclosed system and scheduling method solve the above-mentioned problems, determine the execution speed by estimating the processing speed and power consumption when processing by the CPU and the accelerator, and reduce processing efficiency and power consumption. It aims to be compatible.
  • the disclosed technology includes a CPU and an accelerator, and the execution destination determination unit determines whether to execute the process (first process) by the CPU or the accelerator. .
  • the execution destination determination unit includes a first value based on a first processing time until the CPU completes the first process and a second processing time until the accelerator completes the first process, and a first value based on the remaining battery level.
  • An index value comparison unit that compares two values and an allocation destination determination unit that selects either the CPU or the accelerator based on the comparison result of the index value comparison unit.
  • FIG. 1 is a block diagram of a configuration example of a system according to the embodiment.
  • FIG. 2 is a block diagram showing an example of the internal configuration of the operating system.
  • FIG. 3 is a diagram for explaining an end time for each execution destination.
  • FIG. 4 is a chart showing an example of the power performance index value with respect to the load amount.
  • FIG. 5 is a chart showing an example of the power consumption priority index value with respect to the remaining battery capacity.
  • FIG. 6 is a flowchart showing an outline of processing related to execution destination determination in the mobile terminal.
  • FIG. 7 is a diagram showing information recorded in the ROM by the design phase.
  • FIG. 8 is a diagram showing information recorded in the memory in the execution phase.
  • FIG. 9 is a time chart showing a state in which the CPU executes a plurality of processes.
  • FIG. 10 is a flowchart showing the processing contents of execution destination determination by the execution destination determination unit.
  • FIG. 11 is a flowchart illustrating processing after the processing by the accelerator is completed by the execution destination determination unit.
  • FIG. 12A is a flowchart illustrating a processing flow for detecting an increase in processing load.
  • FIG. 12B is a flowchart of a process flow for detecting a decrease in process load.
  • FIG. 13A is a diagram illustrating a flow of a processing request when the load increases.
  • FIG. 13B is a diagram for explaining the end time of the process when the load increases.
  • FIG. 14A is a diagram illustrating a flow of a processing request when the load increases over time.
  • FIG. 14B is a diagram for explaining the end time of the process when the load increases over time.
  • FIG. 15 is a flowchart illustrating a processing example of execution destination determination when the processing load increases.
  • FIG. 16A is a diagram illustrating a flow of a processing request when the load decreases.
  • FIG. 16B is a diagram for explaining the processing end time when the load decreases.
  • FIG. 17A is a diagram illustrating a flow of a processing request when the load decreases with time.
  • FIG. 17B is a diagram for explaining the end time of the process when the load decreases with time.
  • FIG. 18 is a flowchart illustrating a processing example of execution destination determination when the processing load is reduced.
  • the disclosed system includes a processor (CPU) that has high data processing versatility and high power consumption, and a hardware accelerator that is less versatile but has a specific processing speed faster than the CPU and low power consumption.
  • CPU central processing unit
  • a hardware accelerator that is less versatile but has a specific processing speed faster than the CPU and low power consumption.
  • the CPU or accelerator is selected to execute the process to be performed from now on.
  • a processing destination corresponding to a change in the remaining battery level can be appropriately selected, and both processing efficiency and low power consumption can be achieved.
  • the system will be described using an example in which the system is mounted on a portable terminal that operates on a battery.
  • FIG. 1 is a block diagram of a configuration example of a system according to the embodiment.
  • the disclosed system 100 includes a CPU 101, an accelerator (ACC) 102 that can be used via the CPU 101, a memory 103, a ROM 104, a timer 105 that measures the current time, a battery management unit 106, and the CPU 101 to battery management. And a bus (BUS) 107 connecting the unit 106.
  • the ROM 104 stores information such as processing time and power consumption for each of the CPU 101 and the accelerator 102.
  • the CPU 101 controls execution of application processing by an operating system (OS) 110.
  • OS operating system
  • the CPU 101 or the accelerator 102 is designated by the OS 110 as the execution destination of the application.
  • the CPU 101 is determined as the execution destination, the CPU execution code is output to the CPU 101 through the path A in the figure.
  • the accelerator 102 is determined as an execution destination, the accelerator execution code is output to the accelerator 102 via the CPU 101 along the path B in the figure.
  • FIG. 2 is a block diagram showing an example of the internal configuration of the operating system.
  • the OS 110 includes an execution destination determination unit 111 and a process management unit 113.
  • the execution destination determination unit 111 determines the execution destination of application processing as either the CPU 101 or the accelerator 102.
  • the process management unit 113 manages processes and thread of processes when executing applications. Also, the number of operating threads is notified to the operating thread number acquiring unit 122 of the execution destination determining unit 111, and notified every time the number of operating threads increases or decreases.
  • the process management unit 113 functions as a monitoring unit that monitors the processing load of the CPU 101.
  • the execution destination determination unit 111 includes a processing request reception unit 121, an operating thread number acquisition unit 122, a queue management unit 123, a ROM information acquisition unit 124, a processing thread management unit 125, and an index value.
  • a processing unit 126, a terminal state acquisition unit 127, an accelerator management unit 128, and an allocation destination determination unit (selection unit) 129 are included.
  • the index value processing unit 126 includes an index value calculation unit (calculation unit) 126a that calculates a power performance index value (first value) and a power consumption priority index value (second value), and a power performance index value (first value). ) And a power consumption priority index value (second value), an index value comparison unit (comparison unit) 126b is included.
  • the processing request reception unit 121 receives processing request addition or load increase / decrease notification from the thread of the application to be executed, and starts processing by the execution destination determination unit 111.
  • the operating thread number acquisition unit 122 acquires the number of currently operating threads from the process management unit 113.
  • the queue management unit 123 adds / deletes processing requests to / from the execution queue of the accelerator 102 and acquires queued processing request information.
  • the ROM information acquisition unit 124 acquires processing time and power consumption information recorded in the ROM 104.
  • the processing thread management unit 125 performs processing thread activation, processing assignment, end detection, cancellation, acquisition of remaining processing time, and the like when a processing request is executed by the CPU 101.
  • the index value processing unit 126 calculates a power performance index value and a power consumption priority index value, which are indexes necessary for determining the execution destination of the application.
  • the terminal state acquisition unit 127 acquires the remaining battery level from the battery management unit 106.
  • the use state of the mobile terminal (open / close state of the lid that opens / closes according to the use / non-use, presence / absence of the connection state to the power source, etc.) is acquired from a detection unit (not shown) provided in the mobile terminal.
  • the accelerator management unit 128 manages processing performed by the accelerator, such as assignment of the processing request at the head of the queue to the accelerator and detection of the end of processing in the accelerator.
  • the allocation destination determination unit 129 determines whether the processing request is executed by the CPU 101 or the accelerator 102.
  • FIG. 3 is a diagram for explaining an end time for each execution destination.
  • the execution destination determination unit 111 estimates a processing end time when one process (first processing) of the application is performed by the CPU 101 and a processing end time when the processing is performed by the accelerator 102, respectively. Then, a processing time (first processing time) when the first processing is performed by the CPU 101 and a processing time (second processing time) when the first processing is performed by the accelerator 102 are calculated.
  • the difference between the first processing time and the second processing time is compared from the first processing time and the second processing time.
  • the difference between the power consumption (first power consumption) required for the processing of the CPU 101 required by the first processing time and the power consumption (second power consumption) required for the processing of the accelerator 102 required by the second processing time is obtained.
  • the power performance index value is obtained from this difference.
  • the execution destination determination unit 111 uses the power performance index value and the power consumption priority index value relating to the power consumption of the mobile terminal such as the remaining battery level acquired by the terminal state acquisition unit 127 to determine the first. Whether the CPU 101 or the accelerator 102 performs the process is selected, and the execution destination of the process is assigned.
  • the power consumption priority index value is used as a threshold for comparing with the power performance index value for execution destination determination.
  • FIG. 3 shows the processing time for each thread when the processing is performed by the CPU 101 and the accelerator (ACC) 102 by case.
  • Case 1 there are four threads 301 in the accelerator 102 and the fourth thread is going to be executed by the CPU 101.
  • the end time t1 in the CPU 101 is It is later than the end time t2 when executed in 102.
  • the power performance index value is negative. In other words, processing is completed earlier when all the threads are executed by the accelerator 102.
  • Case 3 is a case where the accelerator 102 has a large number (n) of threads 301 and the CPU 101 tries to execute the n-th thread.
  • the end time at the CPU 101 when the n-th thread is executed by the CPU 101 is shown.
  • t1 can be earlier than the end time t2 when executed by the accelerator 102.
  • the power performance index value is large.
  • the execution destination is determined depending on whether performance is prioritized or power consumption is prioritized.
  • the threshold value (power consumption priority index value to be described later) is 0 and the positive value is large or small. And it is good also as a structure which changes this threshold value with the state of a portable terminal, for example, the present battery residual amount. This point will be described in the power consumption priority index value described later.
  • the power performance index value is obtained by the index value processing unit 126 by the following calculation.
  • Power performance index value (end time t at accelerator 2 -end time t 1 at CPU) / (power consumption PH 1 at CPU 1 -power consumption PH 2 at accelerator)
  • the power consumption amount PH1 of the CPU 101 the power consumption P1 of the CPU ⁇ the processing time T1 required for processing by the CPU
  • the power consumption amount PH2 of the accelerator 102 the power consumption P2 of the accelerator ⁇ the processing time required for the processing of the accelerator.
  • P1, P2, and T1, T2, or PH1 and PH2 are fixed values that are recorded in the ROM 104 in advance by measurement in the design phase described later.
  • FIG. 4 is a chart showing an example of the power performance index value with respect to the load amount.
  • the load amount of the accelerator 102 and the power performance index value are proportional to each other.
  • the power performance index value increases as the load amount of the accelerator 102 increases.
  • the index value processing unit 126 has the following 1. ⁇ 3.
  • the power consumption priority index value is calculated by any of the above.
  • the battery remaining amount, the power connection state, the open / close state of the mobile terminal, and the like are acquired from the terminal state acquisition unit 127. 1.
  • the power consumption priority index value is calculated only from the remaining battery level.
  • Power consumption priority index value a ⁇ / remaining battery capacity ( ⁇ : arbitrary coefficient) This power consumption priority index value is used when the portable terminal is driven by a battery.
  • power consumption priority index value b 0 (the highest priority is given to performance)
  • power consumption priority index value a ⁇ / battery remaining amount
  • the power consumption priority index values a and b are set. select. For example, if the power supply placed in the cradle for charging the mobile terminal is being connected (during battery charging), the power consumption priority index value b is selected. If the mobile terminal is removed from the cradle and the battery is being driven, the power consumption priority index value a is selected.
  • a fixed value (such as the above-described value 0) may be used. Note that fixed values and coefficient values are determined from the required operating time and required performance of the mobile terminal during the design phase described later, and the power performance index value is compared with the threshold value of power consumption priority index. Keep it consistent with possible values.
  • the terminal state acquisition unit 127 acquires the remaining amount of the battery or the usage state of the mobile terminal related to the remaining amount of the battery, and the index value processing unit 126 obtains the power consumption priority index value.
  • FIG. 5 is a chart showing an example of the power consumption priority index value with respect to the remaining battery level.
  • the rate of change of the power consumption priority index value is increased as the remaining battery level is lower.
  • the ROM 104 stores information necessary at the time of design (design phase) before operation of the mobile terminal.
  • the execution destination determination unit 111 measures the processing time and power consumption when the CPU 101 performs processing that can be executed by the accelerator 102 and when the processing is performed by the accelerator 102, and records them in the ROM 104.
  • the execution destination determination unit 111 calculates a power performance index value based on the information recorded in the ROM 104, and assigns the allocation destination.
  • the determination unit 129 determines which of the CPU 101 and the accelerator 102 is the execution destination based on the power performance index value and the power consumption priority index value.
  • FIG. 6 is a flowchart showing an outline of processing related to execution destination determination in the mobile terminal.
  • the power consumption of the CPU 101 and the accelerator 102 is measured (step S601).
  • a process to be executed by the accelerator 102 is determined (step S602).
  • the processing time in the CPU 101 and the accelerator 102 is measured (step S603).
  • execution objects for the CPU 101 and the accelerator 102 are prepared (step S604).
  • an application to be run on the mobile terminal is developed, and processing to be performed by the accelerator 102 is determined from processing performed by the application.
  • program code for performing processing using the accelerator 102 from the application program and program code for performing processing having the same contents as the processing by the accelerator 102 are created.
  • the processing time when the program code is actually executed and processed by the accelerator 102 and when processed by the CPU 101 is actually measured.
  • the processing time is measured for each usage.
  • the power consumption of each of the CPU 101 and the accelerator 102 during this processing time is measured using a power meter or the like.
  • the measured power consumption and the processing time for each usage are recorded in the ROM 104.
  • the created application, the program code that performs processing using the accelerator 102, and the program code that performs the same processing as the accelerator 102 in the CPU 101 are also recorded in the ROM 104.
  • FIG. 7 is a diagram showing information recorded in the ROM by the design phase.
  • processing request information (1 to n) 701 for each processing of the application, CPU power consumption 721, and accelerator power consumption 722 are recorded.
  • the processing request of application processing 1 includes a CPU processing time 711, an accelerator processing time 712, a CPU execution code 713, and an accelerator execution code 714.
  • the execution phase S610 for operating the mobile terminal is entered.
  • the processing in the execution phase S610 first requests the OS 110 to start processing from the application (step S611). Thereby, the OS 110 determines the processing execution destination in the CPU 101 or the accelerator 102 and assigns it (step S612), and ends the series of processing.
  • this execution phase S610 when processing is performed by the accelerator 102 in the application (program), the OS 110 requests the accelerator 102 to perform processing. If the accelerator 102 is free in the OS 110, the program code using the accelerator recorded in the ROM 104 is executed to start processing in the accelerator 102. At this time, the type of processing to be activated and the activation time are recorded in the memory 103.
  • the OS 110 records each processing request using a queue-like data structure.
  • the OS 110 executes program code that uses the accelerator 102 based on the processing request at the head of the queue.
  • FIG. 8 is a diagram showing information recorded in the memory in the execution phase.
  • a plurality of processing requests are recorded in the processing request queue 801 (801a to 801n) in the memory 103, and are processed in order from the top processing request queue 801a.
  • CPU execution processing information 811 related to the CPU 101 and accelerator execution processing information 812 related to the accelerator 102 are recorded.
  • the CPU execution process information 811 includes a process request, a start time, and the like.
  • the accelerator execution process information 812 includes a process request, a start time, an end time, and the like.
  • whether or not to actually add a processing request to the processing request queue 801 is determined by the execution destination determination unit 111 in the OS 110.
  • the execution destination determination unit 111 determines whether the processing requested from the power performance index value and the power consumption priority index value is added to the processing request queue 801 or performed by the CPU 101.
  • the processing thread management unit 125 of the OS 110 switches threads to be executed in units of several milliseconds, and the plurality of threads are operating at the same time in one CPU 101. It looks like The processing thread management unit 125 determines how much time is allocated to which thread per unit time based on the priority information set for each thread. If the priorities are the same, all threads are allocated time evenly.
  • FIG. 9 is a time chart showing a state in which the CPU executes a plurality of processes. As shown in the example, if three threads 1 to 3 are operating at the same time, each thread 1 to 3 acquires the execution time by one third per unit time. That is, the time from the start of processing of each thread 1 to 3 of the CPU to the end of processing takes three times. Further, the processing thread management unit 125 of the OS 110 manages all how many threads are currently processed and how long the threads have been executed so far.
  • the index value processing unit 126 can calculate the end time t1 of each thread.
  • FIG. 10 is a flowchart showing the processing contents of execution destination determination by the execution destination determination unit. Processing performed by the execution destination determination unit 111 of the OS 110 will be described with reference to FIG.
  • the processing request reception unit 121 of the execution destination determination unit 111 performs the following processing to determine a processing execution destination for each processing request every time a processing request from an application is received (step S1001).
  • the ROM information acquisition unit 124 acquires processing times T1 and T2 in the CPU 101 and the accelerator 102 for processing corresponding to the processing request from the ROM 104 (step S1002). Further, the ROM information acquisition unit 124 acquires the power consumption P1 and P2 of the CPU 101 and the accelerator 102 from the ROM 104 (step S1003). Further, the execution destination determination unit 111 acquires the current time (step S1004).
  • the accelerator management unit 128 acquires a processing request and start time of processing performed by the accelerator 102 (step S1005).
  • the number of operating threads is acquired from the operating thread number acquiring unit 122 (step S1006).
  • the index value processing unit 126 of the execution destination determination unit 111 calculates the end time t1 of the CPU 101 and the end time t2 of the accelerator 102 for the process (thread), and calculates the power performance index value.
  • the power performance index value is determined by the end time t1 when the requested processing is performed by the CPU 101, the end time t2 when the requested processing is performed by the accelerator 102, and the CPU 101 and the accelerator 102, respectively. It calculates based on estimated power consumption PH1 and PH2 in the case.
  • the processing time T1 to be processed when the processing is performed by the CPU 101 is measured in the design phase S600 and recorded in the ROM 104. Therefore, the processing time corresponding to the corresponding processing is acquired from the ROM 104.
  • the end time t2 when the processing is performed by the accelerator 102 is the sum of the remaining processing time tn1 of the processing currently being performed by the accelerator 102 and the processing time of the unexecuted processing accumulated in the processing request queue 801.
  • tn2 is the sum of the processing time T2 and the start time t0 when the accelerator 102 performs the corresponding processing.
  • the processing times T1 and T2 of the processes of the CPU 101 and the accelerator 102 are measured and recorded in the ROM 104 in the design phase, the processing times T1 and T2 corresponding to the respective processing requests are acquired from the ROM 104. To do.
  • the power consumption amounts PH1 and PH2 are also read from the ROM 104 and used. Further, the index value processing unit 126 calculates a power consumption priority index value from the state of the mobile terminal (step S1008).
  • the power consumption priority index value is not limited to calculation, and a fixed value (for example, 0) can also be used. If the value is 0, the execution destination of the process is determined based only on the power performance index value. Since this power consumption priority index value is used as a threshold value for determining the value of the power performance index value, the execution destination of the process can be determined simply by comparing the power consumption priority index value and the power performance index value.
  • the allocation destination determination unit 129 of the execution destination determination unit 111 compares the power performance index value with the power consumption priority index value (step S1009). If the power performance index value is larger than the power consumption priority index value (step S1009: Yes), it is determined that the CPU 101 issues a processing request from the application. If the power performance index value is smaller than the power consumption priority index value (step S1009: No), it is determined that the accelerator 102 processes the processing request from the application.
  • the process management unit 113 of the OS 110 acquires the CPU execution code (program code) 713 corresponding to the process request for the target process recorded in the ROM 104. (Step S1010), the execution code acquired by generating a new process is executed in the process (Step S1011). Then, the process management unit 113 records the processing request executed by the CPU 101, the current time, and the calculated end time in the CPU execution processing information 811 of the memory 103 (step S1012), and ends one process.
  • step S1009 when the accelerator 102 is determined to execute the process (step S1009: No), the process management unit 113 acquires the operation status of the accelerator 102 from the accelerator management unit 128 (step S1013), and the accelerator 102 is operating. It is determined whether or not there is (step S1014). If the accelerator 102 is in operation (step S1014: Yes), a process request is added to the last process request queue 801n (step S1015), the process in the accelerator 102 is performed, and one process is completed.
  • step S1014 If it is determined in step S1014 that the accelerator 102 is not operating (step S1014: No), the process management unit 113 acquires the accelerator execution code 714 corresponding to the processing request from the ROM 104 (step S1016). Next, the process management unit 113 executes the acquired accelerator execution code 714 to activate the accelerator 102 (step S1017). Then, the process management unit 113 records the processing request executed by the accelerator 102 and the start time in the accelerator execution process information 812 of the memory 103 (step S1018), and ends one process.
  • FIG. 11 is a flowchart showing processing after the processing by the accelerator is completed by the execution destination determination unit.
  • the accelerator management unit 128 of the execution destination determination unit 111 detects the end of processing in the accelerator 102 (step S1101)
  • the process management unit 113 acquires a processing request from the top processing request queue 801a (step S1102). It is confirmed whether it has succeeded (step S1103). If the acquisition is successful (step S1103: Yes), the process is terminated.
  • step S1103 when the processing request from the top processing request queue 801a cannot be acquired (step S1103: No), the process management unit 113 acquires the accelerator execution code 714 corresponding to the processing request from the ROM 104 ( Step S1104). Next, the process management unit 113 activates the accelerator 102 by executing the acquired accelerator execution code 714 (step S1105). Then, the process management unit 113 records the processing request executed by the accelerator 102 and the start time in the accelerator execution processing information 812 of the memory 103 (step S1106), and ends one process.
  • the increase in the load is determined to be an increase in the load when, for example, an application different from the already started application is started or the number of threads (load) exceeds the setting when the load of the CPU 101 is monitored.
  • the decrease in the load is, for example, a decrease in the load when the application other than the already activated application ends or when the number of threads (load) more than the setting is decreased when the load of the CPU 101 is monitored.
  • FIG. 12-1 is a flowchart showing a processing flow for detecting an increase in processing load.
  • a new thread generation request or thread activation request is output from the application (step S1201).
  • the process management unit 113 generates or activates a thread (step S1202), and notifies the execution destination determination unit 111 of an increase in the number of operating threads (step S1203).
  • the execution destination determination unit 111 performs an execution destination determination process when the load increases based on the notified increase in the number of operating threads (step S1204).
  • FIG. 12-2 is a flowchart showing a processing flow for detecting a decrease in processing load.
  • a thread end notification or a thread stop request is output from the application (step S1211).
  • the process management unit 113 deletes the thread or stops the thread (step S1212), and notifies the execution destination determination unit 111 of the decrease in the number of operating threads (step S1213).
  • the execution destination determination unit 111 performs an execution destination determination process at the time of load reduction based on the notified decrease in the number of operating threads (step S1214).
  • an increase or decrease in processing load detects that the number of threads operating in the process management unit 113 has been changed in response to a request for adding, ending, stopping, or starting a thread from an application.
  • the execution destination determination unit 111 cancels the process in the CPU 101 and executes this process in the accelerator 102 when it is better to execute the new process in the accelerator 102 than in the CPU 101. .
  • the processing of the accelerator 102 is executed by the CPU 101. Specifically, the determination is made based on whether the CPU 101 or the accelerator 102 executes the process and can advance the end time of the entire process.
  • FIG. 13A is a diagram illustrating a flow of a processing request when the load increases
  • FIG. 13B is a diagram illustrating an end time of the processing when the load increases.
  • the end time t2 is calculated.
  • the process can be started at time t3 and end time t4.
  • the index value processing unit 126 calculates a power performance index value using these end times t2 and t4.
  • the allocation destination determination unit 129 determines that it is more efficient to perform processing by the CPU 101, activates the thread S1 in response to the processing request from the CPU 101, and performs processing by the CPU 101.
  • FIG. 14A is a diagram illustrating a flow of a processing request when the load increases over time
  • FIG. 14B is a diagram illustrating an end time of the processing when the load increases over time.
  • a new thread S2 is activated at time t1 '(t1 ⁇ t1' ⁇ t2) in FIG. 14-2 after a fixed time has elapsed from the processing described with reference to FIGS. 13-1 and 13-2.
  • the load on the CPU 101 increases, so the execution destination determination unit 111 executes a load increase process.
  • the end times t2 'and t4' when the process is executed by the CPU 101 and the accelerator 102 are recalculated on the basis of the time t1 '.
  • the allocation destination determination unit 129 determines that it is still more efficient to perform processing with the accelerator 102 from now on, cancels the processing of the thread S2 of the CPU 101, and adds the processing request S3 to the processing request queue 801. To do.
  • FIG. 15 is a flowchart illustrating a processing example of execution destination determination when the processing load increases. Processing performed by the execution destination determination unit 111 will be described below.
  • the processing request reception unit 121 of the execution destination determination unit 111 acquires a processing request executed by the CPU 101 from the ROM 104 by the ROM information acquisition unit 124. (Step S1502). Then, it is determined whether a processing request has been acquired (step S1503). If the process request cannot be acquired (step S1503: No), the process ends. If the process request can be acquired (step S1503: Yes), then the start time and end of the process executed by the CPU 101 from the memory 103 Time is acquired (step S1504).
  • the ROM information acquisition unit 124 acquires the processing time corresponding to the processing request in the CPU 101 and the accelerator 102 from the ROM 104 (step S1505). Further, the CPU 101 and the power consumption of the accelerator 102 are acquired from the ROM 104 (step S1506). Further, the execution destination determination unit 111 acquires the current time (step S1507).
  • the accelerator management unit 128 acquires a processing request and start time of processing performed by the accelerator 102 (step S1508).
  • the number of operating threads is acquired from the operating thread number acquiring unit 122 (step S1509).
  • the index value processing unit 126 of the execution destination determining unit 111 sets the new end time of the CPU 101 for the process (thread) (end time t2 ′ in the example of FIG. 14-2) and the new end time of the accelerator 102. (End time t4 ′ in the example of FIG. 14-2) and the power performance index value are calculated (step S1510).
  • the index value processing unit 126 calculates a power consumption priority index value from the state of the mobile terminal (step S1511).
  • the allocation destination determination unit 129 of the execution destination determination unit 111 compares the power performance index value with the power consumption priority index value (step S1512). If the power performance index value is larger than the power consumption priority index value (step S1512: Yes), it is determined that the CPU 101 issues a processing request from the application. Then, the end time is updated to the calculated new end time, the CPU execution process information 811 is updated (step S1513), and the process ends.
  • step S1512 If the power performance index value is smaller than the power consumption priority index value (step S1512: No), it is determined that the accelerator 102 processes the processing request from the application. Then, the process management unit 113 cancels the execution of the process being processed by the CPU 101 (step S1514), and acquires the operating status of the accelerator 102 from the accelerator management unit 128 (step S1515). Thereafter, it is determined whether or not the accelerator 102 is operating (step S1516). If the accelerator 102 is in operation (step S1516: Yes), a process request is added to the last process request queue 801n (step S1517), the process in the accelerator 102 is performed, and one process is completed.
  • step S1516 the process management unit 113 acquires the accelerator execution code 714 corresponding to the processing request from the ROM 104 (step S1518). Next, the process management unit 113 executes the acquired accelerator execution code 714 to activate the accelerator 102 (step S1519). Then, the process management unit 113 records the processing request executed by the accelerator 102 and the start time in the accelerator execution process information 812 of the memory 103 (step S1520), and ends one process.
  • FIG. 16A is a diagram illustrating a flow of a process request when the load is decreased
  • FIG. 16B is a diagram illustrating an end time of the process when the load is decreased.
  • the allocation destination determination unit 129 determines that the processing by the accelerator 102 is more efficient, and adds the processing request S11 to the processing request queue 801.
  • FIG. 17A is a diagram illustrating a flow of a processing request when the load decreases with the passage of time
  • FIG. 17B is a diagram illustrating an end time of the processing when the load decreases with the passage of time.
  • the execution destination determination unit 111 recalculates the end time in the same way as when the load is increased.
  • the start time t3 and end time t4 in the accelerator 102 are It remains unchanged.
  • the end time is changed to t2 'because the processing load on the CPU 101 is reduced.
  • the process request S12 is extracted (deleted) from the last process request queue 801n. And execute in a thread.
  • FIG. 18 is a flowchart illustrating a processing example of execution destination determination when the processing load is reduced. Processing performed by the execution destination determination unit 111 will be described below.
  • the process management unit 113 detects a decrease in processing load (step S1801)
  • the queue management unit 123 of the execution destination determination unit 111 acquires a processing request from the last processing request queue 801n of the memory 103 (step S1802). Then, it is determined whether a processing request has been acquired (step S1803). If the processing request cannot be acquired (step S1803: No), the processing ends.
  • step S1803 Yes
  • the CPU 101 of the processing corresponding to the processing request from the ROM 104 and the accelerator 102 The processing time is acquired (step S1804). Further, the CPU 101 and the power consumption of the accelerator 102 are acquired from the ROM 104 (step S1805). Further, the execution destination determination unit 111 acquires the current time (step S1806).
  • the accelerator management unit 128 acquires a processing request and start time of processing performed by the accelerator 102 (step S1807).
  • the number of operating threads is acquired from the operating thread number acquiring unit 122 (step S1808).
  • the index value processing unit 126 of the execution destination determination unit 111 sets the new end time of the CPU 101 for the process (thread) (end time t2 ′ in the example of FIG. 17-2) and the new end time of the accelerator 102. (End time t4 in the example of FIG. 17-2) is calculated, and the power performance index value is calculated (step S1809). Further, the index value processing unit 126 calculates the power consumption priority index value from the state of the mobile terminal (step S1810).
  • the allocation destination determination unit 129 of the execution destination determination unit 111 compares the power performance index value with the power consumption priority index value (step S1811). If the power performance index value is larger than the power consumption priority index value (step S1811: Yes), it is determined that the CPU 101 issues a processing request from the application. Then, the target process is deleted from the process request queue 801 (step S1812), and the CPU execution code 713 is acquired from the ROM 104 (step S1813).
  • the process management unit 113 sets to execute the CPU execution code 713 generated and acquired by the new process corresponding to the process (step S1814). Then, the process request executed by the CPU 101 in the CPU execution process information 811, the start time, and the calculated end time are recorded (step S 1815), and the process ends.
  • step S1811 NO
  • step S1816 the previous process request in the process request queue 801 is acquired (step S1816), and the process returns to step S1803. The above process is executed.
  • the CPU 101 when the CPU 101 can perform processing due to processing load fluctuations, the CPU 101 is reconsidering whether the processing accumulated in the processing request queue 801 to be performed by the accelerator 102 can be performed by the CPU 101. At this time, based on the number of threads operating in the CPU 101 in order from the last processing request queue 801n processing (the vacancy rate may be used), the determination is repeated in the same processing as when processing is newly requested. . When processing is to be performed by the CPU 101, the processing is taken out from the processing request queue 801 and executed by the CPU 101.
  • the execution destination of the process is determined as to which process is completed earlier, so that the processing efficiency for each of the plurality of processes is improved. be able to. Furthermore, the power consumption when processing is executed by an accelerator and processor is obtained, and this power consumption is used as a power performance index value to determine the processing execution destination. Efficient execution destination.
  • the execution destination is determined together with the power performance index value using the power consumption priority index value determined from the current state of the mobile terminal, for example, the remaining battery level.
  • the execution destination of the process corresponding to the current remaining battery level, corresponding to the remaining battery level of the mobile terminal that changes over time. For this reason, it is possible to determine for each process an optimal execution destination that balances not only the processing efficiency but also the power consumption required for the process execution, and it is possible to achieve both the processing efficiency of the entire system and a reduction in power consumption.

Landscapes

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

Abstract

　実行先決定部（１１１）は、処理の実行をＣＰＵあるいはアクセラレータに決定する。この決定のために、実行先決定部（１１１）は、ＣＰＵが第１処理を完了するまでの第１処理時間とアクセラレータが第１処理を完了するまでの第２処理時間とに基づく第１値と、ＣＰＵおよびアクセラレータを駆動するバッテリの使用状態に基づく第２値とを比較する指標値比較部（１２６ｂ）と、指標値比較部（１２６ｂ）の比較結果に基づいて、ＣＰＵまたはアクセラレータのいずれかを選択する割り付け先決定部（１２９）と、を含む。

Description

システムおよびスケジューリング方法
　本発明は、処理に適した実行先としてプロセッサあるいはアクセラレータを選択するシステムおよびスケジューリング方法に関する。
　システムには汎用のプロセッサが設けられ、多数の処理をプロセッサで実行する。動画処理や音声処理、３Ｄグラフィック処理、信号処理のような高い処理性能が求められるが処理の内容は決まっているといった特定の処理については、システムにハードウェアエンジンやアクセラレータと呼ばれる処理専用回路を設け、このアクセラレータにより特定の処理をおこなわせている。
　一般に、プロセッサは汎用性が高い反面、消費電力や処理性能の面ではアクセラレータに劣る。このため、アクセラレータを有効活用することで高性能かつ低消費電力を実現できる。単一の処理に関してだけみれば、この単一処理がアクセラレータで実行可能なら、アクセラレータで実行した方が電力面でも性能面でも優れていることになる。
　ここで、非常に多くの処理がアクセラレータで実行可能であるが、プロセッサでのみおこなえる処理がごく少数しかなかったと仮定する。この場合、アクセラレータで実行可能な処理を、全てアクセラレータでおこなうとアクセラレータ側が非常に混雑し、アクセラレータでの処理が遅延する結果、システム全体の処理効率を低下させるおそれがある。このため、アクセラレータで実行可能な処理であっても一部をプロセッサでおこなう手法が開示されている（たとえば、下記特許文献１，２参照。）。
　特許文献１の技術は、新たにアクセラレータに処理を要求するときに、現在アクセラレータで処理待ちの処理の予想処理時間と、要求しようとしている処理のアクセラレータでの予想処理時間と開始時刻から、要求しようとしている処理の終了時刻を推定する。そして、アクセラレータでは期待している時刻までに処理が終了しない場合は、その処理をプロセッサでおこなうというものである。
　また、特許文献２の技術は、アクセラレータで実行可能なそれぞれの処理に、処理時間の指標値を設定しておき、まず処理をプロセッサで実行しておく。そして、設定された処理時間以内にプロセッサでの処理が終わらないといった指標値を満たさない場合に、アクセラレータで実行するというものである。
特開２００６－３０２１６８号公報 特開２０１０－７２７３１号公報
　処理時間の観点でみれば、アクセラレータが混んでいる場合に一部をプロセッサでおこなった方が効率が良いこともあるが、消費電力の観点でみれば、アクセラレータで実行可能な処理は全てアクセラレータでおこなった方が消費電力量は少なくなる。
　このため、必要な処理時間（性能）と、消費電力との兼ね合い（トレードオフ）を考慮して最適な動作点を決定する必要があるが、従来はこれをおこなうことができなかった。
　たとえば、携帯電話端末のようなバッテリで動作する携帯端末の場合、この最適な動作点はバッテリの残量等の状況により常に変化する。携帯端末での使用を想定すると、バッテリ残量が豊富にある場合には、消費電力が増えたとしても性能を優先する処理で良い。しかし、バッテリ残量が少なくなってきた場合には、携帯端末のバッテリを充電するまでの間は、バッテリでの駆動が持続できるように消費電力は極力抑えたい状況となる。
　上記従来の特許文献１の技術では、性能しか指標として利用できず、また、特許文献２の技術では、固定の指標を前提としているため、携帯端末のようにバッテリ残量に応じて最適な動作点が動的に変化する機器には適用できない。
　開示のシステムおよびスケジューリング方法は、上述した問題点を解消するものであり、ＣＰＵとアクセラレータで処理した際の処理速度と消費電力を推定して実行先を決定し、処理効率と低消費電力化を両立することを目的とする。
　上述した課題を解決し、目的を達成するため、開示技術は、ＣＰＵと、アクセラレータとを備え、実行先決定部により処理（第１処理）をＣＰＵあるいはアクセラレータのいずれでおこなうかを決定し実行させる。この実行先決定部は、ＣＰＵが第１処理を完了するまでの第１処理時間とアクセラレータが第１処理を完了するまでの第２処理時間とに基づく第１値と、バッテリ残量に基づく第２値とを比較する指標値比較部と、指標値比較部の比較結果に基づいて、ＣＰＵまたはアクセラレータのいずれかを選択する割り付け先決定部と、を含む。
　開示のシステムおよびスケジューリング方法によれば、ＣＰＵとアクセラレータで処理した際の処理速度と消費電力を推定して実行先を決定し、処理効率と低消費電力化を両立できるという効果を奏する。
図１は、実施の形態にかかるシステムの構成例を示すブロック図である。 図２は、オペレーティングシステムの内部構成例を示すブロック図である。 図３は、実行先別の終了時刻を説明するための図である。 図４は、負荷量に対する電力性能指標値の一例を示す図表である。 図５は、バッテリ残量に対する消費電力優先指標値の一例を示す図表である。 図６は、携帯端末での実行先決定にかかる処理概要を示すフローチャートである。 図７は、設計フェーズによりＲＯＭに記録される情報を示す図である。 図８は、実行フェーズにおけるメモリに記録される情報を示す図である。 図９は、ＣＰＵが複数の処理を実行する状態を示すタイムチャートである。 図１０は、実行先決定部による実行先決定の処理内容を示すフローチャートである。 図１１は、実行先決定部によるアクセラレータでの処理終了後の処理を示すフローチャートである。 図１２－１は、処理の負荷増加を検出する処理の流れを示すフローチャートである。 図１２－２は、処理の負荷減少を検出する処理の流れを示すフローチャートである。 図１３－１は、負荷が増加した場合の処理要求の流れを示す図である。 図１３－２は、負荷が増加した場合の処理の終了時刻を説明する図である。 図１４－１は、時間経過により負荷が増加した場合の処理要求の流れを示す図である。 図１４－２は、時間経過により負荷が増加した場合の処理の終了時刻を説明する図である。 図１５は、処理の負荷増加時における実行先決定の処理例を示すフローチャートである。 図１６－１は、負荷が減少した場合の処理要求の流れを示す図である。 図１６－２は、負荷が減少した場合の処理の終了時刻を説明する図である。 図１７－１は、時間経過により負荷が減少した場合の処理要求の流れを示す図である。 図１７－２は、時間経過により負荷が減少した場合の処理の終了時刻を説明する図である。 図１８は、処理の負荷減少時における実行先決定の処理例を示すフローチャートである。
　以下に添付図面を参照して、開示技術の好適な実施の形態を詳細に説明する。
（実施の形態）
　開示のシステムは、データ処理の汎用性が高く消費電力が大きいプロセッサ（ＣＰＵ）と、汎用性が低いがＣＰＵよりも特定の処理の処理速度が早く、消費電力が小さいハードウェア・アクセラレータとを備えたシステムである。そして、これらＣＰＵとアクセラレータの処理性能に関する電力性能指標値（第１値）と、システムを駆動するバッテリの消費状態等に関する消費電力優先指標値（第２値）とをあらかじめ求めておくことにより、これからおこなおうとする処理をＣＰＵあるいはアクセラレータのいずれの処理先で実行させるかを選択する。これにより、システムが搭載された機器がたとえばバッテリ駆動される場合において、バッテリ残量の変化に対応した処理先を適切に選択でき、処理効率と低消費電力化を両立させる。以下、システムが、バッテリで動作する携帯端末に搭載された例を用いて説明する。
（システムの構成例）
　図１は、実施の形態にかかるシステムの構成例を示すブロック図である。開示のシステム１００は、ＣＰＵ１０１と、ＣＰＵ１０１を介して利用可能なアクセラレータ（ＡＣＣ）１０２と、メモリ１０３と、ＲＯＭ１０４と、現在時刻を計時するタイマ１０５と、バッテリ管理部１０６と、これらＣＰＵ１０１～バッテリ管理部１０６を接続するバス（ＢＵＳ）１０７とを含む。ＲＯＭ１０４には、ＣＰＵ１０１およびアクセラレータ１０２別の処理時間と消費電力の情報等が記録される。ＣＰＵ１０１は、オペレーティングシステム（ＯＳ）１１０によりアプリケーションの処理の実行を制御する。
　アプリケーションの実行先は、ＯＳ１１０によりＣＰＵ１０１あるいはアクセラレータ１０２が指定される。ＣＰＵ１０１が実行先として決定されたときには、図中Ａの経路でＣＰＵ用実行コードがＣＰＵ１０１に出力される。アクセラレータ１０２が実行先として決定されたときには図中Ｂの経路でＣＰＵ１０１を経由し、アクセラレータ１０２にアクセラレータ用実行コードが出力される。
　図２は、オペレーティングシステムの内部構成例を示すブロック図である。ＯＳ１１０は、実行先決定部１１１と、プロセス管理部１１３と、を含む。実行先決定部１１１は、アプリケーションの処理の実行先をＣＰＵ１０１、あるいはアクセラレータ１０２のいずれかに決定する。プロセス管理部１１３は、アプリケーション実行時のプロセスおよびプロセスのスレッドを管理する。また、稼働スレッド数を実行先決定部１１１の稼働スレッド数取得部１２２に通知し、稼働スレッド数の増減毎に通知する。このプロセス管理部１１３は、ＣＰＵ１０１の処理の負荷を監視する監視ユニットとして機能する。
　より詳細に説明すると、実行先決定部１１１は、処理要求受付部１２１と、稼働スレッド数取得部１２２と、キュー管理部１２３と、ＲＯＭ情報取得部１２４と、処理スレッド管理部１２５と、指標値処理部１２６と、端末状態取得部１２７と、アクセラレータ管理部１２８と、割り付け先決定部（選択ユニット）１２９と、を含む。指標値処理部１２６は、電力性能指標値（第１値）と消費電力優先指標値（第２値）とを算出する指標値算出部（算出ユニット）１２６ａと、電力性能指標値（第１値）と消費電力優先指標値（第２値）とを比較する指標値比較部（比較ユニット）１２６ｂとを含む。
　処理要求受付部１２１は、実行するアプリケーションのスレッドからの処理要求追加、もしくは負荷増減の通知を受け取って実行先決定部１１１による処理を開始させる。稼働スレッド数取得部１２２は、プロセス管理部１１３から現在稼働しているスレッド数を取得する。キュー管理部１２３は、アクセラレータ１０２の実行キューへの処理要求の追加・削除、およびキューイングされている処理要求情報の取得をおこなう。ＲＯＭ情報取得部１２４は、ＲＯＭ１０４に記録された処理時間や消費電力の情報を取得する。処理スレッド管理部１２５は、処理要求をＣＰＵ１０１で実行する場合における処理スレッドの起動、処理割り当て、終了検出、キャンセル、残り処理時間の取得などをおこなう。
　指標値処理部１２６は、アプリケーションの実行先を決定するために必要な指標である電力性能指標値と消費電力優先指標値を算出する。端末状態取得部１２７は、バッテリ管理部１０６からバッテリ残量を取得する。そのほか、携帯端末の使用状態（使用の有無に応じて開閉する蓋の開閉状態、電源への接続状態の有無など）を携帯端末に設けられた検出部（不図示）から取得する。アクセラレータ管理部１２８は、キュー先頭の処理要求のアクセラレータへの割り当て、およびアクセラレータでの処理の終了検出などのアクセラレータでおこなう処理を管理する。割り付け先決定部１２９は、処理要求をＣＰＵ１０１で実行するかアクセラレータ１０２で実行するかを決定する。
（アプリケーションの実行先の決定の概要）
　ここで、実行先決定部１１１によるアプリケーションの実行先をＣＰＵ１０１、あるいはアクセラレータ１０２のいずれに決定するかの概要について説明する。
　図３は、実行先別の終了時刻を説明するための図である。実行先決定部１１１は、アプリケーションの一つの処理（第１処理）をＣＰＵ１０１でおこなった場合の処理の終了時刻と、アクセラレータ１０２でおこなった場合の処理の終了時刻と、をそれぞれ推定する。そして、第１処理をＣＰＵ１０１でおこなった場合の処理時間（第１処理時間）と、第１処理をアクセラレータ１０２でおこなった場合の処理時間（第２処理時間）とをそれぞれ算出する。
　そして、これら第１処理時間と第２処理時間から、第１処理時間と第２処理時間（それぞれの終了時刻）の差を比較する。この際、第１処理時間によって必要なＣＰＵ１０１の処理にかかる消費電力（第１消費電力）と、第２処理時間によって必要なアクセラレータ１０２の処理にかかる消費電力（第２消費電力）の差を求め、この差により電力性能指標値を求める。実行先決定部１１１（割り付け先決定部１２９）は、この電力性能指標値と、端末状態取得部１２７により取得したバッテリ残量等の携帯端末の電力消費に関する消費電力優先指標値により、上記第１処理をＣＰＵ１０１、あるいはアクセラレータ１０２のいずれでおこなうかを選択し、処理の実行先を割り当てる。消費電力優先指標値は、実行先決定のために電力性能指標値と比較するための閾値として用いられる。
　図３にはＣＰＵ１０１とアクセラレータ（ＡＣＣ）１０２でおこなった場合のスレッド単位の処理時間をケース別に図示してある。ケース１では、アクセラレータ１０２には４つのスレッド３０１があり、第４スレッドをＣＰＵ１０１で実行させようとした場合であるが、この第４スレッドをＣＰＵ１０１で実行すると、ＣＰＵ１０１での終了時刻ｔ１は、アクセラレータ１０２で実行した場合の終了時刻ｔ２より遅くなる。この場合、電力性能指標値はマイナスとする。すなわち、全てのスレッドをアクセラレータ１０２で実行した方が早く処理が終わる。
　ケース２では、アクセラレータ１０２には９つのスレッド３０１があり、第９スレッドをＣＰＵ１０１で実行させようとした場合であるが、この第９スレッドをＣＰＵ１０１で実行したときのＣＰＵ１０１での終了時刻ｔ１は、アクセラレータ１０２で実行した場合の終了時刻ｔ２よりやや早い。この場合、電力性能指標値は小とする。すなわち、性能優先であれば、ＣＰＵ１０１を実行先とするが、消費電力を考えるとアクセラレータ１０２で実行した方が良い。
　ケース３では、アクセラレータ１０２には多数（ｎ）のスレッド３０１があり、第ｎスレッドをＣＰＵ１０１で実行させようとした場合であるが、この第ｎスレッドをＣＰＵ１０１で実行したときのＣＰＵ１０１での終了時刻ｔ１は、アクセラレータ１０２で実行した場合の終了時刻ｔ２より早くできる。この場合、電力性能指標値は大とする。そして、性能優先であるか消費電力を優先するかにより実行先を決定する。
　上記のケース１～３は、いずれも閾値（後述する消費電力優先指標値）を０としてプラスの値の大小、あるいは値がマイナスとなる場合を想定している。そして、この閾値を携帯端末の状態、たとえば、現在のバッテリ残量等により変更させる構成としても良い。この点は、後述する消費電力優先指標値において説明する。
　つぎに、上記の電力性能指標値について説明する。電力性能指標値は、指標値処理部１２６が下記演算により求める。
　電力性能指標値＝（アクセラレータでの終了時刻ｔ２－ＣＰＵでの終了時刻ｔ１）／（ＣＰＵでの消費電力量ＰＨ１－アクセラレータでの消費電力量ＰＨ２）
　なお、ＣＰＵ１０１での消費電力量ＰＨ１＝ＣＰＵの消費電力Ｐ１×ＣＰＵでの処理にかかる処理時間Ｔ１であり、アクセラレータ１０２での消費電力量ＰＨ２＝アクセラレータの消費電力Ｐ２×アクセラレータの処理にかかる処理時間Ｔ２である。
　Ｐ１，Ｐ２と、Ｔ１，Ｔ２、あるいはＰＨ１とＰＨ２は、予め後述する設計フェーズの際の測定により、ＲＯＭ１０４に記録しておく固定値である。
　ＣＰＵ１０１の終了時刻ｔ１は、下記の１．２．いずれかにより推定する。
１．ＣＰＵ１０１の終了時刻ｔ１＝開始時刻ｔ０＋割り当て処理の残り時間合計ｔｍ＋処理対象の処理時間Ｔ１
２．ＣＰＵ１０１の終了時刻ｔ１＝開始時刻ｔ０＋処理対象の処理時間Ｔ１／（１－ＣＰＵ１０１の稼働率）
　１．２．のいずれを選択するかは、他の全処理の処理時間が判明しているか否かに基づき選択すればよい。
　図４は、負荷量に対する電力性能指標値の一例を示す図表である。図示の例では、アクセラレータ１０２の負荷量と電力性能指標値とが比例する例を図示した。アクセラレータ１０２の負荷量が増加するほど、電力性能指標値は高くなる。
　アクセラレータ１０２の終了時刻ｔ２は、下記式により推定する。
　アクセラレータ１０２の終了時刻ｔ２＝開始時刻ｔ０＋実行中処理の残り時間ｔｎ１、未実行処理の処理時間合計ｔｎ２＋対象処理の処理時間Ｔ２
　上記の消費電力優先指標値の決定について説明する。指標値処理部１２６は、下記１．～３．のいずれかにより消費電力優先指標値を算出する。バッテリ残量、電源接続状態、携帯端末の開閉状態等は、端末状態取得部１２７から取得する。
１．バッテリ残量のみで消費電力優先指標値を算出。
　消費電力優先指標値ａ＝α／バッテリ残量
　（α：任意の係数）
　この消費電力優先指標値は、携帯端末をバッテリで駆動する場合に用いる。
２．電源接続の有無により算出。
　電源接続中は、消費電力優先指標値ｂ＝０（性能最優先とする）
　バッテリ動作中は、消費電力優先指標値ａ＝α／バッテリ残量
　この場合、携帯端末が電源接続中であるか否かを端末状態取得部１２７により取得し、消費電力優先指標値ａ，ｂを選択する。たとえば、携帯端末を充電するクレードルに置いた電源接続中（バッテリ充電中）であれば、消費電力優先指標値ｂを選択する。携帯端末がクレードルから取り外されバッテリ駆動中であれば、消費電力優先指標値ａを選択する。
３．携帯端末の開閉状態（操作状態）により算出。折りたたみ式の携帯端末の蓋が開閉自在であり、開状態で操作使用するものである場合。
　携帯端末が開状態であれば、消費電力優先指標値ａ＝α／バッテリ残量
　携帯端末が閉状態であれば、消費電力優先指標値ｂ＝β／バッテリ残量
　（α，β：任意の係数、α＜βとする。開状態で性能優先とする）
　上記１．～３．のほかに固定値（上述した値０など）としても良い。なお、固定値や係数の値は、後述する設計フェーズの際に携帯端末の要求稼働時間と要求性能等から決定しておき、電力性能指標値と、閾値である消費電力優先指標値とを比較できる値に整合させておく。このように、端末状態取得部１２７により、バッテリの残量、あるいはバッテリの残量に関わる携帯端末の使用状態を取得し、指標値処理部１２６により消費電力優先指標値を求める。
　図５は、バッテリ残量に対する消費電力優先指標値の一例を示す図表である。図示の例では、バッテリ残量が少ないほど消費電力優先指標値の変化の割合を高くしてある。
（設計フェーズと実行フェーズについて）
　ＲＯＭ１０４には、携帯端末運用前の設計時（設計フェーズ）において必要な情報が記録される。設計フェーズでは、実行先決定部１１１は、アクセラレータ１０２で実行可能な処理をＣＰＵ１０１でおこなった場合と、アクセラレータ１０２でおこなった場合の処理時間と、消費電力を測定してＲＯＭ１０４に記録しておく。
　また、携帯端末運用時の処理実行時（実行フェーズ）には、実行先決定部１１１（指標値処理部１２６）は、ＲＯＭ１０４に記録された情報に基づいて電力性能指標値を算出し、割り付け先決定部１２９は、この電力性能指標値と消費電力優先指標値に基づいて、ＣＰＵ１０１、あるいはアクセラレータ１０２のいずれを実行先とするか決定する。
（実行先決定の処理概要）
　図６は、携帯端末での実行先決定にかかる処理概要を示すフローチャートである。設計フェーズＳ６００の段階では、ＣＰＵ１０１とアクセラレータ１０２の消費電力を測定する（ステップＳ６０１）。また、アクセラレータ１０２に実行させる処理を決定する（ステップＳ６０２）。また、ＣＰＵ１０１とアクセラレータ１０２での処理時間をそれぞれ測定する（ステップＳ６０３）。また、ＣＰＵ１０１用とアクセラレータ１０２用の実行オブジェクトを用意する（ステップＳ６０４）。
　この設計フェーズＳ６００における処理を具体的に説明すると、はじめに、携帯端末で動かすアプリケーション（プログラム）を開発して、アプリケーションでおこなう処理の中からアクセラレータ１０２でおこなう処理を決定する。アクセラレータ１０２でおこなう処理が決定したら、アプリケーションのプログラムからアクセラレータ１０２を利用した処理をおこなうプログラムコードと、アクセラレータ１０２での処理と同内容の処理をＣＰＵ１０１でおこなうプログラムコードを作成しておく。
　この後、実際にこれらのプログラムコードを実行してアクセラレータ１０２で処理した場合と、ＣＰＵ１０１で処理した場合の処理時間を実測定する。同じアクセラレータ１０２に対して異なる使い方をする場合は、使い方毎に処理時間を測定する。また、この処理時間中におけるＣＰＵ１０１とアクセラレータ１０２のそれぞれの消費電力を電力測定器等を利用して測定する。測定した消費電力と、使い方毎の処理時間をＲＯＭ１０４に記録する。また、作成したアプリケーションと、アクセラレータ１０２を利用して処理をおこなうプログラムコードと、アクセラレータ１０２と同じ処理をＣＰＵ１０１でおこなうプログラムコードについてもＲＯＭ１０４に記録しておく。
　図７は、設計フェーズによりＲＯＭに記録される情報を示す図である。ＲＯＭ１０４には、アプリケーションの処理毎の処理要求情報（１～ｎ）７０１と、ＣＰＵ消費電力７２１と、アクセラレータ消費電力７２２とが記録される。たとえば、アプリケーションの処理１の処理要求は、ＣＰＵ処理時間７１１と、アクセラレータ処理時間７１２と、ＣＰＵ用実行コード７１３と、アクセラレータ用実行コード７１４とを含む。
　図６に戻り説明すると、上記設計フェーズＳ６００によりＲＯＭ１０４に情報が記録された後、携帯端末を運用する実行フェーズＳ６１０となる。実行フェーズＳ６１０における処理は、はじめに、アプリケーションから処理の起動をＯＳ１１０に要求する（ステップＳ６１１）。これにより、ＯＳ１１０は、処理の実行先をＣＰＵ１０１あるいはアクセラレータ１０２に決定して割り付け（ステップＳ６１２）、一連の処理を終了する。
　この実行フェーズＳ６１０では、アプリケーション（プログラム）中にアクセラレータ１０２で処理をおこなう場合は、ＯＳ１１０はアクセラレータ１０２へ処理を要求する。ＯＳ１１０ではアクセラレータ１０２が空いていれば、ＲＯＭ１０４に記録されたアクセラレータを利用するプログラムコードを実行してアクセラレータ１０２での処理を開始する。このとき、起動する処理の種別と起動時刻をメモリ１０３に記録しておく。アクセラレータ１０２が利用中の場合は、ＯＳ１１０は、キュー状のデータ構造により、処理要求毎に記録しておく。アクセラレータ１０２での実行が完了すると、ＯＳ１１０は、キューの先頭の処理要求に基づいてアクセラレータ１０２を利用するプログラムコードを実行する。
　図８は、実行フェーズにおけるメモリに記録される情報を示す図である。メモリ１０３には、複数の処理要求がそれぞれ処理要求キュー８０１（８０１ａ～８０１ｎ）に記録され、先頭の処理要求キュー８０１ａから順番に処理される。また、ＣＰＵ１０１に関するＣＰＵ実行中処理情報８１１と、アクセラレータ１０２に関するアクセラレータ実行中処理情報８１２と、がそれぞれ記録される。ＣＰＵ実行中処理情報８１１としては、処理要求、開始時刻等がある。アクセラレータ実行中処理情報８１２としては、処理要求、開始時刻、終了時刻等がある。
　ここで、実際に処理要求を処理要求キュー８０１に追加するか否かはＯＳ１１０内の実行先決定部１１１で決定する。実行先決定部１１１では、電力性能指標値と、消費電力優先指標値から要求された処理を処理要求キュー８０１に追加するかＣＰＵ１０１でおこなうかを決定する。
（ＣＰＵでの複数処理時の処理別の終了時刻について）
　一つのＣＰＵ１０１で複数の処理（スレッド）が動作する場合、ＯＳ１１０の処理スレッド管理部１２５は、数ミリ秒単位で実行するスレッドを切り替えて、一つのＣＰＵ１０１であたかも複数のスレッドが同時に動作しているように見せている。単位時間あたりどのスレッドにどれだけの時間を割り振るかは、全て処理スレッド管理部１２５がそれぞれのスレッドに設定された優先度情報などに基づき決定している。優先度が同じであれば、全てのスレッドは均等に時間が割り振られる。
　図９は、ＣＰＵが複数の処理を実行する状態を示すタイムチャートである。図示の例のように、３つのスレッド１～３が同時に動いていれば、単位時間あたりそれぞれのスレッド１～３が３分の１ずつ実行時間を取得することになる。すなわち、ＣＰＵそれぞれのスレッド１～３を処理開始してから処理終了するまでの時間は３倍かかることになる。また、ＯＳ１１０の処理スレッド管理部１２５は、現在どれだけのスレッドが処理されているか、およびスレッドがこれまでにどれだけの時間実行処理したかについて全て管理している。
　したがって、図９に示すように、ＣＰＵ１０１で複数の処理（スレッド）が動作している状況であっても、処理スレッド管理部１２５が管理するスレッド毎の実行時間と、稼働スレッド数取得部１２２が取得した稼働スレッド数から、指標値処理部１２６は、各スレッドの終了時刻ｔ１を算出することができる。
（実行先決定の処理内容）
　図１０は、実行先決定部による実行先決定の処理内容を示すフローチャートである。図１０を用いて、ＯＳ１１０の実行先決定部１１１による処理を説明する。
　実行先決定部１１１の処理要求受付部１２１は、アプリケーションからの処理要求を受け付ける毎に（ステップＳ１００１）、処理要求毎に処理の実行先を決定するために以下の処理をおこなう。はじめに、ＲＯＭ情報取得部１２４により、ＲＯＭ１０４から処理要求に対応する処理についてのＣＰＵ１０１とアクセラレータ１０２での処理時間Ｔ１，Ｔ２を取得する（ステップＳ１００２）。また、ＲＯＭ情報取得部１２４により、ＲＯＭ１０４からＣＰＵ１０１とアクセラレータ１０２の消費電力Ｐ１，Ｐ２を取得する（ステップＳ１００３）。また、実行先決定部１１１は、現在時刻を取得する（ステップＳ１００４）。
　つぎに、アクセラレータ管理部１２８により、アクセラレータ１０２でおこなっている処理の処理要求と開始時刻を取得する（ステップＳ１００５）。つぎに、稼働スレッド数取得部１２２から稼働しているスレッド数を取得する（ステップＳ１００６）。これにより、実行先決定部１１１の指標値処理部１２６は、処理（スレッド）についてのＣＰＵ１０１の終了時刻ｔ１と、アクセラレータ１０２の終了時刻ｔ２と、をそれぞれ算出し、また、電力性能指標値を算出する（ステップＳ１００７）。この電力性能指標値は、上述したように、要求された処理をＣＰＵ１０１でおこなった場合の終了時刻ｔ１と、アクセラレータ１０２でおこなった場合の終了時刻ｔ２と、これらＣＰＵ１０１およびアクセラレータ１０２のそれぞれでおこなった場合の推定消費電力量ＰＨ１，ＰＨ２に基づき算出する。
　この際、ＣＰＵ１０１でおこなった場合の処理対象の処理時間Ｔ１は、設計フェーズＳ６００で測定してＲＯＭ１０４に記録してあるため、該当する処理に対応する処理時間をＲＯＭ１０４から取得する。一方、アクセラレータ１０２でおこなった場合の終了時刻ｔ２は、上述したように、アクセラレータ１０２で現在おこなっている実行中処理の残り時間ｔｎ１と、処理要求キュー８０１にたまっている未実行処理の処理時間合計ｔｎ２と、該当する処理をアクセラレータ１０２でおこなった場合の処理時間Ｔ２と開始時刻ｔ０を加算したものとなる。
　このように、ＣＰＵ１０１およびアクセラレータ１０２のそれぞれの処理の処理時間Ｔ１，Ｔ２は、設計フェーズで測定してＲＯＭ１０４に記録されているため、それぞれの処理要求に対応する処理時間Ｔ１，Ｔ２をＲＯＭ１０４から取得する。消費電力量ＰＨ１，ＰＨ２についても、ＲＯＭ１０４から読み出して用いる。また、指標値処理部１２６は、携帯端末の状態から消費電力優先指標値を算出する（ステップＳ１００８）。
　消費電力優先指標値は、算出するに限らず、固定値（たとえば０）を用いることもできる。値が０であれば、電力性能指標値だけに基づき処理の実行先を決定することになる。この消費電力優先指標値は、電力性能指標値の値を判断するための閾値として用いるため、消費電力優先指標値と電力性能指標値を単純に比較するだけで処理の実行先を決定できる。
　つぎに、実行先決定部１１１の割り付け先決定部１２９は、電力性能指標値と消費電力優先指標値を比較する（ステップＳ１００９）。消費電力優先指標値に対し電力性能指標値が大きければ（ステップＳ１００９：Ｙｅｓ）、アプリケーションからの処理要求をＣＰＵ１０１でおこなうことを決定する。また、消費電力優先指標値に対し電力性能指標値が小さければ（ステップＳ１００９：Ｎｏ）、アプリケーションからの処理要求をアクセラレータ１０２で処理することを決定する。
　処理の実行をＣＰＵ１０１に決定した場合は（ステップＳ１００９：Ｙｅｓ）、ＯＳ１１０のプロセス管理部１１３は、ＲＯＭ１０４に記録されている対象処理の処理要求に対応するＣＰＵ用実行コード（プログラムコード）７１３を取得し（ステップＳ１０１０）、新規プロセスを生成して取得した実行コードをそのプロセスで実行させる（ステップＳ１０１１）。そして、プロセス管理部１１３は、ＣＰＵ１０１で実行した処理要求と、現在時刻と、算出した終了時刻をメモリ１０３のＣＰＵ実行中処理情報８１１に記録し（ステップＳ１０１２）、一つの処理を終了する。
　一方、処理の実行をアクセラレータ１０２に決定した場合は（ステップＳ１００９：Ｎｏ）、プロセス管理部１１３は、アクセラレータ管理部１２８からアクセラレータ１０２の稼働状況を取得し（ステップＳ１０１３）、アクセラレータ１０２が稼働中であるか否かを判断する（ステップＳ１０１４）。アクセラレータ１０２が稼働中であれば（ステップＳ１０１４：Ｙｅｓ）、最後の処理要求キュー８０１ｎに処理要求を追加し（ステップＳ１０１５）、アクセラレータ１０２での処理をおこなわせ、一つの処理を終了する。
　ステップＳ１０１４の判断にてアクセラレータ１０２が稼働中でなければ（ステップＳ１０１４：Ｎｏ）、プロセス管理部１１３は、ＲＯＭ１０４から処理要求に対応するアクセラレータ用実行コード７１４を取得する（ステップＳ１０１６）。つぎに、プロセス管理部１１３は、取得したアクセラレータ用実行コード７１４を実行してアクセラレータ１０２を起動させる（ステップＳ１０１７）。そして、プロセス管理部１１３は、アクセラレータ１０２で実行した処理要求と、開始時刻をメモリ１０３のアクセラレータ実行中処理情報８１２に記録し（ステップＳ１０１８）、一つの処理を終了する。
　図１１は、実行先決定部によるアクセラレータでの処理終了後の処理を示すフローチャートである。実行先決定部１１１のアクセラレータ管理部１２８によりアクセラレータ１０２での処理終了を検出すると（ステップＳ１１０１）、プロセス管理部１１３は、先頭の処理要求キュー８０１ａから処理要求を取得し（ステップＳ１１０２）、取得が成功したか確認する（ステップＳ１１０３）。取得が成功すれば（ステップＳ１１０３：Ｙｅｓ）、処理を終了する。
　ステップＳ１１０３にて、先頭の処理要求キュー８０１ａからの処理要求が取得できなかったときには（ステップＳ１１０３：Ｎｏ）、プロセス管理部１１３は、ＲＯＭ１０４から処理要求に対応するアクセラレータ用実行コード７１４を取得する（ステップＳ１１０４）。つぎに、プロセス管理部１１３は、取得したアクセラレータ用実行コード７１４を実行してアクセラレータ１０２を起動させる（ステップＳ１１０５）。そして、プロセス管理部１１３は、アクセラレータ１０２で実行した処理要求と、開始時刻をメモリ１０３のアクセラレータ実行中処理情報８１２に記録し（ステップＳ１１０６）、一つの処理を終了する。
（処理の負荷変動時の処理について）
　つぎに、処理の負荷変動時における処理の実行先の決定について説明する。負荷の増加は、たとえば、すでに起動しているアプリケーションとは別のアプリケーションの起動や、ＣＰＵ１０１の負荷の監視時に設定以上のスレッド数（負荷）の増加となったときに負荷の増加であると判断する。一方、負荷の減少は、たとえば、すでに起動しているアプリケーションとは別のアプリケーションの終了や、ＣＰＵ１０１の負荷の監視時に設定以上のスレッド数（負荷）の減少となったときに負荷の減少であると判断する。
　図１２－１は、処理の負荷増加を検出する処理の流れを示すフローチャートである。処理の負荷増加時には、アプリケーションから新規スレッドの生成要求またはスレッド起動要求が出力される（ステップＳ１２０１）。これにより、プロセス管理部１１３は、スレッドを生成またはスレッドを起動させ（ステップＳ１２０２）、稼働スレッド数の増加を実行先決定部１１１に通知する（ステップＳ１２０３）。実行先決定部１１１は、通知された稼働数スレッドの増加に基づき、負荷増加時における実行先決定の処理をおこなう（ステップＳ１２０４）。
　図１２－２は、処理の負荷減少を検出する処理の流れを示すフローチャートである。処理の負荷減少時には、アプリケーションからスレッド終了通知またはスレッド停止要求が出力される（ステップＳ１２１１）。これにより、プロセス管理部１１３は、スレッドを削除またはスレッドを停止させ（ステップＳ１２１２）、稼働スレッド数の減少を実行先決定部１１１に通知する（ステップＳ１２１３）。実行先決定部１１１は、通知された稼働数スレッドの減少に基づき、負荷減少時における実行先決定の処理をおこなう（ステップＳ１２１４）。
　上記のように、処理の負荷の増加および減少は、アプリケーションからスレッドの追加、終了、停止、起動等の要求によりプロセス管理部１１３で稼働するスレッド数を変更したことを検出する。
　そして、実行先決定部１１１は、新たな処理をＣＰＵ１０１で実行するのに比してアクセラレータ１０２で実行した方が良い場合には、ＣＰＵ１０１での処理をキャンセルし、アクセラレータ１０２でこの処理を実行する。逆に、ＣＰＵ１０１での処理に空きができ、アクセラレータ１０２よりもＣＰＵ１０１で実行した方が良い場合には、アクセラレータ１０２の処理をＣＰＵ１０１で実行する。具体的には、ＣＰＵ１０１とアクセラレータ１０２のいずれで処理を実行した方が全体の処理の終了時刻を早めることができるか、により決定する。
（処理の負荷増加時の処理について）
　つぎに、処理の負荷増加時に、処理対象の割り当てが変化する状態を説明する。図１３－１は、負荷が増加した場合の処理要求の流れを示す図、図１３－２は、負荷が増加した場合の処理の終了時刻を説明する図である。時刻ｔ１でスレッドが処理要求をおこなったとき、実行先決定部１１１では、要求された処理をＣＰＵ１０１で実行した場合と、アクセラレータ１０２で実行した場合の終了時刻をそれぞれ推定し算出する。
　ＣＰＵ１０１で実行した場合には終了時刻ｔ２であると算出されたとする。一方で、アクセラレータ１０２で実行した場合は、すでに多数の処理要求１３０１がキューイングされているため、処理を開始できるのは時刻ｔ３となり、終了時刻ｔ４となる。指標値処理部１２６は、これら終了時刻ｔ２，ｔ４を用いて電力性能指標値を算出する。そして、割り付け先決定部１２９は、ＣＰＵ１０１で処理をした方が効率が良いと判断して、ＣＰＵ１０１の処理要求に対しスレッドＳ１を起動して、ＣＰＵ１０１で処理をおこなう。
　つぎに、上記処理後の時間経過による負荷の変動時について説明する。図１４－１は、時間経過により負荷が増加した場合の処理要求の流れを示す図、図１４－２は、時間経過により負荷が増加した場合の処理の終了時刻を説明する図である。
　図１３－１、図１３－２を用いて説明した処理時から、一定時間経過した図１４－２の時刻ｔ１’（ｔ１＜ｔ１’＜ｔ２）で新しくスレッドＳ２が起動されたとする。これにより、ＣＰＵ１０１の負荷が上がるため、実行先決定部１１１は、負荷増加の処理を実行する。この負荷増加の処理では、時刻ｔ１’を基準として、処理をＣＰＵ１０１で実行した場合と、アクセラレータ１０２で実行した場合のそれぞれの終了時刻ｔ２’，ｔ４’を再計算する。
　アクセラレータ１０２側では、時刻ｔ３からｔ３’の間でいくつかの処理要求１４０２が処理要求キュー８０１に追加されている。これにより、時刻ｔ１’の時点からアクセラレータ１０２に処理を追加した場合は、再計算の結果、アクセラレータ１０２で処理が開始できるのが時刻ｔ３’となり終了時刻は時刻ｔ４’に変更になったとする。
　一方で、ＣＰＵ１０１で実行した場合は、すでにｔ１からｔ１’の間で処理が進んでいるが、時刻ｔ１’で新しくスレッドＳ２（１４０１）が追加されたことにより、ＣＰＵ１０１の負荷が上昇するため、時刻ｔ１’の時点でまだ処理が済んでいない部分に対して、現在のＣＰＵ１０１の負荷から終了時刻を再計算の結果、終了時刻ｔ２’に変更になったとする。これにより、割り付け先決定部１２９は、今からでもアクセラレータ１０２で処理をおこなった方が効率が良いと判断して、ＣＰＵ１０１のスレッドＳ２の処理をキャンセルし、処理要求キュー８０１に処理要求Ｓ３を追加する。
（処理の負荷増加時の実行先決定処理について）
　図１５は、処理の負荷増加時における実行先決定の処理例を示すフローチャートである。実行先決定部１１１がおこなう処理を以下に説明する。プロセス管理部１１３が処理の負荷増加を検出すると（ステップＳ１５０１）、実行先決定部１１１の処理要求受付部１２１は、ＲＯＭ情報取得部１２４により、ＲＯＭ１０４からＣＰＵ１０１で実行している処理要求を取得する（ステップＳ１５０２）。そして、処理要求が取得できたか判断する（ステップＳ１５０３）。処理要求が取得できなければ（ステップＳ１５０３：Ｎｏ）、処理を終了し、処理要求が取得できれば（ステップＳ１５０３：Ｙｅｓ）、つぎに、メモリ１０３からＣＰＵ１０１で実行している処理の開始時刻と、終了時刻を取得する（ステップＳ１５０４）。
　また、ＲＯＭ情報取得部１２４により、ＲＯＭ１０４から、処理要求に対応する処理のＣＰＵ１０１と、アクセラレータ１０２での処理時間を取得する（ステップＳ１５０５）。また、ＲＯＭ１０４からＣＰＵ１０１と、アクセラレータ１０２の消費電力を取得する（ステップＳ１５０６）。また、実行先決定部１１１は、現在時刻を取得する（ステップＳ１５０７）。
　つぎに、アクセラレータ管理部１２８により、アクセラレータ１０２でおこなっている処理の処理要求と開始時刻を取得する（ステップＳ１５０８）。つぎに、稼働スレッド数取得部１２２から稼働しているスレッド数を取得する（ステップＳ１５０９）。これにより、実行先決定部１１１の指標値処理部１２６は、処理（スレッド）についてのＣＰＵ１０１の新たな終了時刻（図１４－２の例では終了時刻ｔ２’）と、アクセラレータ１０２の新たな終了時刻（図１４－２の例では、終了時刻ｔ４’）と、をそれぞれ算出し、また、電力性能指標値を算出する（ステップＳ１５１０）。また、指標値処理部１２６は、携帯端末の状態から消費電力優先指標値を算出する（ステップＳ１５１１）。
　つぎに、実行先決定部１１１の割り付け先決定部１２９は、電力性能指標値と消費電力優先指標値を比較する（ステップＳ１５１２）。消費電力優先指標値に対し電力性能指標値が大きければ（ステップＳ１５１２：Ｙｅｓ）、アプリケーションからの処理要求をＣＰＵ１０１でおこなうことを決定する。そして、終了時刻を算出した新たな終了時刻に更新し、ＣＰＵ実行中処理情報８１１を更新し（ステップＳ１５１３）、処理を終了する。
　また、消費電力優先指標値に対し電力性能指標値が小さければ（ステップＳ１５１２：Ｎｏ）、アプリケーションからの処理要求をアクセラレータ１０２で処理することを決定する。そして、プロセス管理部１１３は、ＣＰＵ１０１で処理をおこなっているプロセスの実行をキャンセルし（ステップＳ１５１４）、アクセラレータ管理部１２８からアクセラレータ１０２の稼働状況を取得する（ステップＳ１５１５）。この後、アクセラレータ１０２が稼働中であるか否かを判断する（ステップＳ１５１６）。アクセラレータ１０２が稼働中であれば（ステップＳ１５１６：Ｙｅｓ）、最後の処理要求キュー８０１ｎに処理要求を追加し（ステップＳ１５１７）、アクセラレータ１０２での処理をおこなわせ、一つの処理を終了する。
　一方、アクセラレータ１０２が稼働中でなければ（ステップＳ１５１６：Ｎｏ）、プロセス管理部１１３は、ＲＯＭ１０４から処理要求に対応するアクセラレータ用実行コード７１４を取得する（ステップＳ１５１８）。つぎに、プロセス管理部１１３は、取得したアクセラレータ用実行コード７１４を実行してアクセラレータ１０２を起動させる（ステップＳ１５１９）。そして、プロセス管理部１１３は、アクセラレータ１０２で実行した処理要求と、開始時刻をメモリ１０３のアクセラレータ実行中処理情報８１２に記録し（ステップＳ１５２０）、一つの処理を終了する。
（処理の負荷減少時の処理について）
　つぎに、処理の負荷減少時に、処理対象の割り当てが変化する状態を説明する。図１６－１は、負荷が減少した場合の処理要求の流れを示す図、図１６－２は、負荷が減少した場合の処理の終了時刻を説明する図である。時刻ｔ１でスレッドが処理要求をおこなったとき、実行先決定部１１１では、要求された処理をＣＰＵ１０１で実行した場合と、アクセラレータ１０２で実行した場合の終了時刻をそれぞれ推定し算出する。
　ＣＰＵ１０１で実行した場合には多くのスレッドの処理があるため、終了時刻ｔ２になると算出されたとする。一方で、アクセラレータ１０２では、先にキューイングされている処理要求１６０１の数が少なく終了時刻ｔ４になるとする。指標値処理部１２６は、これら終了時刻ｔ２，ｔ４を用いて電力性能指標値を算出する。そして、割り付け先決定部１２９は、アクセラレータ１０２で処理をした方が効率が良いと判断して、処理要求Ｓ１１を処理要求キュー８０１に追加する。
　つぎに、上記処理後の時間経過による負荷の変動時について説明する。図１７－１は、時間経過により負荷が減少した場合の処理要求の流れを示す図、図１７－２は、時間経過により負荷が減少した場合の処理の終了時刻を説明する図である。
　図１６－１、図１６－２を用いて説明した処理時から、一定時間経過した図１７－２の時刻ｔ１’で今度はＣＰＵ１０１のスレッドの処理が終了したとすると、ＣＰＵ１０１の負荷が減少するため、上述した負荷増加時と同じように、実行先決定部１１１は、終了時刻の再計算をおこなう。図１６－１および図１６－２の例では、時刻ｔ１でアクセラレータ１０２で処理を実行することが決定され、処理要求がキューイングされているため、アクセラレータ１０２での開始時刻ｔ３と終了時刻ｔ４は変化しないままとなる。
　一方、ＣＰＵ１０１で実行する場合は、ＣＰＵ１０１での処理の負荷が減少しているため終了時刻はｔ２’に変更になる。ここで、指標値処理部１２６により電力優先指標値を再計算した結果、ＣＰＵ１０１で処理を実行した方が効率が良いと判断した場合は、最後の処理要求キュー８０１ｎから処理要求Ｓ１２を取り出し（削除し）てスレッドで実行する。
（処理の負荷減少時の実行先決定処理について）
　図１８は、処理の負荷減少時における実行先決定の処理例を示すフローチャートである。実行先決定部１１１がおこなう処理を以下に説明する。プロセス管理部１１３が処理の負荷減少を検出すると（ステップＳ１８０１）、実行先決定部１１１のキュー管理部１２３は、メモリ１０３の最後の処理要求キュー８０１ｎから処理要求を取得する（ステップＳ１８０２）。そして、処理要求が取得できたか判断する（ステップＳ１８０３）。処理要求が取得できなければ（ステップＳ１８０３：Ｎｏ）、処理を終了し、処理要求が取得できれば（ステップＳ１８０３：Ｙｅｓ）、つぎに、ＲＯＭ１０４から処理要求に対応する処理のＣＰＵ１０１と、アクセラレータ１０２での処理時間を取得する（ステップＳ１８０４）。また、ＲＯＭ１０４からＣＰＵ１０１と、アクセラレータ１０２の消費電力を取得する（ステップＳ１８０５）。また、実行先決定部１１１は、現在時刻を取得する（ステップＳ１８０６）。
　つぎに、アクセラレータ管理部１２８により、アクセラレータ１０２でおこなっている処理の処理要求と開始時刻を取得する（ステップＳ１８０７）。つぎに、稼働スレッド数取得部１２２から稼働しているスレッド数を取得する（ステップＳ１８０８）。これにより、実行先決定部１１１の指標値処理部１２６は、処理（スレッド）についてのＣＰＵ１０１の新たな終了時刻（図１７－２の例では終了時刻ｔ２’）と、アクセラレータ１０２の新たな終了時刻（図１７－２の例では、終了時刻ｔ４）と、をそれぞれ算出し、また、電力性能指標値を算出する（ステップＳ１８０９）。また、指標値処理部１２６は、携帯端末の状態から消費電力優先指標値を算出する（ステップＳ１８１０）。
　つぎに、実行先決定部１１１の割り付け先決定部１２９は、電力性能指標値と消費電力優先指標値を比較する（ステップＳ１８１１）。消費電力優先指標値に対し電力性能指標値が大きければ（ステップＳ１８１１：Ｙｅｓ）、アプリケーションからの処理要求をＣＰＵ１０１でおこなうことを決定する。そして、対象の処理を処理要求キュー８０１から削除し（ステップＳ１８１２）、ＲＯＭ１０４からＣＰＵ用実行コード７１３を取得する（ステップＳ１８１３）。
　そして、プロセス管理部１１３は、処理に対応する新規プロセスを生成して取得したＣＰＵ用実行コード７１３を実行するよう設定する（ステップＳ１８１４）。そして、ＣＰＵ実行中処理情報８１１におけるＣＰＵ１０１で実行した処理要求と、開始時刻と、算出した終了時刻を記録し（ステップＳ１８１５）、処理を終了する。
　また、消費電力優先指標値に対し電力性能指標値が小さければ（ステップＳ１８１１：Ｎｏ）、処理要求キュー８０１の一つ前の処理要求を取得し（ステップＳ１８１６）、ステップＳ１８０３に戻り、この処理要求に対する上記処理を実行する。
　上述したように、処理の負荷変動により、ＣＰＵ１０１で処理できる場合は、アクセラレータ１０２でおこなうために処理要求キュー８０１に積んでいた処理がＣＰＵ１０１でできないか再検討をおこなっている。この際、最後の処理要求キュー８０１ｎの処理から順番にＣＰＵ１０１で稼働しているスレッド数（空き率を用いても良い）に基づいて、新たに処理を要求したときと同様の処理で判断を繰り返す。そして、ＣＰＵ１０１で処理することになった場合には、処理要求キュー８０１から取り出してＣＰＵ１０１で実行する。
　以上説明した開示技術では、処理をアクセラレータとプロセッサで実行した場合にいずれでおこなった方が早く処理が終了するか処理の実行先を決定しているので、複数の処理ごとの処理効率を向上させることができる。さらに、処理をアクセラレータとプロセッサで実行した場合のそれぞれの消費電力を求め、この消費電力を含め電力性能指標値として用い、処理の実行先を判断するため、処理効率だけではなく、消費電力を含めて効率的な実行先を決定できるようになる。
　さらに、携帯端末の現在の状態、たとえば、バッテリの残量等から決定される消費電力優先指標値を用い、上記の電力性能指標値とともに実行先を決定している。これにより、経時的に変化する携帯端末のバッテリ残量に対応し、現在のバッテリ残量に対応した処理の実行先を決定することができる。このため、処理効率だけではなく、処理実行にかかる消費電力とのバランスが取れた最適な実行先を処理ごとに決定でき、システム全体の処理効率と低消費電力化を両立できるようになる。
　１００　システム
　１０２　アクセラレータ
　１０３　メモリ
　１０６　バッテリ管理部
　１１１　実行先決定部
　１１３　プロセス管理部
　１２１　処理要求受付部
　１２２　稼働スレッド数取得部
　１２３　キュー管理部
　１２４　ＲＯＭ情報取得部
　１２５　処理スレッド管理部
　１２６　指標値処理部
　１２６ａ　指標値算出部
　１２６ｂ　指標値比較部
　１２７　端末状態取得部
　１２８　アクセラレータ管理部
　１２９　割り付け先決定部
　８０１　処理要求キュー
　８１１　ＣＰＵ実行中処理情報
　８１２　アクセラレータ実行中処理情報

Claims (13)

  1. 　ＣＰＵと、
    　アクセラレータと、
    　前記ＣＰＵが第１処理を完了するまでの第１処理時間と前記アクセラレータが前記第１処理を完了するまでの第２処理時間とに基づく第１値と、前記ＣＰＵおよび前記アクセラレータを駆動するバッテリの使用状態に基づく第２値とを比較する比較ユニットと、
    　前記比較ユニットの比較結果に基づいて、前記ＣＰＵまたは前記アクセラレータのいずれかを選択する選択ユニットと、
    　を含むことを特徴とするシステム。
  2. 　前記第１処理時間、前記第２処理時間、前記第１値、および前記第２値を算出する算出ユニットを含むこと
    　を特徴とする請求項１に記載のシステム。
  3. 　前記第１値は、前記第１処理時間と、前記ＣＰＵが前記第１処理を完了する第１終了時刻と、前記ＣＰＵが前記第１処理を実行するときの第１消費電力と、前記第２処理時間と、前記アクセラレータが前記第１処理を完了する第２終了時刻と、前記アクセラレータが前記第１処理を実行するときの第２消費電力とに基づいて、算出されること
    　を特徴とする請求項１または２に記載のシステム。
  4. 　前記第１処理時間と前記第２処理時間とを記録するメモリを含むこと
    　を特徴とする請求項１～３のいずれか一つに記載のシステム。
  5. 　前記選択ユニットは、
    　前記第１値が第２値よりも大きいときに前記ＣＰＵを選択し、
    　前記第１値が前記第２値よりも小さいときに前記アクセラレータを選択すること
    　を特徴とする請求項１～４のいずれか一つに記載のシステム。
  6. 　前記ＣＰＵの負荷を監視する監視ユニットを含み、
    　前記監視ユニットは、前記負荷に変動があるときは、前記選択ユニットに対し、前記ＣＰＵおよび前記アクセラレータの選択の見直しを指示すること
    　を特徴とする請求項１～５のいずれか一つに記載のシステム。
  7. 　前記監視ユニットが前記負荷の増加を検出したとき、
    　前記選択ユニットは、前記第１値が前記第２値よりも小さければ前記ＣＰＵが実行する前記第１処理をキャンセルさせること
    　を特徴とする請求項６に記載のシステム。
  8. 　前記バッテリの使用状態を取得する取得部を備え、
    　当該取得部は、前記バッテリの残量、および当該バッテリ残量に関わる機器の使用状態を取得し、前記比較ユニットに前記第２値の算出用の情報として出力する
    　ことを特徴とする請求項１～７のいずれか一つに記載のシステム。
  9. 　ＣＰＵとアクセラレータを備え、バッテリ駆動されるシステムにおけるスケジューリング方法であって、
    　前記ＣＰＵが第１処理を完了するまでの第１処理時間と、前記アクセラレータが前記第１処理を完了するまでの第２処理時間とをメモリから読み出し、
    　前記第１処理時間と前記第２処理時間とに基づいて第１値を計算し、
    　前記バッテリ残量に基づいて第２値を計算し、
    　前記第１値と前記第２値を比較し、
    　比較結果に基づいて、前記ＣＰＵまたは前記アクセラレータのいずれかを選択し、
    　選択された前記ＣＰＵまたは前記アクセラレータに前記第１処理を割り当てること
    　を特徴とするスケジューリング方法。
  10. 　前記第１処理の処理要求に基づいて当該第１処理の開始時刻を取得し、
    　前記第１処理の開始時刻に基づいて、前記ＣＰＵが前記第１処理を完了する第１終了時刻と前記アクセラレータが前記第１処理を完了する第２終了時刻と算出し、
    　前記第１終了時刻と前記第２終了時刻とに基づいて前記第１値を計算すること
    　を特徴とする請求項９に記載のスケジューリング方法。
  11. 　前記ＣＰＵが前記第１処理を実行するときの第１消費電力と前記アクセラレータが前記第１処理を実行するときの第２消費電力とを前記メモリから読み出し、
    　前記第１消費電力と前記第２消費電力とに基づいて前記第１値を算出すること
    　を特徴とする請求項９または１０に記載のスケジューリング方法。
  12. 　前記第１値が第２値よりも大きいときに前記ＣＰＵを選択し、
    　前記第１値が前記第２値よりも小さいときに前記アクセラレータを選択すること
    　を特徴とする請求項９～１１のいずれか一つに記載のスケジューリング方法。
  13. 　前記ＣＰＵの負荷を監視し、
    　前記負荷に変動があるときは、前記第１処理の開始時刻を取得して、前記ＣＰＵが第１処理を完了する新たな第１終了時刻と前記アクセラレータが前記第１処理を完了する新たな第２終了時刻と算出し、
    　前記新たな第１終了時刻と前記新たな第２終了時刻に基づいて前記第１値を計算すること
    　を特徴とする請求項９～１２のいずれか一つに記載のスケジューリング方法。
PCT/JP2011/056468 2011-03-17 2011-03-17 システムおよびスケジューリング方法 WO2012124125A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/JP2011/056468 WO2012124125A1 (ja) 2011-03-17 2011-03-17 システムおよびスケジューリング方法
JP2013504498A JP5772948B2 (ja) 2011-03-17 2011-03-17 システムおよびスケジューリング方法
US14/027,712 US9672076B2 (en) 2011-03-17 2013-09-16 Scheduling process on a processor or an accelerator on a system driven by battery based on processing efficiency and power consumption

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2011/056468 WO2012124125A1 (ja) 2011-03-17 2011-03-17 システムおよびスケジューリング方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/027,712 Continuation US9672076B2 (en) 2011-03-17 2013-09-16 Scheduling process on a processor or an accelerator on a system driven by battery based on processing efficiency and power consumption

Publications (1)

Publication Number Publication Date
WO2012124125A1 true WO2012124125A1 (ja) 2012-09-20

Family

ID=46830251

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/056468 WO2012124125A1 (ja) 2011-03-17 2011-03-17 システムおよびスケジューリング方法

Country Status (3)

Country Link
US (1) US9672076B2 (ja)
JP (1) JP5772948B2 (ja)
WO (1) WO2012124125A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013050953A (ja) * 2011-08-30 2013-03-14 Samsung Electronics Co Ltd システムオンチップ及びその動作方法並びに携帯用装置
CN105408878A (zh) * 2013-07-31 2016-03-16 惠普发展公司，有限责任合伙企业 具有存储器级并行支持的索引加速器
WO2017135219A1 (ja) * 2016-02-01 2017-08-10 日本電気株式会社 設計支援装置、設計支援方法、および設計支援プログラムを格納した記録媒体
WO2017168483A1 (ja) * 2016-03-28 2017-10-05 株式会社日立製作所 計算機及びデータベースの処理方法
WO2022137838A1 (ja) * 2020-12-25 2022-06-30 日本電気株式会社 プロセス割当制御装置、プロセス割当制御方法、及び、プロセス割当制御プログラムが格納された記録媒体

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6083290B2 (ja) * 2013-03-27 2017-02-22 日本電気株式会社 分散処理システム
KR102402584B1 (ko) * 2015-08-26 2022-05-27 삼성전자주식회사 사용자 어플리케이션의 특성에 따른 연산 디바이스 동적 제어 기법
KR102396309B1 (ko) * 2015-11-06 2022-05-10 삼성전자주식회사 데이터 요청을 제어하기 위한 장치 및 방법
EP3676704A4 (en) * 2017-12-26 2020-09-30 Samsung Electronics Co., Ltd. METHOD AND SYSTEM FOR PREDICTING OPTIMUM NUMBER OF WIRES FOR AN APPLICATION PERFORMING ON AN ELECTRONIC DEVICE

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001095099A1 (fr) * 2000-06-06 2001-12-13 Tadahiro Ohmi Systeme et procede de gestion de circuits de traitement d'informations a fonction variable
JP2011013796A (ja) * 2009-06-30 2011-01-20 Toshiba Corp 情報処理装置

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4345225B2 (ja) * 2000-11-27 2009-10-14 沖電気工業株式会社 エコーキャンセラ
JP4090908B2 (ja) * 2003-02-21 2008-05-28 シャープ株式会社 画像処理装置および画像形成装置
JP2006302168A (ja) 2005-04-25 2006-11-02 Hitachi Ltd コプロセッサ、および、その演算制御方法
US8284205B2 (en) * 2007-10-24 2012-10-09 Apple Inc. Methods and apparatuses for load balancing between multiple processing units
JP2010072731A (ja) 2008-09-16 2010-04-02 Toshiba Corp データ処理装置、方法及びプログラム
US8423799B2 (en) * 2009-11-30 2013-04-16 International Business Machines Corporation Managing accelerators of a computing environment
US8776066B2 (en) * 2009-11-30 2014-07-08 International Business Machines Corporation Managing task execution on accelerators
US8869160B2 (en) * 2009-12-24 2014-10-21 International Business Machines Corporation Goal oriented performance management of workload utilizing accelerators
JP2011242825A (ja) * 2010-05-14 2011-12-01 Fujitsu Ltd 消費電力情報算出プログラム、消費電力情報算出方法、及び消費電力情報算出装置
US8874943B2 (en) * 2010-05-20 2014-10-28 Nec Laboratories America, Inc. Energy efficient heterogeneous systems
US8839256B2 (en) * 2010-06-09 2014-09-16 International Business Machines Corporation Utilization of special purpose accelerators using general purpose processors
US20120163279A1 (en) * 2010-07-07 2012-06-28 Xuan Mai Tran Communication apparatus, communication terminal apparatus, communication system, and communication method
US8739171B2 (en) * 2010-08-31 2014-05-27 International Business Machines Corporation High-throughput-computing in a hybrid computing environment
US9448846B2 (en) * 2011-12-13 2016-09-20 International Business Machines Corporation Dynamically configurable hardware queues for dispatching jobs to a plurality of hardware acceleration engines
JP5834939B2 (ja) * 2012-01-17 2015-12-24 富士通株式会社 プログラム、仮想マシン制御方法、情報処理装置および情報処理システム
US9996394B2 (en) * 2012-03-01 2018-06-12 Microsoft Technology Licensing, Llc Scheduling accelerator tasks on accelerators using graphs

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001095099A1 (fr) * 2000-06-06 2001-12-13 Tadahiro Ohmi Systeme et procede de gestion de circuits de traitement d'informations a fonction variable
JP2011013796A (ja) * 2009-06-30 2011-01-20 Toshiba Corp 情報処理装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
TOMOAKI HAMANO ET AL.: "Power-Saving Task Scheduling on Heterogeneous Environment", IEICE TECHNICAL REPORT, vol. 108, no. 180, 29 July 2008 (2008-07-29), pages 97 - 102 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013050953A (ja) * 2011-08-30 2013-03-14 Samsung Electronics Co Ltd システムオンチップ及びその動作方法並びに携帯用装置
CN105408878A (zh) * 2013-07-31 2016-03-16 惠普发展公司，有限责任合伙企业 具有存储器级并行支持的索引加速器
WO2017135219A1 (ja) * 2016-02-01 2017-08-10 日本電気株式会社 設計支援装置、設計支援方法、および設計支援プログラムを格納した記録媒体
JPWO2017135219A1 (ja) * 2016-02-01 2018-11-29 日本電気株式会社 設計支援装置、設計支援方法、および設計支援プログラム
US10909021B2 (en) 2016-02-01 2021-02-02 Nec Corporation Assistance device, design assistance method, and recording medium storing design assistance program
WO2017168483A1 (ja) * 2016-03-28 2017-10-05 株式会社日立製作所 計算機及びデータベースの処理方法
WO2022137838A1 (ja) * 2020-12-25 2022-06-30 日本電気株式会社 プロセス割当制御装置、プロセス割当制御方法、及び、プロセス割当制御プログラムが格納された記録媒体

Also Published As

Publication number Publication date
US20140282588A1 (en) 2014-09-18
US9672076B2 (en) 2017-06-06
JPWO2012124125A1 (ja) 2014-07-17
JP5772948B2 (ja) 2015-09-02

Similar Documents

Publication Publication Date Title
JP5772948B2 (ja) システムおよびスケジューリング方法
Allavena et al. Scheduling of frame-based embedded systems with rechargeable batteries
JP4490298B2 (ja) プロセッサ電力制御装置及びプロセッサ電力制御方法
Lin et al. Task scheduling with dynamic voltage and frequency scaling for energy minimization in the mobile cloud computing environment
CN102193826B (zh) 一种异构多核处理器高效任务调度方法
US8813080B2 (en) System and method to optimize OS scheduling decisions for power savings based on temporal characteristics of the scheduled entity and system workload
Hotovy Workload evolution on the Cornell theory center IBM SP2
KR101622168B1 (ko) 실시간 스케쥴링 방법 및 이를 이용한 중앙처리장치
JPH09185589A (ja) 情報処理システムと情報処理システムの省電力方法
CN102096603B (zh) MapReduce系统中的作业分解控制方法及设备
JP2007199811A (ja) プログラム制御方法、計算機およびプログラム制御プログラム
CN102622273A (zh) 基于自学习负载预测的集群按需启动方法
US20140137122A1 (en) Modified backfill scheduler and a method employing frequency control to reduce peak cluster power requirements
CN107346263A (zh) 任务执行方法、存储介质以及计算机设备
US8677375B2 (en) Selecting executing requests to preempt
JP2011501309A (ja) リアルタイム・オペレーティング・システムにおけるプリエンプションの管理方法
JP2003256222A (ja) 分散処理システム、ジョブ分散処理方法およびプログラム
CN109324891A (zh) 一种比例空闲时间分配的周期任务低功耗调度方法
Begam et al. Timer-cloud: Time-sensitive vm provisioning in resource-constrained clouds
Holman et al. Guaranteeing Pfair supertasks by reweighting
CN109144691B (zh) 一种面向多核处理器的任务调度分配方法
Niu et al. A hybrid static/dynamic dvs scheduling for real-time systems with (m, k)-guarantee
CN101685335A (zh) 基于seda的应用服务器及其节能装置和方法
CN109298919B (zh) 面向高利用率任务集合的软实时系统的多核调度方法
Zhang et al. An interposed 2-level I/O scheduling framework for performance virtualization

Legal Events

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

Ref document number: 11860766

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2013504498

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11860766

Country of ref document: EP

Kind code of ref document: A1