WO2006129767A1 - マルチスレッド中央演算装置および同時マルチスレッディング制御方法 - Google Patents

マルチスレッド中央演算装置および同時マルチスレッディング制御方法 Download PDF

Info

Publication number
WO2006129767A1
WO2006129767A1 PCT/JP2006/311022 JP2006311022W WO2006129767A1 WO 2006129767 A1 WO2006129767 A1 WO 2006129767A1 JP 2006311022 W JP2006311022 W JP 2006311022W WO 2006129767 A1 WO2006129767 A1 WO 2006129767A1
Authority
WO
WIPO (PCT)
Prior art keywords
thread
instruction
priority
threads
instructions
Prior art date
Application number
PCT/JP2006/311022
Other languages
English (en)
French (fr)
Inventor
Nobuyuki Yamasaki
Original Assignee
Keio University
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 Keio University filed Critical Keio University
Priority to JP2007519071A priority Critical patent/JP5145936B2/ja
Publication of WO2006129767A1 publication Critical patent/WO2006129767A1/ja

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4843Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G06F9/4887Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues involving deadlines, e.g. rate based, periodic
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/48Indexing scheme relating to G06F9/48
    • G06F2209/483Multiproc

Definitions

  • the present invention generally relates to a central processing unit (CPU or MPU) (hereinafter simply referred to as “processor”), and in particular, a multi-thread processor and a simultaneous multi-processor capable of processing a plurality of threads in parallel within the processor. It relates to a method for controlling threading.
  • CPU or MPU central processing unit
  • processor multi-thread processor and a simultaneous multi-processor capable of processing a plurality of threads in parallel within the processor. It relates to a method for controlling threading.
  • the present invention improves the throughput of a plug processor while keeping the time constraint imposed on each thread in applications that perform real-time processing, such as various robots, automobiles, plants, and home automation.
  • the present invention relates to a multi-thread processor suitable for the purpose. Background art
  • the scheduler of the operating system ( os) gives priority to each thread according to the execution cycle of each thread and the time constraint in order to observe the time constraint of each thread. Then, based on the assigned priority, execution is performed by assigning computation resources in order from the thread with the highest priority.
  • a “thread” is an execution unit of a program, and usually one application program is composed of a number of threads.
  • FIG. 1 shows an example of real-time processing using a conventional single thread processor that executes only one thread at a time.
  • thread # 0 has the highest priority
  • thread # 7 has the lowest priority.
  • the release time indicates the time when the thread can be executed
  • the deadline indicates the time constraint of the thread (the final deadline for the execution to be completed).
  • thread # 1, thread # 2, and thread # 3 are initially executable. Among the executable threads # 1, # 2, and # 3, processor resource is given to the thread # 1 having the highest priority, and the thread # 1 is executed. When execution of thread # 1 is complete, a context switch occurs between the memory outside the processor and the processor to execute the next highest priority thread # 2. In the context switch, the context of the currently executing thread # 1 (that is, the process required to execute that thread). The program counter, register file, status register, and other resources in the server are saved in memory outside the processor, and the context of thread # 2 to be executed next is restored from the memory to the processor. The processor then starts executing thread # 2.
  • a context switch occurs, the context of thread # 2 is saved to memory, and the execution of thread # 3 starts after the context of thread # 3 returns from memory to the processor . If thread # 0 with higher priority becomes executable during execution of thread # 3, the execution of thread # 3 is interrupted, a context switch occurs, the context of thread # 3 is saved in memory, and thread # 0 Is returned to the processor and thread # 0 is executed first. When execution of thread # 0 is completed, the context switch saves to the context power memory of thread # 0, and the context of thread # 3 returns to the processor so that the suspended thread # 3 is executed. Resume.
  • Patent Document 1 Japanese Patent Application Laid-Open No. 2004-220070
  • Patent Document 2 JP 2004-295195 A Disclosure of the invention
  • an object of the present invention is to suppress fluctuations in thread execution time, which is a cause of a decrease in time prediction accuracy, in a multithread processor.
  • Another object of the present invention is to improve the throughput of a multi-thread processor.
  • the multi-thread central processing unit that processes a plurality of threads in parallel stores the priority of each thread, and uses the priority of each thread to determine the instructions of the plurality of threads. Control the order or frequency of processing. Power!
  • This multi-thread central processing unit stores the instruction execution target of each thread, monitors the number of execution instructions per hour of each thread, and performs feedback control operation using the number of execution instructions and the target value. Control the order or frequency of processing of multiple thread instructions.
  • this multi-thread central processing unit by controlling the instruction processing order Z frequency using the priority given to each thread, the competition among threads of various resources necessary for instruction processing is reduced. It is arbitrated according to the priority.
  • feedback control based on monitoring the instruction execution status of each thread (for example, the number of instructions executed per predetermined period, IPC or CPI) reduces the influence of other threads that are being processed at the same time, Each thread Fluctuations in the execution time of the code are suppressed. This leads to an improvement in the prediction accuracy of the execution time of each thread, and it is possible to improve the throughput of the entire processor while keeping the time constraints of real-time processing.
  • an allocation amount of a predetermined resource for example, an instruction buffer, a reservation station, or a reorder buffer
  • the thread's instruction footing, issue or execution order or frequency is controlled so that the resource allocation to those threads follows the priority of those threads. For example, if the resource allocation of one or more threads with a lower priority exceeds the resource allocation of one or more threads with a higher priority, at least among the threads with that higher priority Instruction fetch, issue or execution of a single thread is facilitated, or instruction fetch, issue or execution of a thread with its lower priority is suppressed or prohibited.
  • the instruction buffer occupancy of each thread is monitored, and the instruction buffer occupancy power of one or more threads having a higher priority is determined by one or more threads having a lower priority.
  • control to facilitate fetching instructions of at least one thread in the thread with the higher priority or to suppress fetching instructions of the thread with the lower priority Can do.
  • the instruction buffer occupancy by any thread is small and the predetermined lower limit condition is not met, the instruction fetch of that thread is promoted, or the instruction fetch suppression of that thread is released. You may control to do.
  • the reservation station's occupancy of each thread is monitored, and the reservation station's occupancy by one or more threads with higher priority is one or more threads with lower priority.
  • control is issued to promote the issue of instructions of at least one thread in the thread with the higher priority, or to suppress the footing of instructions of the thread with the lower priority. It can also be done. Also, among multiple threads with the same priority, priority is given to a thread with a smaller instruction buffer occupancy, or priority is given to a thread with a smaller reservation station occupancy. Can be controlled to give the right to issue instructions. [0016] Thus, in the preferred embodiment, control is performed so that the instructions of the higher priority thread are processed before the instructions of the lower priority thread.
  • the higher priority threads are wasting processing resources or using them inefficiently (for example, a cache miss, a branch prediction miss or a high probability, In the occupation of the station, etc.), it may be controlled so that the instruction of the lower priority thread is processed before the instruction of the higher priority thread.
  • the instruction execution state (for example, IPC) of each thread is set to be close to the instruction execution target (for example, IPC target value) set for each thread.
  • adjustments are made to the control conditions of the control operation based on the above-described priority. For example, when the instruction execution status of a thread does not meet the above target, the frequency of fetching or issuing the instruction of the thread is increased, or the instruction of another thread having a lower priority than that thread. The frequency of foot or issue is reduced.
  • the operation value for each thread called “inflation value” incorporated in the control condition of control by priority (in the preferred embodiment, called “inflation value”) is increased or decreased. This facilitates or inhibits the fetching or issuing of instructions for each thread. However, even if the operation value is changed, if the instruction execution state does not improve according to the change, the operation value is restored.
  • FIG. 1 is a time chart showing an example of real-time processing by a conventional single thread processor.
  • FIG. 2 is a block diagram showing a configuration of a main part of an embodiment of a multi-thread processor according to the present invention.
  • FIG. 3 is a block diagram showing a configuration for controlling the IPC of a thread.
  • FIG. 4 is a block diagram showing the state transition of the control function for controlling the thread IPC and the operation of increasing / decreasing the inflation value.
  • FIG. 5 is a time chart showing an example of real-time processing using a multi-thread processor that performs arbitration based on priority.
  • FIG. 6 A time chart showing an example of real-time processing by a multithreaded processor that performs IPC control along with priority arbitration.
  • FIG. 7 A time chart showing an example of real-time processing by an SMT processor that has four pipelines and performs IPC control along with priority arbitration.
  • FIG. 2 shows a block configuration of a main part of a multi-thread processor that works according to an embodiment of the present invention.
  • processor 10 The multi-thread processor (hereinafter simply referred to as "processor") 10 shown in FIG.
  • the processor 10 includes an issuing unit 12, a cache unit 14, and an execution unit 16.
  • the basic functions of these units 12, 14 and 16 are as follows.
  • the cache unit 14 accesses an external memory (not shown), fetches and caches instructions from the external memory, loads and caches data (operands) from the external memory, and stores data to be stored. Is cached and stored in external memory.
  • the execution unit 16 has calculation resources such as a memory access unit and various types of arithmetic units, executes instructions issued from the issue unit 12 in an out-of-order manner, and writes back the execution results of the instructions to the issue unit 12.
  • Issue unit 12 internally maintains the context of multiple threads so that multiple threads can be processed in parallel, fetches the instructions of those multiple threads from cache queue 14, decodes the instructions, The instruction (operation instruction of the decoding result of the instruction) is issued to the execution unit 16, the instruction execution result written back from the execution unit 16 is received, and the instruction is committed.
  • the processor 10 has two notable functions according to the principles of the present invention as follows.
  • One is an arbitration function based on priority. In other words, it is a function that mediates resource contention among a plurality of threads based on priorities assigned in advance to the plurality of threads.
  • the other is an IPC control function that keeps the fluctuation of the IPC (Instructions per Clock Cycle) of each thread constant and keeps it at a desired value as much as possible. That is, it is a fixed time per thread.
  • a function that adjusts the execution frequency of instructions in multiple threads so that the number of executed instructions in each thread matches the target number of execution instructions assigned to each thread as much as possible. is there.
  • the issuing unit 12 stores in advance the priority assigned in advance to each thread. The priority is also notified to the cache unit 14 and the execution unit 16. Issue unit 12, cache unit 14 and execution unit 16 are individually the amount of resources for instruction fetch, issue, execute and commit provided to each of multiple threads based on the priority of the multiple threads. To control. For this purpose, lower priority threads can be used without lowering the performance of higher priority threads simply by preventing the execution of higher priority threads from being hindered by lower priority threads. Is implemented.
  • the issuing unit 12 stores in advance a target value of the number of execution instructions allocated in advance to each thread.
  • the issuing unit 12 counts the actual number of executed instructions (number of committed instructions) for each thread at a fixed repetition period, and stores it in advance and compares it with the target value. If the actual number of instructions executed by a thread does not reach the target value, the above-mentioned control of resource contention arbitration based on priority is corrected by feedback control so that the frequency of fetching or issuing instructions of that thread increases. . For example, in order to increase the frequency of fetching or issuing instructions for a thread, fetching or issuing lower priority threads than that thread is suppressed. Conversely, fetching or issuing a lower priority thread than that thread is facilitated, for example, to reduce the frequency of fetching or issuing instructions for that thread.
  • the issue unit 12 includes a thread control unit 20, a PC (program counter) control unit 22 for the maximum number of threads that can be processed simultaneously (for example, eight), a fetch thread selector 24, an instruction decoder 26, an instruction analyzer 28, Instruction buffer 30, instruction issue select 32, a rename register 34, a register file 36 for the maximum number of threads that can be processed simultaneously (for example, eight), and a reorder buffer 40.
  • the cache unit 14 includes an instruction MMU (memory management unit) 42, an instruction cache 44, an instruction victim cache 46, an instruction wait buffer 48, a data MMU 50, a data read Z write buffer 52, a data cache 54, a data victim buffer 56, and a data wait. It has a buffer 58.
  • the execution unit 16 has a predetermined plurality (for example, five) of reservation stations 60 and various kinds of computing resources 62-80.
  • Computing resource 62-80 includes memory access unit 62, multiple branch units 64, integer divider 66, multiple integer arithmetic units 68, FP (floating point) divider 70, multiple FP arithmetic units 72, 64-bit integers Arithmetic unit 74, vector integer arithmetic unit 78, vector FP arithmetic unit 80, etc. Since threads that are processed simultaneously are unlikely to use the same computing resource at the same time, the number of reservation stations and the number of each computing resource are based on the maximum number of threads that can be processed simultaneously (for example, 8). Avoids unnecessary redundant resources.
  • the thread control unit 22 is a unit that functions as a core for controlling parallel processing of a plurality of threads.
  • the thread control unit 22 stores and holds the priority of the plurality of threads therein, and the priority thereof. Is distributed to the entire processor 10.
  • the number of priority threads that can be stored in the thread control unit 22 is preferably equal to or greater than the maximum number (eg, 40) of context threads that the processor 10 can internally hold.
  • the plurality of PC control units 22 are respectively assigned to a plurality of threads that can be simultaneously processed in the processor 10, and give the value of the program counter from each thread to the fetch thread selector 24. Contention between multiple threads occurs first in instruction cache access.
  • the fetch thread selector 24 selects one thread from the threads requesting the instruction cache access using the priority of each thread, and sets the program counter of the selected thread to the instruction MMU ( Memory management unit) 42
  • the fetch thread selector 24 requests instruction cache access and selects a thread having the highest priority among the threads! /.
  • the highest priority thread is not always selected, and the execution of the highest priority thread is not stressed. Under certain circumstances, a lower priority thread may be selected instead of the highest priority thread.
  • the instruction MMU 42 accesses the instruction cache 44 and passes the instruction of the selected thread to the instruction decoder 26 as well. If an instruction cache miss occurs, the external memory (not shown) must be accessed to read the cache line. Since the memory access has a higher latency than the cache access, when the cache miss continues, a plurality of memory access requests are waited in the instruction wait buffer 48. In this case, the instruction wait buffer 48 basically processes the memory access request ahead of the thread with the highest priority based on the priority of each thread. This gives priority to the execution of threads with a higher priority. However, memory access requests of higher priority threads are not always prioritized. Execution of higher priority threads is not stressed V. Under certain circumstances, lower priority threads than higher priority threads. In some cases, this memory access request is processed first.
  • a plurality of instructions (for example, eight lines corresponding to one line of the cache) are simultaneously sent from the instruction cache 44 to the instruction decoder 26.
  • the instruction decoder 26 simultaneously decodes a plurality of instructions fetched from the instruction cache 44 at the same time, and the decoding results of these instructions (also referred to as “instructions” for convenience in the following description) are simultaneously stored in the instruction buffer 40.
  • the instruction analyzer 28 is necessary to determine the instruction type of multiple instructions that are decoded simultaneously (which thread's instruction, which computing resource is used, and whether there is a dependency between instructions, etc.) Information on threads, opcodes, operands, etc.) and give the instruction type to the instruction issue selector 32.
  • the instruction issue selector 32 checks whether the reorder buffer 40, the rename register 34, and the reservation station 60 are empty and the dependency relationship between instructions in the instruction buffer 30. Based on the result, the instruction issue selector 32 To select an instruction that can be issued to the reservation station 60. A predetermined number of instructions (less than the maximum number of threads that can be processed simultaneously, for example, four) can be issued from the instruction buffer 30 simultaneously. At that time, if there are a plurality of instructions that can be issued in the instruction buffer 30 (especially, more than the predetermined number (four) above), the instruction issue selector 32, as a rule, has a higher rank according to the priority of each thread. Priority of thread with priority issued first To do. However, as will be described later, in a predetermined situation in which execution of a higher priority thread is not squeezed, an instruction of a lower priority thread than a higher priority thread may be issued first.
  • each reservation station 60 For various arithmetic units such as the integer arithmetic unit 68 and the FP arithmetic unit 72 connected to each reservation station 60, competition occurs between threads. Therefore, each reservation station 60 also arbitrates contention using the priority of each thread. Each reservation station 60 sends the instructions waiting there in an out-of-order order to the arithmetic unit in the order of the instruction power with the operands necessary for the operation. At that time, each reservation station 60 sends the instruction power of the thread with higher priority to the arithmetic unit first, based on the priority of each thread, in principle, when multiple instructions can be operated simultaneously. Thus, priority is given to the execution of a thread having a high priority.
  • execution of a higher priority thread that does not always give priority to a thread's instructions is always under pressure.
  • a lower priority thread is used instead of a higher priority thread.
  • the instruction of the thread is sent to the arithmetic unit first.
  • the data read Z write buffer 52 gives priority to the execution of the higher priority thread by executing the data cache access card of the higher priority thread first, based on the priority of each thread. .
  • high-priority cache access is not always given priority, and under certain circumstances where the execution of higher-priority threads is not under pressure, the lower-priority thread cache is replaced by the higher-priority thread. In some cases, access is processed first.
  • the data wait buffer 58 is based on the priority of each thread.
  • priority is given to the execution of threads with higher priorities by processing the memory access demands of threads with higher priorities first.
  • the memory access of the higher priority thread is not always given priority.
  • the lower priority is used instead of the higher priority thread.
  • the memory access of this thread is processed first.
  • the reorder buffer 40 temporarily holds the execution result of the instruction executed out of order, and commits the instruction in order.
  • a predetermined number of instructions for example, four less than the maximum number of threads that can be processed simultaneously) can be committed at the same time.
  • the reorder buffer 40 basically commits to the instruction power of the higher priority thread.
  • the priority is not always high and the execution of the higher priority thread is not stressed V.
  • the lower priority is substituted for the higher priority thread. May be committed first.
  • register files 36 There are as many register files 36 as the maximum number of threads that can be processed simultaneously (for example, eight), and each register file 36 is assigned to a plurality of threads that are processed simultaneously.
  • Each register file 36 stores the context of each thread.
  • the context cache 38 can store contexts for a larger number of threads (for example, 32 threads). The context of any thread in the context cache 38 and the context in any register file 36 can be quickly exchanged. Therefore, in this processor 10, the number of register files 36 (for example, 8) can be processed without performing a context switch, and the number of threads (for example, 32) supported by the context cache 38 can be processed at high speed. Switch.
  • an IPC control for suppressing the fluctuation of the IPC of each thread and maintaining it as close to the desired value as possible. It is done by the power processor 10. Controllability of instruction processing order or processing frequency using thread priority as described above Adjusted or modified by this IPC control.
  • the thread control unit 20, the fetch thread selector 24, and the instruction issue Rector 32 is directly involved in this IPC control.
  • the thread control unit 20 stores and holds a target value of the number of execution instructions allocated in advance to each of a plurality of threads.
  • the number of target threads that can be stored in the thread control unit 22 is preferably equal to or greater than the maximum number of context threads (for example, 40) that the processor 10 can internally hold.
  • the thread control unit 20 counts the actual number of instructions executed per thread (number of clock cycles in one IPC X 1 monitoring period) per fixed monitoring period (for example, every several hundred clock cycles).
  • FIG. 3 shows a configuration of a mechanism that performs this IPC control.
  • block 100 illustrates a mechanism for pipeline processing of the above-described multi-thread instructions in processor 10, where, as described above, using the priority of each thread, Arbitration control of resource competition between threads is performed.
  • the IPC control mechanism includes an execution instruction number monitoring unit 102, a comparison unit 104, and a control function unit 106, and is incorporated in the thread control unit 20 shown in FIG.
  • the execution instruction number monitoring unit 102 counts the number of execution instructions of each of a plurality of threads being processed in parallel for each fixed monitoring period.
  • the comparison unit 104 compares the counted actual instruction execution number with a target value stored in advance for each thread. As will be described later, in this embodiment, the comparison unit 104 also performs the following comparison in addition to the comparison between the actual instruction execution number and the target value because of the relationship of performing control according to state transition as described later. . That is, for each thread, the number of instructions (the number of carry-over instructions) that was insufficient for the number of instructions that the actual number of effective instructions should have been executed in the previous monitoring cycle is calculated, and the number of carry-over instructions and the target value are calculated. It is added to calculate the carry-over value (that is, the number of instructions that should be executed in the current monitoring period), and the carry-over value is compared with the actual instruction execution number this time.
  • the control function unit 106 performs a predetermined feedback control operation based on the comparison result by the comparison unit 104 and determines an operation value for adjusting the frequency of instruction fetch and instruction issue of each thread.
  • the operation value is applied to the pipeline processing mechanism 100. Where In this embodiment, the control operation for controlling the operation value according to the state transition as described later with reference to FIG. 4 is performed. Adopted.
  • As the operation value a parameter called an inflation value prepared for each thread as described later with reference to FIG. 4 is adopted.
  • the inflation value for each thread output from the control function unit 106 is a unit that controls the frequency of instruction fetch and instruction issuance in the pipeline processing mechanism 100, that is, in this embodiment, it is shown in FIG. This is given to the fetch thread selector 24 and the instruction issue selector 32.
  • the inflation value of each thread is gradually increased or decreased within a predetermined variable range by the control function unit 106 according to the comparison result between the number of instructions executed by each thread, the target value, and the remaining carry-over value.
  • the fetch thread selector 24 and the instruction issue selector 32 respond to the inflation value so that when the inflation value increases, the frequency of instruction fetch and instruction issue increases and the inflation value decreases, and the frequency of instruction fetch and instruction issue decreases. To adjust the control operation using the priority.
  • the fetch thread selector 24 and the instruction issue selector 32 respectively suppress the frequency of instruction fetch and instruction issue of a thread having a lower priority than that thread. As a result, the instruction foot of that thread and the frequency of instruction issuance increase. Conversely, for example, when the inflation value of a thread decreases, the fetch thread selector 24 and instruction issue selector 32 promote the frequency of instruction fetch and instruction issue for threads with lower priority than that thread, respectively. As a result, the instruction foot of that thread and the frequency of instruction issuance are reduced.
  • the IPC control mechanism having the above-described configuration monitors the IPC of each thread with a certain monitoring period PERIOD.
  • the programmer writes the value of “PERIO D X ipc” in the IPC setting register of each thread as the setting value of the number of instructions executed for each thread, with the IPC target value of each thread as ipc.
  • the IPC control mechanism increases the inflation value of any thread if the setting value “PERIOD X ip cj is satisfied!
  • the IPC control mechanism holds the following values for each thread and controls the inflation value.
  • ipc.target Setting value for the number of instructions executed, that is, PERIOD X ipc; com.cnt: Number of instructions executed this term, that is, the number of instructions actually executed in the current monitoring period PERIOD;
  • prev_com_cnt Number of instructions executed in the previous period, that is, the number of instructions actually executed in the previous monitoring period PERIOD;
  • carryover The number of carry-over instructions, that is, the number of instructions to be executed in the current monitoring period PERIOD, and if this value is not zero at the end of the current monitoring period PERIOD, this value is carried over to the next monitoring period PERIOD ;
  • stat.cnt Number of monitoring period PE RIOD that remains in the current state (each state shown in Fig. 4 described later).
  • the value of the carry-over instruction number carry_over is updated every monitoring period PERIOD,
  • control function unit 106 of the IPC control mechanism performs the state transition shown in FIG. 4 for each monitoring period PERIOD using the above-described values, and controls the inflation value.
  • the details are as follows.
  • FIG. 4 shows the state transition of the control function unit 106 and the operation of increasing / decreasing the inflation value.
  • control function unit 106 performs the operation shown in FIG. 4 in parallel for each of the plurality of threads.
  • “Normal” 110 is a state where the number of instructions executed com_cnt for this term satisfies the set value ipc_target and the number of carry-over instructions carryover, in other words, The thread performance is guaranteed. Until now the state was "Normal” 110 On the other hand, if the number of instructions executed in the current monitoring period PERIOD does not satisfy both of the set values ip C _target, the state transitions to “IPC failing” 112, while the force does not satisfy only the carryover number carryover. If so, the state transitions to “request failing” 114. Also, if “normal” 110 continues over a certain number of monitoring cycles, the inflation value is decreased, and as a result, the frequency of instruction fetch and instruction issuance for that thread is suppressed.
  • "Request failing" 114 is a state in which the current number of executed instructions com_cnt satisfies the set value ipc_target but does not satisfy the carryover number carryover.
  • the power that the IPC target value is satisfied in the short term is the state that the IPC target value is not satisfied in the previous monitoring period PERIOD, so that the insufficient instructions must be executed extra. If this state persists for a certain number of times over REQ_FAIL_THRESH, the inflation value is incremented and the state transitions to “Resource Up Check” 116.
  • “Request Failing” 114 when the current number of executed instructions satisfies the carry-over residual value, the state transitions to “Normal” 110.
  • IPC failing 112 is a state in which the current number of execution instructions com-cnt does not satisfy both the carry-over instruction number carry-over and the set value ip C _target. In other words, the IPC target value is satisfied in the short and long term. If this state continues for a certain number of times of IPC_FAIL_THRESH or more, the inflation value is increased and the state transitions to “Resource App Check” 116. On the other hand, in “IPC failing” 112, when both the carry-over instruction number carry_over and the set value ip target are satisfied, the state transitions to “normal” 110.
  • "Resource up check” 116 is a state for checking whether there has been an improvement in IPC commensurate with the increase in inflation value after the inflation value has been increased. In this state, if the increment of the current execution instruction number com_cnt compared to the previous execution instruction number prev_com_cnt is greater than or equal to the preset threshold value EFFICIENT_THRESH, the inflation value if the carry forward instruction number carry_over is not yet satisfied. Is further increased. On the other hand, if the carryover number carryover is satisfied, the state transitions to “normal” 110. In addition, in the “resource up check” 116, the above increment is the threshold EFFICIENT_THR. If it is less than ESH, the inflation value is decreased and the state transitions to “resource down” 118.
  • Resource down 118 is a state corresponding to a case where improvement in IPC commensurate with an increase in inflation value is not recognized. When entering this state, the inflation value is decreased and the state transitions to “resource down check” 120.
  • "Resource down check” 120 is a state for checking whether or not the IPC has significantly decreased after the inflation value is decreased. In this state, if the number of execution instructions com_cnt for the current period falls below a preset threshold value compared to the number of execution instructions prev_com_cnt for the previous period, the inflation value is returned to the previous period. Otherwise, the inflation value is kept at the current value.
  • the state transitions to “Normal” 110, “IPC Failing” 112, or “Request Failing” 114.
  • the status is “normal” 1 10 and “IPC failing” 112 and “request failing” 114! Whether to shift to the difference is the result of comparing the number of executed instructions com_cnt with the set value ipc_target and the number of carry forward instructions carry_over It depends on.
  • the inflation value is increased. However, even if the inflation value is increased, if the improvement in IPC commensurate with the increase cannot be obtained, the inflation value is restored. The reason is to cope with the maximum performance of the program changing with time. In other words, because the IPC of the program changes with time, the IPC target value may not be met in a certain monitoring period P ERIOD. In such a case, increasing the inflation value is meaningless and only prevents other threads from executing. Therefore, if an increase in the inflation value does not improve the IPC commensurate with the increase, it can be expected to recover at the future monitoring period PERIOD, so cancel the increase in the inflation value. Insufficient instruction is added to the carry-over number of instructions carry_ 0Ve r. By increasing the inflation value when the IPC of the program becomes easier to improve in the future, the number of insufficient instructions will be eliminated.
  • FIG. 5 shows an example in which real-time processing is performed using a multi-thread processor that performs arbitration based on the above-described priority.
  • a single pipeline multi-thread processor such as the processor 10 described above, which has only one thread that can be processed simultaneously, is not possible with an SMT processor that can process multiple threads simultaneously. It is assumed that this is the case of ideal execution (no cache miss or branch misprediction occurs).
  • thread # 7 having the highest priority of thread # 0 is the lowest.
  • thread # 1, thread # 2, and thread # 3 are initially executable.
  • thread # 1, thread # 2, and thread # 3 are executed in parallel.
  • execution of thread # 1 with the highest priority is prioritized due to arbitration of computing resources according to priority. Therefore, thread # 1 is executed first.
  • thread # 2 with the next highest priority is executed preferentially by arbitration by priority.
  • thread # 2 since the context of the thread # 2 is held in the processor, the thread # 2 is immediately executed without performing a context switch. Even if thread # 0 with a higher priority becomes executable during execution of thread # 4, execution of thread # 0 is prioritized due to arbitration of computing resources by priority. At this time, thread # 0 is executed immediately without performing a context switch. When execution of thread # 0 is completed, computing resources are then allocated to thread # 4, and thread # 4 resumes execution immediately.
  • a multi-thread processor can maintain high throughput of the entire processor by executing another thread.
  • the multi-thread processor when a high-priority thread stalls, it is possible to perform arbitration by priority so that the next highest-priority thread is executed. Can improve It is.
  • FIG. 6 shows an example in which multiple threads are simultaneously executed by a multithread processor that performs IPC control together with arbitration by priority.
  • the example in Figure 6 shows the actual execution of a single pipeline multithread processor with only one thread that can be processed simultaneously (causing a cache miss or branch prediction miss).
  • thread # 0 has the highest priority of thread # 0.
  • # 2 and thread # 3 become executable.
  • Arbitration of computing resources by priority gives priority to the execution of thread # 1, which has the highest priority among thread # 1, thread # 2 and thread # 3 that can be executed.
  • no cache miss or branch prediction miss occurs, so threads are executed in order according to priority.
  • there is no IPC change because there is no interference between threads.
  • a cache miss or branch prediction miss may occur. For example, if thread # 1 stalls due to this type of mistake, thread # 2 with the next highest priority will be executed.
  • thread # 2 Since the context of thread # 2 is held in the processor, thread # 2 can be executed immediately without performing a context switch. For this reason, it appears that “thread # 1 and thread # 2 (or more threads are executed concurrently in parallel). Since thread # 2 uses computational resources, Affects the execution time of high thread # 1, so interference between threads occurs and IPC changes occur.If IPC control is not adopted, the time prediction accuracy of thread # 1 is reduced. On the other hand, by adopting IPC control, each thread # 1 and # 2 is set so that the number of executed instructions (IPC) of each thread # 1 and # 2 that are running at the same time approaches the target value. Therefore, even if multiple threads are executed at the same time, the degradation of time prediction accuracy is small, so it is possible to improve the throughput of the entire processor while keeping the time constraint. .
  • IPC executed instructions
  • FIG. 5 and FIG. 6 illustrate the case of a single pipeline processor for ease of understanding. However, the same explanation applies to SMT processors that can process multiple threads simultaneously as shown in Figure 2.
  • Figure 7 shows the simultaneous execution of multiple threads from the SMT processor that uses the 4 pipelines shown in Figure 2 and performs IPC control along with arbitration by priority ( An example in the case of actual execution) is shown.
  • This control mediates and resolves competition between threads in each operation resource such as an instruction fetch slot, instruction issue slot, and operation unit when a plurality of threads are executed simultaneously.
  • the priority assigned by the scheduler is used to resolve conflicts between threads.
  • low priority ! high priority thread, prevent thread execution from being interrupted, and high priority thread execution guaranteed To do.
  • a mechanism is adopted that executes low priority threads without degrading the performance of high priority threads.
  • the SMT architecture uses a superscalar architecture, so single-thread performance is higher than that of a normal single pipeline.
  • it is necessary to share execution resources among threads so that all execution resources can be used by a single thread. Sharing execution resources can be expected to improve the performance of a single thread, but it tends to affect performance between threads, so lower priority threads can adversely affect the performance of higher priority threads. End up.
  • slot priority control such as fetch slot and issue slot
  • control of shared resource occupancy can be implemented.
  • a control method is adopted that avoids bottlenecks in fetch thread selection as much as possible and controls the entire instruction supply mechanism.
  • fetch thread selection it is possible to employ a control method capable of fetching other threads while suppressing the performance degradation of the highest priority thread as much as possible.
  • other lower priority threads use slots that are wasted (not used) by the highest priority thread under certain circumstances.
  • the performance of the entire system can be improved to some extent. The following can be mentioned as such a control method.
  • the above three control methods are methods of storing instructions of the lower priority thread using the slots that the highest priority thread wastes.
  • conditional branch instructions are executed, the higher the possibility of branch misprediction, and the higher the possibility of wasting execution resources. Therefore, when the number of conditional branch instructions in the pipeline exceeds the threshold, fetch is performed from a thread with a low priority.
  • the threshold value is set lower than the 24 instructions described above. The lower the threshold, the lower the performance of the higher priority thread.
  • BTB Brain Target Buffer, not shown
  • BTB Branch Target Buffer, not shown
  • BTB has much lower prediction accuracy because there is no information on whether there is a branch instruction. Therefore, limit the number of speculative fetches by BTB. By controlling the number of stages in the fetch control pipeline, the number of consecutive fetches is suppressed.
  • the control by the number of instructions in the pipeline may fill the reservation station 60. Therefore, count the number of instructions in the reservation station 60 and exceed the threshold. If it does, fetch the thread power with low priority.
  • the instruction fetch mechanism power to supply the instruction directly to the instruction execution unit 16 is considered to have a large effect on the thread performance if there are enough instructions. . Therefore, in order to suppress a decrease in the performance of a high-priority thread, the instruction issue mechanism issues an instruction of a thread with the highest priority as much as possible. In issuing instruction selection by priority, as in the case of fetch thread selection, a thread instruction with a low priority is issued in the following manner.
  • the instruction of the low priority thread includes an instruction to use another reservation station! /, Issue the instruction.
  • the target reservation station 60 If the target reservation station 60 is full, the low priority is low unless the high priority thread and low V, and the units used by the thread are biased and different. Not many instructions can be issued from a thread.
  • the reorder buffer 40 and the rename register 34 are shared between threads, it is impossible to issue instructions from a low priority thread. Is less frequent. In other words, compared to fetch thread selection where a cache miss can occur, the priority is low and the possibility of issuing a thread instruction is low. Additional control methods are used to conceal latency by executing multiple threads in parallel. It is. Furthermore, emphasis is placed on the overall system performance, the following parameters:
  • execution resources can be implemented in two ways: prepared for each thread or shared.
  • the processor 10 shown in FIG. 2 aims to improve the performance of a single thread by sharing execution resources.
  • the number of entries of the nofer that can be used by each thread is set by software in units of partitions. In this regard, the following two control methods can be adopted.
  • a partition usage right is set for each thread using a control register.
  • the same partition can be used by multiple threads.
  • the resources that can be used for each thread can be individually specified, so stable performance can be expected. However, when the periodic task finishes executing and waits for the next period, the thread executes Execution resources that are difficult to handle when it is not possible cannot be used effectively.
  • the maximum number setting method other slots are controlled by priority control, so execution resources can be used from the highest priority thread to the specified maximum amount, depending on the situation. It is easy to use execution resources as much as possible. However, if the sum of the maximum number of threads exceeds the total number of partitions, threads with low priority will interfere with execution of threads with high priority.
  • the resource reservation method can statically predict performance, and the maximum number setting method can dynamically measure the efficiency of execution resource usage.
  • each thread can be controlled to allocate an amount of processor resources according to its priority. For example, with respect to the instruction cache, it is possible to control the allocation amount of each instruction buffer to each thread according to the priority of each thread. This makes it easier for the lower-priority thread to acquire the fetch right, and therefore the performance fluctuations that may cause some degradation in the performance of the highest-priority thread are reduced, and the predictability is expected to increase. In addition, improvement in instruction buffer utilization efficiency can be expected to improve overall performance.
  • This is mainly executed by the fetch thread selector 24 in the processor 10 shown in FIG.
  • This control monitors the occupancy of the instruction buffer of each thread, and if the occupancy of the lower priority thread exceeds the occupancy of the higher priority thread, the instruction of the thread priority of the lower priority is exceeded. It suppresses or prohibits fetching.
  • the following symbols are used in the following description.
  • Thread Thread
  • Gj A group of threads given the same priority. Priority between groups is assumed to be Gj> G ⁇ 1;
  • ThOlMinlQ Thread with the smallest instruction buffer occupation in group Gj
  • THNUM Threads Ti belonging to group Gj
  • IQSUM Number of instruction buffers occupied by group Gj (total number of instruction buffers occupied by threads belonging to group Gj);
  • MIN_IQ_THRESH Predetermined lower limit for the number of instruction buffers occupied per thread; FREQj: Group Gj fetch request;
  • FETCHj Fetch request Thread that fetches when FREQj is accepted Chired).
  • the fetch request FREQj and the fetch thread FETCHj have the following control conditions (1) and (
  • FETCHj ThOlMinlQ (Gj)... Control conditions (2)
  • the value MINJQ_THRESH is a lower limit value for the purpose of reducing the frequency with which the instruction buffer of each thread becomes empty.
  • This value MINJQ_THRESH is the following condition value,
  • FETCHj and FREQj are determined.
  • processor 10 only one thread performs fetch in one cycle, so one thread must be selected from a plurality of fetch requests. Therefore, in order to prioritize the execution of the highest priority thread, a control method can be adopted in which the fetch request of the highest priority group is selected and the fetch thread is determined. Further, even if the thread selected as the fetch thread cannot perform fetch due to a cache miss or the like, the fetch right may not be transferred to the lower priority thread. This is to prevent reversal of the resource occupancy so that the lower priority thread does not squeeze the performance of the upper priority thread.
  • the instruction issue of each thread is controlled so that the resource occupancy follows the priority.
  • This instruction issue control is executed by, for example, the instruction issue selector 32 in the processor 10 shown in FIG.
  • a reservation station or reorder buffer can be used as a resource to be monitored.
  • the occupation amount of each thread of the reservation station is monitored, and if the occupation amount of a thread with a higher priority than the occupation power of a thread with a lower priority is exceeded, Instruction issue from lower priority threads is suppressed or prohibited.
  • the following symbols are used.
  • Tj, k threads belonging to group Gj;
  • RSNUM Tj, k: Number of reservation stations occupied by thread Ti, k; RSSUM (Gj.): Number of reservation stations occupied by group Gj (total number of reservation stations occupied by threads belonging to group Gj);
  • IREQj.k Instruction issue request for thread Tj, k.
  • Instruction issue request IREQj, k is determined according to the following control condition (3).
  • the reservation station occupation number RSNU M (Tj, k) of a certain thread Tj, k has a lower rank priority than that of the group Gj-1.
  • the instruction issue request IREQj, k for the thread Tj, k is accepted, but its priority is low!
  • the group instruction issue request IREQ ⁇ l, k is accepted. It is not possible.
  • a maximum of four threads can issue instructions in one cycle. Unlike instruction fetch, instruction issue requests may come from multiple threads in the same group. Therefore, in the instruction issue control, the threads issuing the instruction issue requests are ranked as follows, and the top four threads in the rank are used as issue threads.
  • Reservation station 60 occupies in ascending order among threads of the same priority (group)
  • the instruction issue control method is very similar to that of the aforementioned instruction foot.
  • the difference is that the occupied number of the reservation station 60 is used instead of the occupied number of the instruction buffer 30, and there is no condition corresponding to the lower limit value MINJQ_THRESH of the occupied number.
  • the reason why the reservation station 60 is used as a criterion for issuing threads is as follows. In other words, there are cases where the thread selected as the issuing thread cannot actually issue. This is mainly the case as follows.
  • the reorder buffer 40 and the rename buffer 34 are linked, and the actual restriction is the reorder buffer 40 power reservation station 60.
  • the occupation number of the reservation station 60 is used as a thread selection criterion in order to allocate more precious resources to high priority threads.
  • the evaluation test conducted by the inventor has also shown that the force of the reservation station 60 is more influential than the reorder buffer 40.
  • IPC control the number of instructions executed by each thread is monitored at regular intervals, and if it is less than the specified target value, the frequency at which instructions are fetched and issued is increased. In addition, the performance of the program may change greatly with time, and this point is taken into account in the IPC control described below.
  • the inflation value INFLj is a predetermined value range, For example, in the range of 0 ⁇ INFLj ⁇ 32, it is increased or decreased according to the current performance of group Gj. In other words, if the IPC with the specified group Gj is not obtained, the inflation value INFLj is increased, which suppresses the fetch and issue of threads with a lower priority than the group Gj. Increase thread performance.
  • the variable range of the inflation value INFLj is from 0 to 32 based on the fact that the instruction buffer 30 and the reservation station 60 have 32 entries in the processor 10 shown in FIG. As mentioned above, although embodiment of this invention was described, this embodiment is only the illustration for description of this invention, and is not the meaning which limits the scope of the present invention only to this embodiment. The present invention can be implemented in various other modes without departing from the gist thereof.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Advance Control (AREA)

Abstract

   同時マルチスレッディングを行なうCPUによるスレッド実行時間の予測精度が向上される。CPU内で、各スレッドの優先度が設定され、原則として上位優先度のスレッドが下位優先度のスレッドより優先的に処理されるよう、複数スレッドの命令の処理順序/頻度が制御される。それにより、同時処理されるスレッド間の資源の競合が調停される。加えて、CPU内で各スレッドの実行命令数の目標値が設定され、一定周期で各スレッドの周期当たり実行命令数がカウントされ、そして、実行命令数と目標値との比較に基づくフィードバック制御動作により、優先度を用いた命令処理順序/頻度が修正される。それにより、どのようなスレッドの組み合わせで複数スレッドの同時処理が行われても、各スレッドの実行時間(またはIPC)が所望値近傍に安定して保たれる。  

Description

明 細 書
マルチスレッド中央演算装置および同時マルチスレツディング制御方法 技術分野
[0001] 本発明は、一般的には中央演算装置 (CPUまたは MPU) (以下、単に「プロセッサ」 と呼ぶ)に関わり、特に、プロセッサ内で複数のスレッドを並列処理できるマルチスレ ッドプロセッサおよび同時マルチスレツディングを制御するための方法に関する。
[0002] 本発明は、特に、各種ロボット、自動車、プラント、ホームオートメーション等の実時 間処理を行うアプリケーションにお 、て、各スレッドに課された時間制約を守りつつプ 口セッサのスループットを向上するために好適なマルチスレッドプロセッサに関する。 背景技術
[0003] 実時間処理を行うリアルタイムシステムでは、各スレッドの時間制約を守るために、 オペレーティングシステム(os)のスケジューラは各スレッドの実行周期や時間制約に より、各スレッドに優先度を付与する。そして、付与された優先度を基に、優先度の高 いスレッドから順番に演算資源を割り当てて実行を行う。ここで、「スレッド」とは、プロ グラムの実行単位であり、通常、一つのアプリケーションプログラムは多数のスレッド から構成される。
[0004] 図 1に、一時に 1スレッドのみを実行する従来のシングルスレッドプロセッサを用いて 実時間処理を行った場合の例を示す。この例では、スレッド #0の優先度が最も高ぐ スレッド #7の優先度が最も低いとする。また、リリース時刻はそのスレッドが実行可能 になる時刻、期限はそのスレッドの時間制約 (その実行が完了されるべき最終期限) を示す。
[0005] 図 1に示された例では、最初にスレッド #1、スレッド #2およびスレッド #3が実行可能 になる。これら実行可能なスレッド #1、 #2および #3の中で最も優先度の高いスレッド #1 にプロセッサ資源が与えられ、スレッド #1が実行される。スレッド #1の実行が完了する と、次に優先度の高いスレッド #2の実行を行うために、プロセッサ外のメモリとプロセッ サとの間でコンテキストスィッチが起こる。コンテキストスィッチでは、現在実行してい るスレッド #1のコンテキスト(すなわち、そのスレッドを実行するために必要なプロセッ サ内のプログラムカウンタ、レジスタファイル、ステータスレジスタ等の各種資源)をプ 口セッサ外のメモリに退避させ、次に実行するスレッド #2のコンテキストをメモリからプ 口セッサ内に復帰させる。その後、プロセッサはスレッド #2の実行を開始する。スレッド #2の実行が完了すると、コンテキストスィッチが起こり、スレッド #2のコンテキストがメモ リに退避し、スレッド #3のコンテキストがメモリからプロセッサ内に復帰した後、スレッド #3の実行が開始される。スレッド #3の実行中に、より優先度の高いスレッド #0が実行 可能になると、スレッド #3の実行が中断され、コンテキストスィッチが起こり、スレッド #3 のコンテキストがメモリに退避し、スレッド #0のコンテキストがプロセッサ内に復帰して、 スレッド #0の実行が先に行われる。スレッド #0の実行が完了すると、コンテキストスイツ チにより、スレッド #0のコンテキスト力メモリに退避し、スレッド #3のコンテキストがプロ セッサ内に復帰することにより、中断していたスレッド #3の実行が再開する。
[0006] このように従来のシングルスレッドプロセッサを用いた処理では、優先度の高!、スレ ッドの実行が完了した場合や、現在実行しているスレッドよりもより優先度の高いスレ ッドが実行可能になった場合は、コンテキストスィッチが発生する。 OSは、現在実行し ているスレッドのコンテキストをメモリに退避し、次に実行するスレッドのコンテキストを プロセッサ内に復帰させなければならない。リアルタイムシステムでは、このコンテキ ストスィッチが大きなオーバヘッドとなる。一方、コンテキストスィッチのオーバヘッドを 削減する技術として、プロセッサ内で複数のスレッドを並列処理するマルチスレッドプ 口セッサがある。マルチスレッドプロセッサは、プロセッサ内に複数スレッド分のコンテ キストを保持し、これらをプロセッサ内のハードウェアで切り替えながらそれぞれのス レッドを実行するため、コンテキストスィッチを行わずに複数のスレッドを実行すること が可能である(例えば、特許文献 1参照)。
[0007] また、実時間処理に適したマルチスレッドプロセッサのスループット向上のための別 の制御技術として、各スレッドに割り当てられた優先度に応じて、複数のスレッドの命 令の実行順序をリザべーシヨンステーションにて入れ替える技術が知られて 、る(例 えば、特許文献 2参照)。
[0008] 特許文献 1:特開 2004— 220070号公報
特許文献 2 :特開 2004— 295195号公報 発明の開示
発明が解決しょうとする課題
[0009] マルチスレッドプロセッサにおいて、複数のスレッドを並列に実行するとき、キヤッシ ュアクセスや演算器等の演算資源においてスレッド間の競合が起こり得る。演算資源 の競合が起こると、 1スレッド単体の実行時間が増加する。そして、プロセッサ内で並 列的に実行される複数のスレッドの組み合わせが異なれば、演算資源の競合の仕方 や頻度が異なってくるため、各スレッドの実行時間が異なってくる。その結果、各スレ ッドの実行時間の予測精度が低下する。特にリアルタイムシステムでは、各スレッドに 時間制約があるため、各スレッドの実行をその時間制約内に完了させ得るよう、スケ ジユーラによりスレッド実行のスケジューリングがなされる。し力し、マルチスレッドプロ セッサを用いたシステムでは、上記理由から時間予測精度が低いために、スレッドの 時間制約を守れるようなスケジューリングが難しい。
[0010] 従って、本発明の目的は、マルチスレッドプロセッサにおいて、時間予測精度の低 下の原因であるスレッド実行時間の変動を抑制することにある。
[0011] 本発明の別の目的は、マルチスレッドプロセッサのスループットを向上させることに ある。
課題を解決するための手段
[0012] 本発明に従えば、複数のスレッドを並列的に処理するマルチスレッド中央演算装置 は、各スレッドの優先度を記憶し、各スレッドの優先度を用いて、複数のスレッドの命 令の処理の順序または頻度を制御する。力!]えて、このマルチスレッド中央演算装置 は、各スレッドの命令実行目標を記憶し、各スレッドの時間当たりの実行命令数を監 視し、そして、実行命令数と目標値を用いたフィードバック制御動作により、複数のス レッドの命令の処理の順序または頻度を制御する。
[0013] このマルチスレッド中央演算装置によれば、各スレッドに付与された優先度を用い た命令処理順序 Z頻度の制御により、命令処理に必要な各種資源のスレッド間での 競合が、各スレッドの優先度に応じて調停される。それに加えて、各スレッドの命令実 行状態 (例えば所定周期当りの実行命令数、 IPCあるいは CPIなど)の監視に基づくフ イードバック制御により、同時に処理されている他のスレッド力もの影響が減り、各スレ ッドの実行時間の変動が抑制される。引いては、各スレッドの実行時間の予測精度の 向上につながり、実時間処理の時間制約を守りつつ、プロセッサ全体のスループット を向上することが可能となる。
[0014] 好適な実施形態では、このマルチスレッド中央演算処理装置内の所定の資源 (例 えば、命令バッファ、リザべーシヨンステーションまたはリオーダバッファ等)の複数ス レッドへの割当量が監視され、監視されたそれらスレッドへの資源割当量がそれらス レッドの優先度に従うように、それらスレッドの命令フ ツチ、発行または実行の順序 または頻度が制御される。例えば、より下位の優先度をもつ 1以上のスレッドの資源 割当量が、より上位の優先度をもつ 1以上のスレッドの資源割当量を超えた場合、そ の上位優先度をもつスレッド中の少なくとも一つのスレッドの命令フェッチ、発行また は実行が促進され、または、その下位優先度をもつスレッドの命令フェッチ、発行また は実行が抑制または禁止される。
[0015] より具体的には、各スレッドの命令バッファの占有量を監視して、より上位の優先度 をもつ 1以上のスレッドによる命令バッファの占有量力 下位の優先度をもつ 1以上の スレッドによるそれ以下であるとき、その上位優先度をもつスレッド中の少なくとも一つ のスレッドの命令のフェッチを促進し、または、その下位優先度をもつスレッドの命令 のフェッチを抑制するように制御を行なうことができる。また、いずれかのスレッドによ る命令バッファの占有量が少なくて所定の下限条件を満たさないときには、そのスレ ッドの命令のフェッチを促進し、または、そのスレッドの命令のフェッチの抑制を解除 するように制御してもよい。更に、各スレッドのリザべーシヨンステーションの占有量を 監視して、より上位の優先度をもつ 1以上のスレッドによるリザべーシヨンステーション の占有量が、下位の優先度をもつ 1以上のスレッドによるそれ以下であるとき、その上 位優先度をもつスレッド中の少なくとも一つのスレッドの命令の発行を促進し、または 、その下位優先度をもつスレッドの命令のフ ツチを抑制するように制御を行なうこと もできる。また、同じ優先度をもつ複数のスレッド間では、命令バッファの占有量がよ り小さいスレッドに優先的に、命令フェッチ権を与え、または、リザべーシヨンステーシ ヨンの占有量がより小さいスレッドに優先的に、命令発行権を与えるように制御を行な うことができる。 [0016] このようにして、好適な実施形態では、上位優先度のスレッドの命令が下位優先度 のスレッドの命令より先に処理されるように制御が行われる。しかし、上位優先度のス レッドが処理資源を無駄にする力 または非効率的に使用するような所定の状況下( 例えば、キャッシュミスの発生、分岐予測ミスの発生または高い発生可能性、またはリ ザべーシヨンステーションの占領など)では、下位優先度のスレッドの命令が上位優 先度のスレッドの命令より先に処理されるように制御してもよい。
[0017] また、好適な実施形態では、各スレッドの命令実行状態 (例えば IPC)をスレッド毎に 設定された命令実行目標(例えば IPCの目標値)に近づけるように、特に命令フェツ チまたは発行のステージにお 、て、上述した優先度による制御動作の制御条件に調 整が加えられる。例えば、或るスレッドの命令実行状況が上記目標を満たさない場合 、そのスレッドの命令のフェッチまたは発行の頻度が増加させられ、または、そのスレ ッドより下位の優先度をもつ他のスレッドの命令のフ ツチまたは発行の頻度が抑制 される。優先度による制御動作を調整させるために、優先度による制御の制御条件 に組み込まれた「インフレーション値」と呼ばれるスレッド毎の操作値 (好適な実施形 態では、「インフレーション値」と呼ばれる)が増減され、それにより、各スレッドの命令 のフェッチまたは発行が促進されたり、抑制されたりする。しかし、その操作値を変化 させても、その変化に応じた命令実行状態の改善が現れない場合には、操作値が元 に戻される。
発明の効果
[0018] 本発明によれば、マルチスレッドプロセッサにお 、て、各スレッドの実行時間または I PCの変動を小さくすることが可能となる。これにより、実時間処理のためのより良いス ケジユーリングが容易となり、ひいては、プロセッサ全体のスループットの向上に貢献 できる。
図面の簡単な説明
[0019] [図 1]従来のシングルスレッドプロセッサによる実時間処理の例を示すタイムチャート 図。
[図 2]本発明に従うマルチスレッドプロセッサの一実施形態の主要部の構成を示すブ ロック線図。 [図 3]スレッドの IPCを制御するための構成を示すブロック線図。
[図 4]スレッドの IPCを制御するための制御関数の状態遷移とインフレーション値増減 の動作を示すブロック線図。
[図 5]優先度による調停を行なうマルチスレッドプロセッサを用いて実時間処理を行つ た場合の例を示すタイムチャート。
[図 6]優先度による調停と共に IPC制御を行なうマルチスレッドプロセッサによる実時 間処理の例を示すタイムチャート。
[図 7]4つのパイプラインをもち、優先度による調停と共に IPC制御を行なう SMTプロセ ッサによる実時間処理の例を示すタイムチャート。
符号の説明
10 マノレテスレツドプロセッサ
12 発行ユニット
14 3fャッシュユニット
16 実行ユニット
20 スレッドコントローノレユニット
24 フェッチスレッドセレクタ
32 命令発行セレクタ
36 レジスタファイル
38 コンテキストキャッシュ
40 リオーダバッファ
44 命令キャッシュ
48 命令ウェイトバッファ
52 データリード zライトバッファ
58 データウェイトノ ッファ
60 リザべーシヨンステーション
100 パイプライン処理機構
102 実行命令数監視部
104 比較部 106 制御関数部
発明を実施するための最良の形態
[0021] 以下、図 2から図 6を参照して、本発明の一実施形態について説明する。
[0022] 図 2は、本発明の一実施形態に力かるマルチスレッドプロセッサの主要部のブロック 構成を示す。
[0023] 図 2に示されるマルチスレッドプロセッサ (以下、単に「プロセッサ」という) 10は、 SMT
(Simultaneous Multi Threading:同時マルチスレツディング)アーキテクチャを採用し、 複数 (例えば最大 8つ)のスレッドを同時に処理することができるとともに、より多く(例 えば最大 40)のスレッドのコンテキストを内部に保持して、外部のメモリとの間でのコ ンテキストスィッチなしに多数のスレッドを処理することができる。図示のように、このプ 口セッサ 10は発行ユニット 12、キャッシュユニット 14および実行ユニット 16を備える。 これらのユニット 12, 14および 16の基本的な機能は次のとおりである。キャッシュュ ニット 14は、外部のメモリ(図示省略)にアクセスし、その外部メモリから命令をフェツ チしてキャッシュし、外部メモリからデータ (オペランド)をロードしてキャッシュし、また 、ストアされるべきデータをキャッシュして外部メモリへストアする。実行ユニット 16は、 メモリアクセスユニットや各種の演算器等の演算資源を有し、発行ユニット 12から発 行された命令をアウトォブオーダで実行し、命令の実行結果を発行ユニット 12へライ トバックする。発行ユニット 12は、複数のスレッドを並列的に処理できるよう、複数のス レッドのコンテキストを内部で保持し、それら複数のスレッドの命令をキャッシュュ-ッ ト 14からフェッチし、その命令をデコードし、その命令(その命令のデコード結果の動 作指示)を実行ユニット 16へ発行し、実行ユニット 16からライトバックされた命令実行 結果を受け、そして、その命令をコミットする。
[0024] 上述した基本的な機能の上に、このプロセッサ 10は、本発明の原理に従う次のよう な特筆すべき 2つの機能を有する。一つは、優先度による調停機能である。すなわち 、それは、複数のスレッドに予め割り当てられた優先度に基づいて複数のスレッド間 での資源の競合を調停する機能である。別の一つは、各スレッドの IPC (Instructions per Clock Cycle:クロックサイクル当り命令実行数)の変動を抑えできるだけ所望値で 一定に保っための IPC制御機能である。すなわち、それは、スレッド毎の一定時間当 たりの実行命令数を監視し、各スレッドの実行命令数が各スレッドに予め割り当てら れた実行命令数の目標値にできるだけ一致するように、複数のスレッドの命令の実行 頻度を調整する機能である。この 2つの機能は相互に関係付けられ同時に働く。ここ で、各スレッドの優先度や命令実行数目標値は、例えば、 OSのスケジューラゃプログ ラマ力 プロセッサ 10に対して設定される。
[0025] 優先度による調停機能を実現するために、発行ユニット 12は、各スレッドに予め割 り当てられた優先度を予め記憶する。その優先度はキャッシュユニット 14および実行 ユニット 16にも通知される。発行ユニット 12、キャッシュユニット 14および実行ユニット 16は、個別に、複数のスレッドの優先度に基づいて、複数のスレッドのそれぞれに提 供される命令フェッチ、発行、実行およびコミットのための資源の量を制御する。なお 、この目的のために、上位優先度のスレッドの実行が下位優先度のスレッドにより阻 害されないようにするだけでなぐ上位優先度のスレッドの性能を低下させずに、下 位優先度のスレッドも実行されるような制御方法が実装される。
[0026] さらに、 IPC制御機能を実現するために、発行ユニット 12は、各スレッドに予め割り 当てられた実行命令数の目標値を予め記憶する。発行ユニット 12は、一定の繰返し 周期でスレッド毎の実際の実行命令数 (コミットされた命令の数)をカウントし、それを 予め記憶して 、る目標値と比較する。或るスレッドの実際の実行命令数が目標値に 達してなければ、そのスレッドの命令のフェッチまたは発行の頻度が増えるように、上 述した優先度による資源競合調停の制御をフィードバック制御により修正する。例え ば、或るスレッドの命令のフェッチまたは発行の頻度を増加させるために、そのスレツ ドより下位優先度のスレッドのフェッチまたは発行が抑制される。逆に、例えば、或る スレッドの命令のフェッチまたは発行の頻度を低下させるために、そのスレッドより下 位優先度のスレッドのフェッチまたは発行が促進される。
[0027] 以下、図 2を参照しつつ、プロセッサ 10のより具体的な構成と機能、とりわけ、優先 度による調停機能と IPC制御機能に関わる部分に重点をおいて説明する。
[0028] 発行ユニット 12は、スレッドコントロールユニット 20、同時処理可能なスレッドの最大 数分(例えば 8つ)の PC (プログラムカウンタ)コントロールユニット 22、フェッチスレッド セレクタ 24、命令デコーダ 26、命令アナライザ 28、命令バッファ 30、命令発行セレク タ 32、リネームレジスタ 34、同時処理可能なスレッドの最大数分(例えば 8つ)のレジ スタファイル 36、およびリオーダバッファ 40を有する。キャッシュユニット 14は、命令 M MU (メモリマネジメントユニット) 42、命令キャッシュ 44、命令ヴィクティムキャッシュ 46 、命令ウェイトバッファ 48、データ MMU50、データリード Zライトバッファ 52、データキ ャッシュ 54、データヴィクティムバッファ 56およびデータウェイトバッファ 58を有する。 実行ユニット 16は、所定の複数個(例えば 5つ)のリザべーシヨンステーション 60と各 種の演算資源 62— 80を有する。演算資源 62— 80には、メモリアクセスユニット 62、 複数のブランチユニット 64、整数除算器 66、複数の整数演算ユニット 68、 FP (浮動 小数点)除算器 70、複数の FP演算ユニット 72、 64ビット整数演算ユニット 74、ベクタ 整数演算ユニット 78およびべクタ FP演算ユニット 80などがある。同時処理されるスレ ッドが同じ演算資源を同時に使おうとする可能性は低いので、リザべーシヨンステー シヨンの個数や各演算資源の個数は、同時処理可能なスレッドの最大数 (例えば 8つ )よりは少なぐ資源の無駄な冗長を避けている。
[0029] 以下では、命令が処理される流れにほぼ沿って、各部の機能と動作を説明する。
[0030] スレッドコントロールユニット 22は、複数スレッドの並列的な処理を制御するための コアとして働くユニットであり、その内部に複数のスレッドの優先度を記憶し保持し、そ して、その優先度をプロセッサ 10全体に配布する。ここで、スレッドコントロールュ-ッ ト 22に記憶され得る優先度のスレッド数は、好ましくは、このプロセッサ 10が内部に 保持し得るコンテキストのスレッドの最大数 (例えば 40)以上である。複数の PCコント ロールユニット 22は、プロセッサ 10内で同時処理され得る複数のスレッドにそれぞれ 割り当てられ、それぞれのスレッドからのプログラムカウンタの値をフェッチスレッドセ レクタ 24に与える。複数スレッド間の競合は、まず命令キャッシュアクセスにおいて生 じる。そこで、フェッチスレッドセレクタ 24は、命令キャッシュアクセスを要求しているス レッドの中から、各スレッドの優先度を用いて、一つのスレッドを選択し、選択されたス レッドのプログラムカウンタを命令 MMU (メモリマネジメントユニット) 42に送る。ここで、 フェッチスレッドセレクタ 24は、原則として命令キャッシュアクセスを要求して!/、るスレ ッドの中で最上位優先度をもつスレッドを選択する。しかし、常に最上位優先度のス レッドが選択されるわけではなぐ最上位優先度のスレッドの実行が圧迫されな ヽ所 定の状況下では、最上位優先度のスレッドに代えて下位優先度のスレッドが選択さ れる場合もある。
[0031] 命令 MMU42は、命令キャッシュ 44をアクセスして、上記選択されたスレッドの命令 を命令キャッシュ 44力も命令デコーダ 26に渡させる。ここで命令キャッシュミスが発生 した場合、外部のメモリ(図示省略)をアクセスしキャッシュラインを読み込む必要があ る。メモリアクセスはキャッシュアクセスに比べてレイテンシが大きいため、キャッシュミ スが続くと、命令ウェイトバッファ 48にて複数のメモリアクセス要求が待たされる。この 場合、命令ウェイトバッファ 48は、各スレッドの優先度に基づいて、原則として最上位 優先度のスレッドのメモリアクセス要求力 先に処理する。それにより、より上位の優 先度をもつスレッドの実行が優先される。しかし、常に優先度の高いスレッドのメモリ アクセス要求が優先されるわけではなぐ上位優先度のスレッドの実行が圧迫されな V、所定の状況下では、上位優先度のスレッドよりも下位優先度のスレッドのメモリァク セス要求が先に処理される場合もある。
[0032] 命令キャッシュ 44から命令デコーダ 26へ、複数(キャッシュの 1ライン分である例え ば 8つ)の命令が同時に送られる。命令デコーダ 26は、命令キャッシュ 44から同時に フェッチした複数命令を同時にデコードし、それら複数命令のデコード結果 (これも、 以下の説明では便宜上「命令」という)は同時に命令バッファ 40に入れられる。その 際、命令アナライザ 28が、同時デコードされた複数命令の命令タイプ(どのスレッドの 命令であるか、どの演算資源を使用するか、および命令間の依存関係はどうかなど の判断を行うために必要な、スレッド、オペコードおよびオペランドなどに関する情報 )を把握し、その命令タイプを命令発行セレクタ 32に与える。命令発行セレクタ 32は 、リオーダバッファ 40、リネームレジスタ 34およびリザべーシヨンステーション 60の空 きや、命令バッファ 30内の命令間の依存関係を調べ、その結果に基づいて、命令バ ッファ 30の中から、リザべーシヨンステーション 60に発行可能である命令を選択する 。所定数(同時処理可能なスレッド最大数より少な 、例えば 4つ)の命令が同時に命 令バッファ 30から発行され得る。その際、命令発行セレクタ 32は、命令バッファ 30内 に発行可能な命令が複数 (とりわけ、上記所定数 (4つ)より多く)ある場合、各スレッド の優先度に応じて、原則としてより上位の優先度をもつスレッドの命令力 先に発行 する。しかし、後述するように、上位優先度のスレッドの実行が圧迫されない所定の状 況下では、上位優先度のスレッドよりも下位の優先度のスレッドの命令が先に発行さ れる場合もある。
[0033] 各リザべーシヨンステーション 60に接続された整数演算ユニット 68や FP演算ュ-ッ ト 72等の各種の演算ユニットについても、スレッド間で競合が発生する。そこで、各リ ザべーシヨンステーション 60でも、各スレッドの優先度を用いた競合の調停が行なわ れる。各リザべーシヨンステーション 60は、そこで待機している命令を、演算に必要な オペランドがそろった命令力 順に、アウトォブオーダで演算ユニットに送る。その際 、各リザべーシヨンステーション 60は、複数の命令が同時に演算可能になった場合、 各スレッドの優先度に基づいて、原則として優先度の高いスレッドの命令力も先に演 算ユニットに送ることにより、優先度の高いスレッドの実行を優先する。しかし、常に優 先度の高 、スレッドの命令が優先されるわけではなぐ上位優先度のスレッドの実行 が圧迫されな 、所定の状況下では、上位優先度のスレッドに代えて下位の優先度の スレッドの命令が先に演算ユニットに送られる場合もある。
[0034] データキャッシュアクセスにおいても競合が発生する。そこで、データリード Zライト バッファ 52は、各スレッドの優先度に基づいて、原則として上位優先度のスレッドの データキャッシュアクセスカゝら先に実行することにより、上位優先度のスレッドの実行 を優先する。しかし、常に優先度の高いキャッシュアクセスが優先されるわけではなく 、上位優先度のスレッドの実行が圧迫されない所定の状況下では、上位優先度のス レッドに代えて下位の優先度のスレッドのキャッシュアクセスが先に処理される場合も ある。また、データキャッシュミスが起こった場合、外部のメモリ(図示省略)をアクセス しキャッシュラインを読み込む必要がある力 命令キャッシュの場合と同様に、データ ウェイトバッファ 58が、各スレッドの優先度に基づいて、原則として上位優先度のスレ ッドのメモリアクセス要求力も先に処理することにより、優先度の高いスレッドの実行を 優先する。しかし、ここでも、常に優先度の高いスレッドのメモリアクセスが優先される わけではなぐ上位優先度のスレッドの実行が圧迫されない所定の状況下では、上 位優先度のスレッドに代えて下位の優先度のスレッドのメモリアクセスが先に処理さ れる場合もある。 [0035] リオーダバッファ 40は、アウトォブオーダで実行された命令の実行結果を一時的に 保持し、インオーダで命令をコミットする。所定数(同時処理可能なスレッド最大数より 少ない例えば 4つ)の命令が同時にコミットされ得る。その際、リオーダバッファ 40は、 複数 (とりわけ、上記所定数 (4つ)より多く)の命令がコミット可能であれば、原則とし て上位優先度のスレッドの命令力 先にコミットする。しかし、ここでも、常に優先度の 高 、スレッドが優先されるわけではなぐ上位優先度のスレッドの実行が圧迫されな V、所定の状況下では、上位優先度のスレッドに代えて下位の優先度のスレッドが先 にコミットされる場合もある。
[0036] レジスタファイル 36は、同時処理され得るスレッド最大数 (例えば 8つ)だけ存在し、 それぞれ、同時処理される複数のスレッドに割り当てられる。各レジスタファイル 36に は、各スレッドのコンテキストが格納される。コンテキストキャッシュ 38は、より多くのス レッド数(例えば 32スレッド)分のコンテキストが格納できる。コンテキストキャッシュ 38 内の任意のスレッドのコンテキストと任意のレジスタファイル 36内のコンテキストとを高 速に交換することができる。従って、このプロセッサ 10では、レジスタファイル 36の数 (例えば 8つ)のスレッドがコンテキストスィッチを行うことなしに処理でき、コンテキスト キャッシュ 38がサポートするスレッド数(例えば 32個)のスレッドが、高速にコンテキス トスイッチを行うことができる。
[0037] 上述したように、プロセッサ 10内における命令のフェッチ、発行、実行およびコミット のステージにそれぞれ関わる諸ユニットにおいて、複数のスレッドの優先度を用いて 、スレッド間での資源競合を調停するための命令の処理順序または処理頻度の制御 が行われる。これにより、上位優先度のスレッドが優先的に実行され、かつ、上位優 先度のスレッドの性能を低下させないようにして下位優先度のスレッドも実行されるこ とになる。
[0038] さて、上記制御にカ卩えて、各スレッドの実行時間の予測を容易にするために、各ス レッドの IPCの変動を抑えてそれをできるだけ所望値の近傍に維持するための IPC制 御力 プロセッサ 10で行われる。上述したスレッドの優先度を用いた命令の処理順序 または処理頻度の制御力 この IPC制御により調整または修正される。この実施形態 では、スレッドコントロールユニット 20、フェッチスレッドセレクタ 24および命令発行セ レクタ 32が、この IPC制御に直接的に関与する。スレッドコントロールユニット 20は、 複数のスレッドの各々に予め割り当てられた実行命令数の目標値を記憶し保持する 。ここで、スレッドコントロールユニット 22に記憶され得る目標値のスレッド数は、好ま しくは、このプロセッサ 10が内部に保持し得るコンテキストのスレッドの最大数 (例え ば 40)以上である。スレッドコントロールユニット 20は、一定の監視周期毎(例えば、 数百クロックサイクル毎)にスレッド毎の実際の実行命令数 (IPC X 1監視周期中のク ロックサイクル数)をカウントし、カウントされた実行命令数と記憶されて ヽる目標値と を比較し、そして、その比較の結果に基づくフィードバック制御の方法で、フェッチス レッドセレクタ 24および命令発行セレクタ 32による各スレッドの命令フェッチと命令発 行の頻度を制御する。
[0039] 図 3は、この IPC制御を行なう機構の構成を示す。
[0040] 図 3において、ブロック 100は、プロセッサ 10内における上述された複数スレッドの 命令のパイプライン処理を行う機構を示し、そこでは、上述されたように、各スレッドの 優先度を用いて、スレッド間の資源競合の調停制御が行われる。 IPC制御機構は、実 行命令数監視部 102、比較部 104および制御関数部 106を有し、図 2に示されたス レッドコントロールユニット 20に組み込まれる。
[0041] 実行命令数監視部 102は、一定の監視周期毎に、並列処理されている複数スレツ ドの各々の実行命令数をカウントする。比較部 104は、スレッド毎に、カウントされた 実際の命令実行数と、予め記憶されている目標値とを比較する。後述するように、こ の実施形態では、後述するような状態遷移に従う制御を行う関係から、比較部 104は 、実際の命令実行数と目標値との比較だけでなぐ次のような比較も行なう。すなわち 、スレッド毎に、前回の監視周期において実際の実効命令数が実行されるべきであ つた命令数に足りなかった命令数 (繰越命令数)が計算され、その繰越命令数と目標 値とが加算されて繰越残値 (つまり、現在の監視周期で実行されるべきである命令数 )が計算され、その繰越残値と今回の実際の命令実行数とが比較される。
[0042] 制御関数部 106は、比較部 104による比較の結果に基づいて、所定のフィードバッ ク制御動作を行って、各スレッドの命令フェッチと命令発行の頻度を調節するための 操作値を決定し、その操作値をパイプライン処理機構 100に適用する。ここで、フィ ードバック制御動作には、 PD制御や PID制御などを用いることも可能である力 この 実施形態では、後に図 4を参照して説明されるような、状態遷移に従って操作値を制 御する制御動作が採用される。操作値としては、後に図 4を参照して説明されるような 、スレッド毎に用意されたインフレーション値というパラメータが採用される。
[0043] 制御関数部 106から出力されるスレッド毎のインフレーション値は、パイプライン処 理機構 100中の命令フェッチと命令発行の頻度を制御するユニット、すなわち、この 実施形態では図 2に示されたフェッチスレッドセレクタ 24および命令発行セレクタ 32 に与えられる。各スレッドのインフレーション値は、各スレッドの実行命令数と目標値 および繰越残値との比較結果に応じて、制御関数部 106により所定の可変レンジ内 で漸次的に増減される。インフレーション値が増加すると命令フェッチや命令発行の 頻度が増し、インフレーション値が低!、と命令フェッチや命令発行の頻度が減少する ように、フェッチスレッドセレクタ 24および命令発行セレクタ 32が、インフレーション値 に応じて、優先度を用いた制御動作を調整する。例えば、或るスレッドのインフレーシ ヨン値が増加すると、フェッチスレッドセレクタ 24および命令発行セレクタ 32は、それ ぞれ、そのスレッドより下位の優先度をもつスレッドの命令フェッチおよび命令発行の 頻度を抑制し、その結果、そのスレッドの命令フ ツチおよび命令発行の頻度が増え る。逆に、例えば、或るスレッドのインフレーション値が減少すると、フェッチスレッドセ レクタ 24および命令発行セレクタ 32は、それぞれ、そのスレッドより下位の優先度を もつスレッドの命令フェッチおよび命令発行の頻度を促進させ、その結果、そのスレツ ドの命令フ ツチおよび命令発行の頻度が低下する。
[0044] 上述した構成をもつ IPC制御機構は、それぞれのスレッドの IPCをある一定の監視 周期 PERIODで監視する。プログラマは、各スレッドの IPC目標値を ipcとして、「PERIO D X ipc」の値を、各スレッドの実行命令数の設定値として各スレッドの IPC設定レジス タに書き込む。 IPC制御機構は、いずれかのスレッドについて、設定値「PERIOD X ip cjが満たされて!/ヽな 、状態が続 、た場合、そのスレッドのインフレーション値を増加さ せる。
[0045] IPC制御機構は、スレッド毎に、以下の値を保持し、インフレーション値を制御する。
[0046] ipc.target: 実行命令数の設定値、つまり PERIOD X ipc; com.cnt: 今期実行命令数、すなわち現在の監視周期 PERIODで実際に実行され た命令数;
prev_com_cnt:前期実行命令数、すなわち一つ前の監視周期 PERIODで実際に実 行された命令数;
carryover:繰越命令数、すなわち現在の監視周期 PERIODで実行されるべき命令 数であり、この値が現在の監視周期 PERIODの終了時にゼロでなければ、この値は次 の監視周期 PERIODへと繰り越される;
stat.cnt:現在の状態 (後述する図 4に示される各状態)に留まっている監視周期 PE RIODの回数。
[0047] ここで、繰越命令数 carry_overの値は、監視周期 PERIOD毎に更新され、
carry— over = carry— over + ipe— target— com— cnt
というように決められる。すなわち、或る監視周期 PERIODにおいて繰越命令数 carry_ overで指定された数より少な 、数の命令しか実行できな力つた場合、不足命令数が 繰越命令数 carry_overとして次の監視周期 PERIOD繰り越され、それにより、次の監 視周期 PERIODにおける繰越総命令数 carryoverが増加する。逆に、或る監視周期 P ERIODにおいて繰越命令数 carryoverで指定された数より多くの命令が実行された 場合、次の監視周期 PERIODでは、繰越命令数 carry_overが減少する。なお、或る監 視周期 PERIODで今期実行命令数 com_cntが繰越命令数 carry_overを上回った場合 、その監視周期 PERIOD内では該当するスレッドの命令フェッチは行われなくなる。
[0048] IPC制御機構の制御関数部 106は、上述した値を用いて、図 4に示される状態遷移 を監視周期 PERIOD毎に行い、インフレーション値を制御する。その詳細は、以下の とおりである.
[0049] 図 4は、制御関数部 106の状態遷移とインフレーション値増減の動作を示す。
[0050] 制御関数部 106は、複数のスレッドのそれぞれについて並列的に、図 4に示された 動作を行う。
[0051] 図 4にお!/、て、「ノーマル」 110は、今期実行命令数 com_cntが設定値 ipc_targetを満 たしており、繰越命令数 carryoverも満たしている状態であり、換言すれば、そのスレ ッドの性能が保証されている状態である。今まで状態が「ノーマル」 110であったとこ ろ、現在の監視周期 PERIODで実行した命令数が設定値 ipC_targetの両方を満たせ な力つた場合、状態は「IPCフェイリング」 112に遷移し、他方、繰越命令数 carryover のみを満たせな力つた場合には、状態は「リクエストフェイリング」 114に遷移する。ま た、ある回数以上の監視周期にわたり「ノーマル」 110が続いた場合には、インフレ一 シヨン値が減少され、その結果、そのスレッドの命令フェッチおよび命令発行の頻度 が抑制される。
[0052] 「リクエストフェイリング」 114は、今期実行命令数 com_cntが設定値 ipc_targetを満た しているが、繰越命令数 carryoverを満たしていない状態である。つまり、短期的には IPC目標値が満たされている力 それ以前の監視周期 PERIODで IPC目標値が満たさ れな力つたために、不足命令を余分に実行しなくてはならない状態である。この状態 がある回数 REQ_FAIL_THRESH以上の監視周期にわたり続く場合、インフレーション 値が増加され、そして、状態は「リソースアップチヱック」 116に遷移する。他方、「リク エストフエイリング」 114において、現在の実行命令数が繰越残値を満たした場合は、 状態は「ノーマル」 110へ遷移する。
[0053] 「IPCフェイリング」 112は、今期実行命令数 com— cntが繰越命令数 carry— overと設定 値 ipC_targetを共に満たしていない状態である。つまり、短期的にも長期的にも IPC目 標値が満たされて 、な 、状態である。この状態がある回数 IPC_FAIL_THRESH以上の 監視周期にわたり続く場合、インフレーション値が増カロさせられ、状態は「リソースアツ プチエック」 116に遷移する。他方、「IPCフェイリング」 112において、繰越命令数 carr y_overと設定値 ip targetが共に満たされた場合は、状態は「ノーマル」 110に遷移す る。
[0054] 「リソースアップチェック」 116は、インフレーション値を増加させた後、インフレーショ ン値の増加に見合う IPCの向上があつたかどうかをチェックするための状態である。こ の状態にぉ 、て、前期実行命令数 prev_com_cntと比較した今期実行命令数 com_cnt の増分が、予め設定された閾値 EFFICIENT_THRESH以上である力 まだ繰越命令 数 carry_overが満たされていない場合は、インフレーション値がさらに増加される。他 方、繰越命令数 carryoverが満たされた場合は、状態は「ノーマル」 110に遷移する。 また、「リソースアップチェック」 116において、上記増分が上記閾値 EFFICIENT_THR ESH未満である場合は、インフレーション値は減少させられ、状態は「リソースダウン」 118に遷移する。
[0055] 「リソースダウン」 118は、インフレーション値の増加に見合った IPCの向上が認めら れな力つた場合に相当する状態である。この状態に入ると、インフレーション値が減 少させられ、状態は「リソースダウンチヱック」 120に遷移する。
[0056] 「リソースダウンチェック」 120は、インフレーション値を減少させた後、 IPCが大幅に 低下していないかどうかをチェックするための状態である。この状態において、前期 実行命令数 prev_com_cntと比較して、今期実行命令数 com_cntの予め設定された閾 値以上に低下した場合、インフレーション値は一周期前の値に戻される。そうでない 場合は、インフレーション値は現在の値に維持される。状態は「ノーマル」 110、「IPC フェイリング」 112または「リクエストフェイリング」 114に遷移する。状態が「ノーマル」 1 10と「IPCフェイリング」 112と「リクエストフェイリング」 114の!、ずれに遷移するかは、 今期実行命令数 com_cntと設定値 ipc_targetおよび繰越命令数 carry_overとの比較結 果により決まる。
[0057] 以上のように、各スレッドについて、 IPCが所望値を満たせていない状態が続くと、ィ ンフレーシヨン値が増加させられる。ただし、インフレーション値を増加した場合であ つても、その増加に見合った IPCの向上が得られない場合は、インフレーション値を 元に戻す。その理由は、プログラムの最大性能が時間と共に変化することに対応する ためである。すなわち、プログラムの IPCは時間と共に変化するため,ある監視周期 P ERIODでは IPC目標値を満たせない場合がある。そのような場合にインフレーション 値を増加させても無意味であり、他スレッドの実行が阻害されるだけである。そこで、 インフレーション値を増加させてもその増加に見合った IPCの向上が生じない場合に は、将来の監視周期 PERIODで取り返しがっくことが期待できるので、インフレーショ ン値の増加を取り消す。不足命令数は繰越命令数 carry_0Verに加算される。将来プ ログラムの IPCが向上しやすくなつた時点でインフレーション値を増加させることで、そ の不足命令数が解消されることになる。
[0058] 上記の IPC制御により、性能の変動が激しいプログラムにおいても、他スレッドの実 行を著しく阻害することなぐ特定のスレッドの性能を制御することができる。各スレツ ドの IPCが所望値近くに制御されることになるので、各スレッドの実行時間の予測の精 度が向上する。その結果、実時間処理において、複数スレッドを並列に実行していて も時間制約を守ることができるようなスケジューリングが容易になる。
[0059] 図 5は、上述した優先度による調停を行なうマルチスレッドプロセッサを用いて実時 間処理を行った場合の例を示す。なお、図 5の例では、説明の都合上、上述したプロ セッサ 10のような複数スレッドを同時処理できる SMTプロセッサではなぐ同時処理で きるスレッドは 1つのみであるシングルパイプラインのマルチスレッドプロセッサを用い た場合であって、理想的な実行 (キャッシュミスや分岐予測ミスが発生しな ヽ)の場合 を想定する。
[0060] 図 5に示される例では、スレッド #0の優先度が最も高ぐスレッド #7の優先度が最も 低いとする。この例では、最初にスレッド #1、スレッド #2およびスレッド #3が実行可能 になる。ここで、優先度による資源の調停を行なわない従来のマルチスレッドプロセッ サでは、スレッド #1、スレッド #2およびスレッド #3が並列的に実行されることになる。こ れに対し、優先度による資源の調停を行なうマルチスレッドプロセッサでは、優先度 による演算資源の調停により、原則として、最も優先度の高いスレッド #1の実行が優 先される。そのためスレッド #1が先に実行される。スレッド #1の実行が完了すると、優 先度による調停により、次に優先度の高いスレッド #2が優先的に実行される。このとき 、スレッド #2のコンテキストがプロセッサ内に保持されているため、スレッド #2はコンテ キストスイッチを行うことなく直ちに実行される。スレッド #4の実行中に、より優先度の 高いスレッド #0が実行可能になった場合においても、優先度による演算資源の調停 によりスレッド #0の実行が優先される。このときも、スレッド #0はコンテキストスィッチを 行うことなく直ちに実行される。スレッド #0の実行が完了すると、次にスレッド #4に演算 資源が割り当てられて、スレッド #4が直ちに実行を再開する。
[0061] マルチスレッドプロセッサは、一般に 1つのスレッドがキャッシュミスなどでストールし ている場合でも、別のスレッドを実行することにより、プロセッサ全体のスループットを 高く維持できる。この側面に関して、本発明に従うマルチスレッドプロセッサでは、優 先度の高いスレッドがストールした場合、次に優先度の高いスレッドを実行するように 、優先度による調停を行うことができ、それにより、スループットを向上することが可能 である。
[0062] 図 6は、優先度による調停と共に IPC制御を行なうマルチスレッドプロセッサより複数 スレッドの同時実行を行った場合の例を示す。図 6の例は、同時処理できるスレッドが 1つのみのシングルパイプラインのマルチスレッドプロセッサの実際の実行 (キャッシュ ミスや分岐予測ミスが発生する)場合を示して ヽる。
[0063] 図 6に示した例でも、図 5に示した例と同様に、スレッド #0の優先度が最も高ぐスレ ッド #7の優先度が最も低ぐ最初にスレッド #1、スレッド #2およびスレッド #3が実行可 能になる。優先度による演算資源の調停により、実行可能なスレッド #1、スレッド #2お よびスレッド #3中で最も優先度の高いスレッド #1の実行が優先される。上述の図 5に 例示された理想的な実行の場合、キャッシュミスや分岐予測ミスが発生しな 、ため、 優先度に従って順番にスレッドが実行される。この理想的な場合では、スレッド間の 干渉がないため、 IPCの変化はない。これに対し、図 6に例示される実際の実行の場 合、キャッシュミスや分岐予測ミスなどが発生することがある。例えばスレッド #1がこの 種のミスでストールすると、次に優先度の高いスレッド #2が実行される。スレッド #2のコ ンテキストはプロセッサ内に保持されているため、コンテキストスィッチを行うことなく直 ちにスレッド #2を実行することができる。このため、見かけ上「スレッド #1とスレッド #2が (或いは、より多くのスレッドカ 同時並列的に実行される」ことになる。スレッド #2は演 算資源を使用するため、優先度のより高いスレッド #1の実行時間に影響を与える。そ のため、スレッド間の干渉が発生し、 IPCの変化が発生する。 IPC制御を採用しない場 合には、スレッド #1の時間予測精度が低下する。これに対して、 IPC制御を採用する ことにより、同時に実行されている各スレッド #1、 #2の実行命令数 (IPC)をそれぞれの 目標値に近づけるように、各スレッド #1、 #2の実行の頻度が制御される。よって、複数 スレッドを同時実行した場合でも、時間予測精度の低下は小さい。そのため、時間制 約を守りつつ、プロセッサ全体のスループットを向上することが可能となる。
[0064] 図 5と図 6は、理解を容易にするするために、シングルパイプラインのプロセッサの 場合を例示した。しかし、同様の説明は、図 2に示したような複数のスレッドを同時処 理できる SMTプロセッサにも適用される。図 7は、図 2に示した 4パイプラインをもち優 先度による調停と共に IPC制御を行なう SMTプロセッサより複数スレッドの同時実行( 実際の実行)を行った場合の例を示す。
[0065] 図 7に示すように、マルチパイプラインの SMTプロセッサでは、より多くの数のスレツ ドカ 見かけ上、同時並列的に実行される。同時並列的に実行されるスレッドの数が 多いほど、スレッド間の資源の競合が発生する頻度が多くなり、各スレッドについての 時間予測精度がより低下する。故に、 IPC制御の採用による時間予測精度の低下を 抑制できる利点は大きい。
[0066] さて、以下では、図 2に示した SMTアーキテクチャを採用したプロセッサ 10における 、優先度による資源調停と IPC制御のより具体的で詳細な制御方法を説明する。
[0067] まず、優先度による資源調停の制御方法を説明する。
[0068] この制御は、複数のスレッドを同時に実行する場合における、命令フェッチスロット、 命令発行スロット、演算ユニットなどの各演算資源におけるスレッド間の競合を調停し 解決するものである。そこでは、スケジューラが付与した優先度を、スレッド間の競合 解決のために使用する。プロセッサ 10内で生じるスレッド間の競合解決に優先度を 用いることで、優先度の低!、スレッドが優先度の高 、スレッドの実行を阻害することを 防ぎ、優先度の高いスレッドの実行を保証する。ただし、優先度を単純に全ての競合 処理に導入すると、システム全体の性能が低下してしまい、マルチスレッドによるレイ テンシの隠蔽の効果を得ることができない。そこで、優先度の高いスレッドの性能を低 下させずに、優先度の低いスレッドを実行する機構が採用される。 SMTァーキテクチ ャは、スーパースカラアーキテクチャを採用するので、単一スレッドの性能が通常のシ ングルパイプラインと比較して高い。ただし、単一スレッドの性能をできるだけ高くする には、実行資源をスレッド間で共有ィ匕し、全ての実行資源を一つのスレッドが利用で きるようにする必要がある。実行資源を共有化すると、単一のスレッドの性能の向上が 期待できるが、スレッド間で性能に影響を与えやすくなるので、優先度の低いスレッド が優先度の高いスレッドの性能に悪影響を与えてしまう。その対策として、フェッチス ロットや発行スロットといったスロットの優先度制御に加え、共有資源の占有率の制御 も実装することができる。また、フェッチスレッド選択でのボトルネックをできるだけ回 避し、命令供給機構全体を制御するような制御方法が採用される。その際、ソフトリア ルタイムタスクとハードリアルタイムタスクの性質の違いに着目し、単一スレッドの性能 に大きく比重を置く制御方法と、単一スレッドの性能の低下を抑制しつつ全体の性能 に比重を置く制御方法とを実装することができる。
[0069] フェッチスレッド選択では、最上位優先度スレッドの性能低下をできるだけ抑制しつ つ、他のスレッドのフェッチを行うことができる制御方法を採用することができる。最上 位優先度スレッドの性能低下をできるだけ抑えることに主眼を置く場合、所定の状況 下で最上位優先度スレッドにより無駄にされる(使用されない)スロットを、他の下位優 先度スレッドが使用することで、ある程度のシステム全体の性能向上が期待できる。 そのような制御方法として次のものを挙げることができる。
[0070] (1) 命令フェッチでのキャッシュミス
キャッシュミスした後に同じスレッドが命令フェッチを行うことはハードウェアを不必要 に複雑化するのみである。キャッシュから命令が返ってくるまでは他のスレッドがフエ ツチを行う。
[0071] (2) 分岐予測ミス力 の回復
分岐予測ミスによるパイプライン中の命令の破棄はその分岐命令のコミット時に行 われる。分岐命令がライトバックされたときにはその予測の成否がわ力るので、もし予 測ミスして 、た場合にはそれ以後のフェッチは無駄になる。そこでライトバックした分 岐命令が予測ミスしていた場合には、その命令がコミットするまで他のスレッドカもフ エッチを行う。
[0072] (3) 命令バッファ中の命令数
最上位優先度スレッドの性能を落さな 、ためには、実行機構への発行を可能な限り 絶やさない必要がある。そのためには、命令バッファ中に常に命令が格納されている 必要がある。図 2に示したプロセッサ 10の場合、命令発行まで 5ステージあるので、ス レッド選択の際に最上位優先度スレッドの命令が命令バッファ 30内に 6クロック分あ れば、そのクロックに他のスレッドからフェッチを行ったとしても命令バッファ中の命令 が不足することはない。 4命令の同時発行のため、 24命令が命令バッファ 30内に存 在する場合に、優先度の低いスレッドからフ ツチを行う。ただし次に最上位優先度 スレッドがフェッチした命令中にいくつの有効な命令があるかはこの時点では不明で あるのにカ卩え、次の命令フェッチがキャッシュミスを起こす可能性があるので、それを 考慮にいれると、さらに命令数を増やした方が性能の低下は防げる。
[0073] 以上の 3つの制御方法は、最上位優先度スレッドが無駄にするスロットを使用して 下位優先度スレッドの命令を格納するという方法である。それに対し、優先度の高い スレッドが実行資源を非効率的に使うと予測して、優先度の低いスレッドのフ ツチを 行うという制御方法も採用し得る。その例を以下に挙げる。
[0074] (1) パイプライン中の条件分岐命令数
条件分岐命令を多く実行するほど分岐予測ミスの可能性が高くなり、実行資源を無 駄にする可能性が高くなる。そのため、パイプライン中の条件分岐命令の数が閾値を 越えた場合に優先度の低いスレッドからフェッチを行う。
[0075] (2) パイプライン中の命令数
ノ ィプライン中に命令数が多くなると、それが依存するデータを待つ命令が多くなり 、実行スロットを埋めることが難しくなる。特に単一のスレッドの命令数が多くなつたと きに、この現象は顕著になる。そのため、ノ ィプライン中の命令数が閾値を越えた場 合に優先度の低 、スレッド力もフ ツチを行う。
[0076] (3) 命令バッファ中の命令数
前述した制御方法では、常に最大限命令が発行されると仮定したが、リザべーショ ンステーション 60などの問題で最大限命令を発行できないことがある。そこで、閾値 を上述した 24命令よりも低く設定する。閾値が低い程、優先度の高いスレッドの性能 が落ちると考えられる。
[0077] (4) フェッチ制御ユニット内の占めているステージ数
デコード時に用いられる分岐予測器と比較して、 BTB (Branch Target Buffer: 分岐 ターゲットバッファ、図示省略)は分岐命令があるかどうかという情報がない分、予測 精度が大きく劣る。そのため、 BTBによる投機フェッチ数を制限する。フェッチ制御パ ィプライン中のステージ数によって制御することで、連続するフェッチ回数を抑える。
[0078] (5) リザべーシヨンステーション内の待ち命令数
使われる実行ユニットに偏りがある場合や、命令間に強い依存関係がある場合、パ ィプライン中の命令数による制御ではリザべーシヨンステーション 60を一杯にしてしま う可能性がある。そこで、リザべーシヨンステーション 60内の命令数を数え、閾値を越 えた場合に優先度の低いスレッド力 フェッチを行う。
[0079] 以上の 5つの制御方法は、システム全体の性能を向上させることを重視している。
[0080] さて、発行命令選択では、命令実行ユニット 16に直接命令を供給するために、命 令フェッチ機構力 十分な命令が来ている場合には、スレッドの性能に大きな影響を 及ぼすと考えられる。そこで、優先度の高いスレッドの性能の低下を抑制するために 、命令発行機構では発行できる限り優先度の高いスレッドの命令を発行する。優先 度による発行命令選択ではフェッチスレッド選択と同様に、次のような方法で優先度 の低 、スレッドの命令を発行する。
[0081] (1) 対象のリザべーシヨンステーションが一杯の場合
優先度の低いスレッドの命令に他のリザべーシヨンステーションを利用する命令が 含まれて!/、る場合はその命令を発行する。
[0082] (2) リオーダバッファやリネームレジスタが一杯の場合
これらの実行資源をスレッド毎に所持している場合は他のスレッドの命令を発行す る。
[0083] (3) 投機実行が禁止されている命令の場合
コントロールレジスタへの書き込み命令のように、投機実行が禁止されて 、る命令 の場合はその命令より前の命令が全てコミットされない限り命令発行を止める。
[0084] (4) 分岐予測ミス力 の回復の場合
フェッチスレッド選択と同様に、ライトバックされた分岐命令が予測ミスをして 、た場 合にその命令がコミットするまで命令発行を止める。
[0085] 対象のリザべーシヨンステーション 60がー杯の場合は、優先度の高いスレッドと低 V、スレッドの利用するユニットがそれぞれ偏って 、てなおかつ異なる場合でな 、限り 、優先度の低いスレッドから多くの命令を発行できるわけではない。また、リオーダバ ッファ 40やリネームレジスタ 34をスレッド間で共有する構成にした場合には、優先度 の低いスレッドからの命令発行は行うことが出来なぐ投機実行が禁止されている命 令は通常のプログラムにおいては頻度が低い。つまり、キャッシュミスが起こり得るフエ ツチスレッド選択と比較して、優先度の低 、スレッドの命令が発行される可能性が低 い。複数スレッドの並列実行によるレイテンシの隠蔽には、更なる制御方法が採用さ れる。さらに、システム全体の性能に重きを置き、次のパラメータ、
•パイプライン中の条件分岐命令数
•パイプライン中の命令数
•リザべーシヨンステーション内の待ち命令数 を参照して優先度の高!、スレッドの命令発行を止める。
[0086] 以上、命令フェッチ、発行といったパイプライン中のスロットに関する競合を解決す る制御方法について述べた。それに加え、 SMTアーキテクチャでは複数スレッドで実 行資源が共有されるため、その競合制御についても考慮にいれる必要がある。ここで いう実行資源とは、典型的には、
•命令バッファ 30
'リネームレジスタ 34
'リオーダバッファ 40
などを指す。これらの実行資源は、スレッドごとに用意されるか、または共有化される かの 2通りの実装方法がある。
[0087] 実行資源力スレッドごとに用意される場合、スレッド間の影響を低く抑えることが可 能である。或るスレッドがストールしても、他のスレッドは容易に実行できる。しかし、一 つのスレッドが使える量が小さく抑えられるので、単一のスレッドの性能が低くなる。 一方、実行資源力 Sスレッド間で共有された場合、単一のスレッドを優先して実行した 場合に、実行資源を十分に利用できるので性能が高くなる。しかしスレッド間の影響 が大きくなるため、低い優先度のスレッドが高い優先度のスレッドを阻害してしまう。ま たスレッドがストールしたときに他のスレッドが実行できないことがある。
[0088] このようにスレッド間の影響を考えると、スレッド毎に実行資源を用意する方法の方 が好ましいが、チップサイズの制限があるのでスレッドあたりの資源の量は小さく抑え られてしまう。そのため、優先度の高いスレッドの性能が低くなるので、ソフトリアルタイ ム処理に耐え得る高い性能という面で問題がある。そこで、図 2に示されたプロセッサ 10では、実行資源を共有ィ匕することで、単一のスレッドの性能向上を目指す。
[0089] 各バッファをパーティション化 (幾つかの単位に分割)することにより、ハードウェアの 複雑化を防ぐことができる。一つのパーティションを単一のスレッドのみが使用するよ うに設計することで、スレッドごとにパーティションの使用順番とパーティション内の現 在位置だけ記憶しておけば良 、ので、ハードウェアが単純になる。
[0090] 各バッファを共有することで、優先度の低いスレッドがバッファを占有することにより 優先度の高いスレッドの実行を阻害してしまう。そこで、共有バッファにおけるスレッド 間の性能に対する影響を抑えるために、各スレッドが使用できるノ ッファのエントリ数 をソフトウェアによりパーティション単位で設定する。これに関し、次の 2通りの制御方 法が採用できる。
[0091] (1) 資源予約
制御レジスタを用いてスレッド毎にパーティション使用権を設定する。同じパーティ シヨンを複数のスレッドが利用することができる。
[0092] (2) 最大数設定
制御レジスタを用いてスレッド毎に使用できる最大のパーティション数を設定する。
[0093] 資源予約方式では、スレッド毎に利用できる資源を個別に指定できるので、安定し た性能が期待できるが、周期タスクが実行を終え、次の周期を待っている場合など、 スレッドが実行できない場合に対応がしづらぐ実行資源を有効に使うことができない 。最大数設定方式では、他のスロットの制御を優先度制御で行っているために、優先 度の高いスレッドから指定された最大限の量まで実行資源を利用することができ、状 況に応じて最大限に実行資源を利用しやすい。ただし、各スレッドの最大数の合計 がパーティション総数を上回っている場合には、優先度の低いスレッドが優先度の高 いスレッドの実行を阻害してしまう。資源予約方式は静的に性能の予測ができ、最大 数設定方式は、動的に実行資源の利用の効率ィ匕を計ることができる。しかし、これら の制御方法のみでは最上位優先度スレッドの性能を維持することは難 、。例えば 優先度の高 、スレッドがスケジューリング可能な状態になり、最上位優先度スレッドが 切り替わる場合には、それまで実行されて ヽた優先度の低 ヽスレッドが実行資源を占 有しており、優先度の高いスレッドの実行が阻害されてしまう。そこで、優先度の高い スレッドの命令が格納されているパーティションの数が閾値以下で、空きパーティショ ンがな 、場合に、現在その資源を利用して 、るスレッドの中から最も優先度の低 、ス レッドの命令を破棄する。命令バッファ 30の場合ではそのスレッドの先頭の命令から フェッチし直し、リオーダバッファ 40では分岐予測ミスの場合と同様の機構を用いて ノ ィプライン中の命令を破棄する。
[0094] SMTアーキテクチャでは、優先度による制御を行っていても、同時に実行されるスレ ッドによっては最上位優先度の実行に影響を与える場合がある。そこで、プロセッサ の性能の予測性、及び全体スループットの改善のために、各スレッドがその優先度に 従った量のプロセッサ資源を割り当てるように制御することができる。例えば、命令フ エッチに関しては、命令バッファの各スレッドへの割当量を、各スレッドの優先度に従 うように制御することができる。これにより下位優先度スレッドがフェッチ権を獲得しや すくなるため、最上位優先度スレッドの性能が多少低下する可能性がある力 性能の 変動は小さくなり、予測性が高まるものと考えられる。また、命令バッファの利用効率 の改善により全体性能の向上が期待できる。
[0095] 命令フ ツチに関するこの制御について、以下に具体的に述べる。この制御は、図
2に示されたプロセッサ 10内の主としてフェッチスレッドセレクタ 24によって実行され る。この制御は、各スレッドの命令バッファの占有量を監視し、より下位の優先度のス レッドの占有量力 より上位の優先度のスレッドの占有量を超えると、その下位優先 度のスレッド力もの命令フェッチを抑制または禁止するものである。以後の説明には 以下の記号を用いる。
[0096] Ti:スレッド;
Gj:同じ優先度を与えられたスレッドのグループ。グループ間の優先度は Gj > G卜 1 であるとする;
ThOlMinlQ(Gj):グループ Gj中で命令バッファ占有数が最小のスレッド; THNUM(Gj):グループ Gjに属するスレッド Tiの数;
IQSUM(Gj):グループ Gjが占有する命令バッファ数(グループ Gjに属するスレッドの 命令バッファ占有数の合計);
MINIQ(Gj):グループ Gjが占有する命令バッファ数の最小値;
MIN_IQ_THRESH: 1スレッド当りの命令バッファ占有数に対する所定の下限値; FREQj:グループ Gjのフェッチ要求;
FETCHj:フェッチ要求 FREQjが認められた場合にフェッチを行なうスレッド(フェツ チスレッド)。
[0097] フェッチ要求 FREQjとフェッチスレッド FETCHjは、以下のような制御条件 (1)および(
2)に従って決められる。
FREQj =
MINIQ(Gj)≤ IQSUM(Gj-l)
or
IQSUM(Gj)≤MINJQ— THRESH X THNUM(Gj) … 制御条件 (1)
FETCHj = ThOlMinlQ (Gj) … 制御条件 (2)
ここで、値 MINJQ_THRESHは、各スレッドの命令バッファが空になる頻度を低くする ことを目的とした下限値である。各スレッドの命令バッファ占有数力この下限値 MINJ Q_THRESHを下回ると、各スレッドは無条件にフェッチ要求を出すことができる。この 値 MINJQ_THRESHは以下の条件値、
• 1回のフェッチでフェッチされる命令数
•フ ツチ開始力 命令発行までに要する最短サイクル数
• 1サイクルの最大命令発行数
によって決めることができる。例えば図 2に示されたプロセッサ 10では、 1サイクルで 8 つの命令がフェッチされ、フェッチ開始力 命令発行まで 6サイクルを要し、 1サイクル で 4命令が発行される。そのため、命令バッファの命令数が 24になった時点でフェツ チを開始することで、命令供給が途絶える頻度を減らすことができると考えられる。そ こで、値 MINJQ_THRESHとして「24」を採用することができる。
[0098] 制御条件 (1)によれば、或るグループ Gjの命令バッファ占有数の最小値 MINIQ(Gj)
1S それより 1ランク優先度の低 、グループ G卜 1の命令バッファ占有数 IQSUM(G卜 1) と同等力 り少ないときには、または、或るグループ Gjの命令バッファ占有数 IQSUM( Gj)力 そのグループ Gjにより占有されるべき命令バッファ数の下限値 MINJQ_THRE SH X THNUM(Gj)と同等かより少ないときには、そのグループ Gjのフェッチ要求 FRE Qjは認められる力 より優先度の低いグループ G卜 1のフェッチ要求 FREQ卜 1は認め られない。そして、制御条件 (2)によれば、そのグループ Gjのフェッチ要求 FREQjが 認められる場合、そのグループ Gj中で命令バッファ占有数が最小であるスレッド ThO IMinlQ (Gj)に、フェッチ権が与えられる。
[0099] 以上により、 FETCHj、 FREQjが決定される力 プロセッサ 10では、 1サイクルで 1 つのスレッドのみがフェッチを行うため、複数のフェッチ要求から 1つのスレッドを選択 しなければならない。そこで、最上位優先度スレッドの実行を優先するために、最上 位優先度のグループのフェッチ要求を選択し、フェッチスレッドを決定するような制御 方法が採用できる。また、フェッチスレッドとして選択されたスレッドがキャッシュミス等 を起こしフェッチを行えな 、場合であっても、下位優先度のスレッドにフェッチ権を譲 ることはないようにしてもよい。これは、資源占有量の逆転を防ぎ下位優先度スレッド が上位優先度スレッドの性能を圧迫しな 、ようにするためである。
[0100] この制御方法では、一方において、下位優先度スレッドがフェッチ権を得やすくな つており、プロセッサの全体性能が向上すると考えられる。そして、他方において、プ ログラムの特性によらず高優先度スレッドほど多くの命令バッファを獲得できるように 制御されており、低優先度スレッドに多くの命令バッファが割かれる問題や、長期間 命令バッファが占有される問題は生じにくいと考えられる。この利点は、後述の命令 発行の制御方法との組み合わせにより、より強化される。また、この制御方法では、同 じ優先度のスレッドが複数あった場合には、それらの中で最も命令バッファ占有数が 少な 、スレッドからフェッチを行う。
[0101] 次に命令発行の制御方法について述べる。
[0102] 命令フ ツチの制御と同様に、資源の占有量が優先度に従うように、それぞれのス レッドの命令発行が制御される。この命令発行の制御は、図 2に示されたプロセッサ 1 0内の例えば命令発行セレクタ 32によって実行される。この命令発行の制御では、監 視対象の資源として、リザべーシヨンステーションまたはリオーダバッファを採用するこ とができる。以下に説明する制御では、リザべーシヨンステーションのスレッド毎の占 有量が監視され、より下位の優先度のスレッドの占有量力 より上位の優先度のスレ ッドの占有量を超えると、その下位優先度のスレッドからの命令発行が抑制または禁 止される。以降の説明では以下の記号を用いる。
[0103] Tj,k:グループ Gjに属するスレッド;
RSNUM(Tj,k):スレッド Ti,kのリザべーシヨンステーション占有数; RSSUM(Gj.):グループ Gjのリザべーシヨンステーション占有数(グループ Gjに属する スレッドのリザべーシヨンステーション占有数の合計);
IREQj.k:スレッド Tj,kの命令発行要求。
[0104] 命令発行要求 IREQj,kは以下のような制御条件 (3)に従って決められる。
IREQj.k = RSNUM(Tj,k)≤ RSSUM(Gj-l) … 制御条件 (3)
[0105] 制御条件 (3)によれば、或るスレッド Tj,kのリザべーシヨンステーション占有数 RSNU M(Tj,k)が、それより 1ランク優先度の低 、グループ Gj-1のリザべーシヨンステーション 占有数と同等かそれより少ないときには、そのスレッド Tj,kの命令発行要求 IREQj,kは 認められるが、その優先度の低!、グループの命令発行要求 IREQ卜 l,kは認められな い。ここで、図 2に示されたプロセッサ 10では、 1サイクルで最大で 4つのスレッドが命 令を発行し得る。命令フェッチと異なり、同じグループの複数のスレッドから命令発行 要求が来る場合がある。そこで、命令発行の制御では、命令発行要求を出しているス レッドを以下のように順位付けし、その順位の上位 4つのスレッドを発行スレッドとする
[0106] ·スレッドに与えられた優先度の高い順
•同じ優先度(グループ)のスレッド間では、リザべーシヨンステーション 60の占有数 が少ない順
[0107] 命令発行の制御方法は、前述の命令フ ツチのそれとよく似たものである。相違点 は、命令バッファ 30の占有数の代わりにリザべーシヨンステーション 60の占有数を用 いる点と、占有数の下限値 MINJQ_THRESHに対応する条件が無い点である。発行 スレッド選択の基準にリザべーシヨンステーション 60を用いる理由は次の通りである。 すなわち、発行スレッドとして選択されたスレッドが実際には発行できない場合が存 在する。これは主に次のような場合である。
[0108] 'リオーダバッファ 40に空きがない
•リネームバッファ 34に空きがな!ヽ
'発行先の実行ユニットのリザべーシヨンステーション 60に空きがない
プロセッサ 10では、リオーダバッファ 40とリネームバッファ 34は連動しており、実際 に制約となるのはリオーダバッファ 40力リザべーシヨンステーション 60である。このう ち、実際上は、リザべーシヨンステーション 60に空きがなく命令発行が行えない場合 が多い。そのため、上記の制御条件 (3)では、より貴重な資源を高優先度スレッドに割 り当てるためスレッド選択の基準にリザべーシヨンステーション 60の占有数が用いら れる。実際、発明者が実施した評価試験によっても、リオーダバッファ 40よりリザべ一 シヨンステーション 60の方力 より影響的であることがわかった。
[0109] 次に、 IPC制御の具体的方法を説明する。
[0110] リアルタイム処理においてはタスクの実行時間の予測性が重要である。そこで、前 述の命令フ ツチ、命令発行機構に IPCを制御する機構を加えられる。 IPC制御では 、一定の間隔で各スレッドの実行命令数を監視し、それが指定された目標値に満た ない場合には命令フェッチ、発行が行われる頻度を高くする。また、プログラムの性 能は時間とともに大きく変化することがあり、以下に説明する IPC制御ではその点につ いても考慮される。
[0111] この IPC制御では、グループ Gjの現在の IPCに応じて変化するインフレーション値 IN FLjが導入され、前述の命令フ ツチ、発行の制御条件 (1)と (3)が以下の制御条件 (4) と (5)のように変更される。
FREQj =
MINIQ(Gj)≤ IQSUM(Gj-l) + INFLj X THNUM(Gj)
or
IQSUM(Gj)≤ MINJQ— THRESH X THNUM(Gj) … 制御条件 (4)
IREQj.k = RSNUM(Tj,k)≤ RSSUM(Gj-l) +INFLj … 制御条件 (5) ここで、既に図 4を参照して説明したように、インフレーション値 INFLjは、所定の値 範囲、例えば 0≤ INFLj≤ 32の範囲で、グループ Gjの現在の性能によって増減さ れる。すなわち、グループ Gjが指定された IPCを得られていない場合には、インフレ ーシヨン値 INFLjが増加し、それにより、グループ Gjより優先度が下位のスレッドのフエ ツチと発行が抑制され、グループ Gjのスレッドの性能を上昇させる。インフレーション 値 INFLjの可変範囲が 0から 32であるのは、図 2に示されたプロセッサ 10では命令バ ッファ 30およびリザべーシヨンステーション 60が 32エントリをもつことに基づいている 以上、本発明の実施形態を説明したが、この実施形態は本発明の説明のための例 示にすぎず、本発明の範囲をこの実施形態にのみ限定する趣旨ではない。本発明 は、その要旨を逸脱することなぐその他の様々な態様でも実施することができる。

Claims

請求の範囲
[1] 複数のスレッドを並列的に処理するマルチスレッド中央演算装置において、
各スレッドの優先度を記憶する優先度記憶手段と、
前記各スレッドの優先度を用いて、前記複数のスレッドの命令の処理の順序または 頻度を制御する第 1の制御手段と、
各スレッドの命令実行目標を記憶する目標記憶手段と、
前記各スレッドの命令実行状態を監視し、前記実行命令状況と前記命令実行目標 を用いたフィードバック制御動作により、前記複数のスレッドの命令の処理の順序ま たは頻度を制御する第 2の制御手段と
を備えたマルチスレッド中央演算装置。
[2] 請求項 1記載の装置において、
前記第 1の制御手段が、前記装置内の所定の資源の前記複数のスレッドへの割当 量を監視し、前記複数のスレッドへの割当量が前記複数のスレッドの優先度に従うよ うに、前記複数のスレッドの命令のフェッチ、発行または実行のそれぞれの順序また は頻度を制御するマルチスレッド中央演算装置。
[3] 請求項 2記載の装置において、
前記第 1の制御手段が、第 1の優先度をもつ 1以上の第 1のスレッドへの前記資源 の割当量が、前記第 1の優先度より下位の第 2の優先度をもつ 1以上の第 2のスレッド へのそれ以下であるとき、前記第 1のスレッド中の少なくとも一つのスレッドの命令の フェッチ、発行または実行を促進し、または、前記第 2のスレッドの命令のフェッチ、発 行または実行を抑制するマルチスレッド中央演算装置。
[4] 請求項 3記載の装置において、
前記第 1の制御手段が、各スレッドへの前記資源の割当量が少なくて所定の下限 条件を満たさないとき、前記各スレッドの命令のフェッチ、発行または実行を促進し、 または、前記各スレッドの命令のフェッチ、発行または実行の抑制を解除するマルチ スレッド中央演算装置。
[5] 請求項 3項記載の装置において、
前記第 1のスレッド中の前記少なくとも一つのスレッドには、前記資源の占有量が前 記第 1のスレッド中で最小であるスレッドが含まれるマルチスレッド中央演算装置。
[6] 請求項 2記載の装置において、
フェッチされた前記複数のスレッドの命令をそれが発行されるまで保持する命令バ ッファをさらに備え、
前記第 1の制御手段が、前記複数のスレッドによる前記命令バッファの占有量を監 視し、前記複数のスレッドによる前記命令バッファの占有量が前記複数のスレッドの 優先度に従うように、前記複数のスレッドの命令のフ ツチの順序または頻度を制御 するマルチスレッド中央演算装置。
[7] 請求項 6記載の装置において、
前記第 1の制御手段が、第 1の優先度をもつ 1以上の第 1のスレッドによる前記命令 バッファの占有量が、前記第 1の優先度より下位の第 2の優先度をもつ 1以上の第 2 のスレッドによるそれ以下であるとき、前記第 1のスレッド中の少なくとも一つのスレッド の命令のフェッチを促進し、または、前記第 2のスレッドの命令のフェッチを抑制する マルチスレッド中央演算装置。
[8] 請求項 7記載の装置において、
前記第 1の制御手段が、各スレッドによる前記命令バッファの占有量が少なくて所 定の下限条件を満たさないとき、前記各スレッドの命令のフェッチを促進し、または、 前記各スレッドの命令のフ ツチの抑制を解除するマルチスレッド中央演算装置。
[9] 請求項 7記載の装置において、
前記第 1のスレッド中の前記少なくとも一つのスレッドには、前記命令バッファの占 有量が前記第 1のスレッド中で最小であるスレッドが含まれるマルチスレッド中央演算 装置。
[10] 請求項 2記載の装置において、
フェッチされた前記複数のスレッドの命令をそれが発行されるまで保持する命令バ ッファと、
前記命令バッファ力 発行された前記複数のスレッドの命令をそれが実行されるま で保持する 1以上のリザべーシヨンステーションと
をさらに備え、 前記第 1の制御手段が、前記複数のスレッドによる前記リザべーシヨンステーション の占有量を監視し、前記複数のスレッドによる前記リザべーシヨンステーションの占有 量が前記複数のスレッドの優先度に従うように、前記複数のスレッドの命令の発行の 順序または頻度を制御するマルチスレッド中央演算装置。
[11] 請求項 10記載の装置において、
前記第 1の制御手段が、第 1の優先度をもつ 1以上の第 1のスレッドによる前記リザ ベーシヨンステーションの占有量が、前記第 1の優先度より下位の第 2の優先度をも つ 1以上の第 2のスレッドによるそれ以下であるとき、前記第 1のスレッド中の少なくと も一つのスレッドの命令の発行を促進し、または、前記第 2のスレッドの命令の発行を 抑制するマルチスレッド中央演算装置。
[12] 請求項 7または 8の 、ずれか一項記載の装置にお!、て、
前記第 1のスレッド中の前記少なくとも一つのスレッドには、前記リザべーシヨンステ ーシヨンの占有量が前記第 1のスレッド中で最小であるスレッドが含まれるマルチスレ ッド中央演算装置。
[13] 請求項 1記載の装置において、
前記第 1の制御手段力 通常の状況下では上位優先度のスレッドの命令が下位優 先度のスレッドの命令より先に処理され、前記上位優先度のスレッドが前記装置内の 所定の資源を無駄にするか非効率的に使用するような所定状況下では、前記下位 優先度のスレッドの命令が前記上位優先度のスレッドの命令より先に処理されるよう に制御を行うマルチスレッド中央演算装置。
[14] 請求項 1記載の装置において、
前記第 2の制御手段が、前記各スレッドの命令実行状態が前記各スレッドの命令実 行目標に近づくように、前記複数のスレッドの命令のフェッチまたは発行の順序また は頻度を制御するマルチスレッド中央演算装置。
[15] 請求項 14記載の装置において、
前記第 2の制御手段が、或るスレッドの前記命令実行状態が前記命令実行目標を 満たさない場合、前記或るスレッドの命令のフェッチまたは発行を促進し、または、前 記或るスレッドより下位の優先度をもつ他のスレッドの命令のフェッチまたは発行を抑 制するマルチスレッド中央演算装置。
[16] 請求項 1記載の装置において、
前記第 1の制御手段は、所定の制御条件に従って前記複数のスレッドの命令の処 理の順序または頻度を制御し、
前記第 2の制御手段が、前記各スレッドの命令実行状態が前記各スレッドの命令実 行目標に近づくようにするための調整を、前記第 1の制御手段の前記制御条件にカロ えるマルチスレッド中央演算装置。
[17] 請求項 16記載の装置において、
前記第 2の制御手段が、或るスレッドの前記命令実行状態が前記命令実行目標を 満たさな 、場合、前記或るスレッドの命令の処理の頻度を増加させるための調整を、 前記第 1の制御手段の制御条件に加え、そして、前記調整を加えても前記或るスレツ ドの前記命令実行状態に所定条件を満たす改善が現れな!/、場合、前記加えられた 調整を解除して前記制御条件を前記調整を加える前のものに戻すマルチスレッド中 央演算装置。
[18] 同時マルチスレツディングの制御方法にぉ 、て、
各スレッドの優先度をもつステップと、
前記各スレッドの優先度を用いて、前記複数のスレッドの命令の処理の順序または 頻度を制御するステップと、
各スレッドの命令実行目標をもつステップと、
前記各スレッドの命令実行状態を監視するステップと、
前記各スレッドの前記命令実行状態と前記命令目標を用いたフィードバック制御動 作により、前記複数のスレッドの命令の処理の順序または頻度を制御するステップと 有する同時マルチスレツディング制御方法。
PCT/JP2006/311022 2005-06-02 2006-06-01 マルチスレッド中央演算装置および同時マルチスレッディング制御方法 WO2006129767A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007519071A JP5145936B2 (ja) 2005-06-02 2006-06-01 マルチスレッド中央演算装置および同時マルチスレッディング制御方法

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2005-162549 2005-06-02
JP2005162549 2005-06-02
JP2005-167427 2005-06-07
JP2005167427 2005-06-07

Publications (1)

Publication Number Publication Date
WO2006129767A1 true WO2006129767A1 (ja) 2006-12-07

Family

ID=37481695

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2006/311022 WO2006129767A1 (ja) 2005-06-02 2006-06-01 マルチスレッド中央演算装置および同時マルチスレッディング制御方法

Country Status (2)

Country Link
JP (1) JP5145936B2 (ja)
WO (1) WO2006129767A1 (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103324269A (zh) * 2013-06-13 2013-09-25 中国科学院计算技术研究所 一种降低多线程程序功耗的方法及系统
CN103336571A (zh) * 2013-06-13 2013-10-02 中国科学院计算技术研究所 一种降低多线程程序功耗的方法及系统
JP2014053016A (ja) * 2007-11-19 2014-03-20 Qualcomm Incorporated バスアクセス要求の選択的除外
US9436464B2 (en) 2010-06-11 2016-09-06 Socionect Inc. Instruction-issuance controlling device and instruction-issuance controlling method
CN113139003A (zh) * 2020-01-19 2021-07-20 上海静客网络科技有限公司 一种基于spark的大数据处理方法
US11204802B2 (en) 2020-04-27 2021-12-21 International Business Machines Corporation Adjusting a dispatch ratio for multiple queues

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10124316A (ja) * 1996-08-27 1998-05-15 Matsushita Electric Ind Co Ltd 複数の命令流を独立に処理し、命令流単位に処理性能を柔軟に制御するマルチスレッドプロセッサ
JP2882475B2 (ja) * 1996-07-12 1999-04-12 日本電気株式会社 スレッド実行方法
JP2004287883A (ja) * 2003-03-24 2004-10-14 Toshiba Corp プロセッサ、計算機及び優先度決定方法
JP2004532444A (ja) * 2001-02-19 2004-10-21 イマジネイション テクノロジーズ リミテッド マルチスレッドプロセッサ上の優先順位及び命令速度の制御

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2882475B2 (ja) * 1996-07-12 1999-04-12 日本電気株式会社 スレッド実行方法
JPH10124316A (ja) * 1996-08-27 1998-05-15 Matsushita Electric Ind Co Ltd 複数の命令流を独立に処理し、命令流単位に処理性能を柔軟に制御するマルチスレッドプロセッサ
JP2004532444A (ja) * 2001-02-19 2004-10-21 イマジネイション テクノロジーズ リミテッド マルチスレッドプロセッサ上の優先順位及び命令速度の制御
JP2004287883A (ja) * 2003-03-24 2004-10-14 Toshiba Corp プロセッサ、計算機及び優先度決定方法

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014053016A (ja) * 2007-11-19 2014-03-20 Qualcomm Incorporated バスアクセス要求の選択的除外
US9436464B2 (en) 2010-06-11 2016-09-06 Socionect Inc. Instruction-issuance controlling device and instruction-issuance controlling method
CN103324269A (zh) * 2013-06-13 2013-09-25 中国科学院计算技术研究所 一种降低多线程程序功耗的方法及系统
CN103336571A (zh) * 2013-06-13 2013-10-02 中国科学院计算技术研究所 一种降低多线程程序功耗的方法及系统
CN103336571B (zh) * 2013-06-13 2016-02-03 中国科学院计算技术研究所 一种降低多线程程序功耗的方法及系统
CN113139003A (zh) * 2020-01-19 2021-07-20 上海静客网络科技有限公司 一种基于spark的大数据处理方法
US11204802B2 (en) 2020-04-27 2021-12-21 International Business Machines Corporation Adjusting a dispatch ratio for multiple queues

Also Published As

Publication number Publication date
JP5145936B2 (ja) 2013-02-20
JPWO2006129767A1 (ja) 2009-01-08

Similar Documents

Publication Publication Date Title
JP2006343872A (ja) マルチスレッド中央演算装置および同時マルチスレッディング制御方法
US6542921B1 (en) Method and apparatus for controlling the processing priority between multiple threads in a multithreaded processor
US7752627B2 (en) Leaky-bucket thread scheduler in a multithreading microprocessor
JP5081143B2 (ja) マルチスレッド化されたプロセッサ内で低消費電力モードを自動的に呼び出すための装置及び方法
KR100880470B1 (ko) 스레드 라이브록 유닛
US20040172631A1 (en) Concurrent-multitasking processor
US7941643B2 (en) Multi-thread processor with multiple program counters
US20010056456A1 (en) Priority based simultaneous multi-threading
US9436464B2 (en) Instruction-issuance controlling device and instruction-issuance controlling method
US20070234091A1 (en) Multithreaded dynamic voltage-frequency scaling microprocessor
JP5607545B2 (ja) マイクロプロセッサシステムにおける命令フェッチングの優先順位付け
EP2147373B1 (en) Multithreaded processor for executing thread de-emphasis instruction and method therefor
JP5861354B2 (ja) 演算処理装置及び演算処理装置の制御方法
JP5145936B2 (ja) マルチスレッド中央演算装置および同時マルチスレッディング制御方法
US20060037021A1 (en) System, apparatus and method of adaptively queueing processes for execution scheduling
US7797683B2 (en) Decoupling the number of logical threads from the number of simultaneous physical threads in a processor
JP2011216004A (ja) マイクロプロセッサ、電子制御ユニット、実行比率切り替え方法
WO2002046887A2 (en) Concurrent-multitasking processor
US11144353B2 (en) Soft watermarking in thread shared resources implemented through thread mediation
US7904703B1 (en) Method and apparatus for idling and waking threads by a multithread processor
JP2012168725A (ja) マルチスレッド・プロセッサ
WO2017199106A1 (en) Single-thread speculative multi-threading
CN116324719A (zh) 具有多个op高速缓存管线的处理器
CN116324716A (zh) 用于微处理器中的同时多线程指令调度的装置和方法
Svärd et al. Two Real-Time Operating Systems and Their Scheduling Algorithms: QNX vs. RTLinux

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2007519071

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: 06756899

Country of ref document: EP

Kind code of ref document: A1