Performance monitors in a multithreaded processor architecture

A system comprising a plurality of execution units configured to execute, at least in part, a plurality of instruction threads; a plurality of performance monitors, each performance monitor being configured to collect performance information related to the execution of at least one instruction thread; a selected thread identifier configured to provide, during operation, the selection of at least one instruction thread; and a performance manager configured to filter, utilizing the selected thread, the information collected by the plurality of performance monitors.

TECHNICAL FIELD

This description relates to monitoring the performance of a processor, and more specifically to monitoring the performance of a selected instruction thread in a multi-threaded processor architecture.

BACKGROUND

Typically a processor or central processing unit (CPU) may be thought of a black box. A program or series of instructions may be executed by the processor with only the inputs and outputs of the instruction series known. This may frustrate a programmer's desire to understand how their program is performing and where in the series of instructions optimizations may be made.

Some processors have added performance monitors to assist the programmer or other processor user in understanding how the processor is executing a given series of instructions. Typically the performance monitors may be thought of as monitoring two different tasks: general workload characterization and event counting. Often workload characterization monitors how much work a series of instructions took to perform. For example, the amount of time spent executing the series of instructions may be monitored. Conversely, event counting monitors are often simple counters that count how often a processor or portion of a processor has performed a certain task. In one example, a performance monitor may count the number of cache misses encountered. Typically, the performance monitors count or monitor all the events or the workload of the processor regardless of what series of instructions are being performed.

The term “thread” or “instruction thread” in computer science is typically short for a thread of execution. In this context, a thread may be a series of instructions that are relatively autonomous and self-contained. Frequently, a thread may receive input from another thread before an action may be performed. Likewise, a thread typically returns information to another thread. In some embodiments, a thread may comprise a subroutine, an object, or a plurality of instructions grouped together to perform a task.

In modern processing systems, multiple threads can be executed substantially in parallel. This multithreading generally occurs by time slicing or time-division multiplexing, wherein a single processor switches between different threads, in which case the processing is not literally simultaneous, for the single processor is really doing only one thing at a time. This switching can happen so fast as to give the illusion of simultaneity to an end user.

In more complex processor systems, multiple threads may be capable of executing in parallel. For example, a processor may have three arithmetic logic units (ALUs, capable of performing simple arithmetic) and two floating-point units (FPUs, capable of performing more complex arithmetic). In this example, the processor may actually be able to execute five threads simultaneously, if the execution requirements of the five threads happen to align with the available exaction units.

Also, due to the pipelining nature of modern processors, which breaks the total execution of an instruction into smaller execution steps, a first thread may be executing in the front of the pipeline, while other threads are executing in the middle or end of the pipeline. For example, a first thread may be executed by the Instruction Fetch Unit (IFU, which may read an instruction from memory), while a second thread may be further along in the pipeline and executed by the Instruction Decode Unit (IDU, which may determine what type of further execution an instruction requires), a third thread may be executed by the ALU, and a forth thread may be executed by the write-back unit (WBU, which may write the results of an instructions execution back to memory).

SUMMARY

DETAILED DESCRIPTION

FIG. 1is a block diagram of an embodiment of a system100for the monitoring of processor performance in accordance with the disclosed subject matter. In one embodiment, a system100may include a plurality of execution units110, et seq., a plurality of performance monitors116, et seq., a selected thread identifier120, and a performance manager130. In one embodiment, the system100may be capable of monitoring the performance for a single selected instruction thread being executed in a multi-threaded processing environment. In one embodiment, the system100may include a processor or a central processing unit (CPU).

In one embodiment, the plurality of execution units110may be configured to execute, at least in part, a plurality of instruction threads104. In one embodiment, the system100may be capable of substantially simultaneously executing multiple threads.FIG. 1illustrates at least three execution units110,110′ &110″ with execution logic112,112′ &112″, executed thread identifier114,114′ &114″, and performance monitors116,116′ &116″. In one embodiment, these execution units may be substantially identical. However, it is contemplated that in other embodiments, the execution units may differ.

In one embodiment, the instruction threads104may be assigned to an execution unit by the instruction thread dispatcher102. For example, in one embodiment, one execution unit may be an arithmetic logic unit (ALU), one a floating-point unit (FPU) and a Single Instruction, Multiple Data Unit (SIMD). The instruction thread dispatcher102may examine the thread and determine which form of execution is requested by the thread. In one embodiment, these execution units may be capable of executing separate threads substantially simultaneously.

It is understood that while the traditional textbook processor pipeline may have five pipe stages (Instruction fetch, Instruction decode, Execute, Memory access, and Write back) that the term “execution unit”, in this context is not limited only to units involved in the execute pipe stage. In this context an execution unit may include any logical functional unit block (FUB) that performs an operation or utilizes the instruction thread, regardless or where in the pipeline the FUB conceptually resides. Therefore, the instruction thread dispatcher102may be considered an execution unit even through it may conceptually reside in the Instruction Decode stage. Furthermore, it is understood that the disclosed subject matter is not limited to any number of pipe stages or even a pipelined architecture.

In one embodiment, each of the execution units110may include a executed thread identifier114configured to indicate which of the plurality of instruction threads104the execution unit is currently executing. In one embodiment, each of the instruction threads114may be assigned a sufficiently unique number that indentifies or colors the thread. In one embodiment, the execution units110,110′ &110″ may be executing three different threads. Therefore, their corresponding executed thread identifiers114,114′ &114″ may hold or store three different numbers, each number associated with the current thread being executed. In one embodiment, the value stored by the executed thread identifier114may change as the thread being executed by the execution unit110changes. In one embodiment, each execution unit110,110′ &110″ may include execution logic112,112′ &112″ that ultimately performs the execution operations on the executed thread.

In one embodiment, each of the execution units110may include a subset of the performance monitors116, wherein the subset of performance monitors may be configured to monitor events related with the execution unit. For example, in one embodiment, the execution110may include performance monitor116, while execution unit110′ may include performance monitor116′, and execution unit110″ may include performance monitor116″. In one illustrative embodiment, a performance monitor residing within a cache related to an execution unit may monitor the number of cache hits, cache misses, and/or other cache related information. Conversely, in another illustrative embodiment, a performance monitor residing within a branch prediction related execution unit may monitor the number of encountered instruction branches, the number of predicted instruction branches, and/or the number of correct predictions. It is understood, however, that these are merely a few illustrative embodiments, to which the disclosed subject matter is not limited. In one embodiment, a subset of performance monitors may reside, conceptually, outside of a particular execution unit and monitor system-wide or cross-execution unit performance.

In one embodiment, the plurality of performance monitors114may be configured to collect performance information related to the execution of at least one instruction thread104. In one embodiment, the plurality of performance monitors may be configured to collect information related to the execution of a plurality of instruction threads104. In one embodiment, a performance monitor116may be associated with an execution unit110or execution logic112, and configured to collect performance information related to the execution unit110, regardless of which instruction thread is actively being executed by the execution unit110.

In one embodiment, the selected thread identifier120may be configured to provide, during operation, selection of at least one instruction thread. In one embodiment, a user may select a particular thread to be monitored from amongst the plurality of instruction threads104. In one embodiment, the thread may be selected as a result of a user-configured event. For example, in one embodiment, a particular thread may be selected if a particular instruction branch is taken, a memory access occurs, or a processor exception occurs, etc.; it is understood, however, that these are merely a few example conditions and that the disclosed subject matter is not so limited. In one embodiment, the selected thread identifier may include a thread mask configured to provide the selection of a plurality of threads. For example, in one embodiment, the selected thread identifier may allow for the selection of a number of threads that are derived from a common thread. In a specific example, the number of threads may be all threads occurring as a result of, for example, a particular user action, such as for example, switching a program from offline to online mode. However, this is merely one illustrative to which the disclosed subject matter is not so limited.

In one embodiment, the performance manager130may be configured, during operation, to filter the information collected by the plurality of performance monitors utilizing the selected thread. In one embodiment, the performance manager130may compare the executed thread identifier114with the selected thread identifier120, and if the values of the two are substantially equivalent, instruct the performance monitor116to collect information related to the performance of the execution unit110. Conversely, in one embodiment, if the executed thread identifier114and the selected thread identifier120are not equivalent, the performance manager130may instruct the performance monitor116to not collect information. It is understood that in various embodiments, the performance manager may not be configured to control individual performance monitors, but may control the plurality of performance monitors114,114′ &114″ as a whole, or by subsection.

In another embodiment, the filtration may not occur as the information is collected by the performance monitor114, but instead after the information has been collected. In one embodiment, a performance monitor116,116′ or116″ may collect performance information regarding all executed threads, but may correlate the information by thread. The performance manager may then filter the plurality of available information related to the plurality of instruction threads104by utilizing the selected thread identifier120. It is understood that these are merely two illustrative embodiments and that other embodiments are within the scope of the disclosed subject matter. In addition, further details and embodiments, of the program manager130are discussed below in reference toFIG. 2.

In one embodiment, the system100may include a performance reporter140. In one embodiment, the performance reporter140may be configured to report the performance information collected by one or more performance monitors116,116′ &116″ that is related to the selected thread, as indicated by the selected thread identifier120. In one embodiment, the performance reporter140may make the information available to a user via a software interface. In one embodiment, the performance monitor140may actively change the available performance information as either the information of the selected thread change. In another embodiment, the performance reporter140may allow an interface by which a user may select between a plurality of data. In one embodiment, the performance reporter140may filter the available information based, at least in part, upon the selected thread. In one embodiment, the performance manager130may include the performance reporter140.

FIG. 2is a block diagram of an embodiment of a performance monitoring system200for the monitoring of processor performance in accordance with the disclosed subject matter. In one embodiment, the performance monitoring system200may include a selected thread identifier220, at least one memory212, a performance monitoring subsystem210, and a performance reporter240.

In one embodiment, the selected thread identifier220may be configured to indicate an instruction thread that is to be monitored. In one embodiment, each or many performance monitoring subsystems210may include a selected thread identifier220. In such an embodiment, the performance of different execution units may be monitored for different threads. In other embodiments, the selected thread identifier220may be shared amongst all of the performance monitoring subsystems210. In such an embodiment, the performance of all execution units may be monitored for a selected thread.

In one embodiment, the executed thread identifier214may be configured to indicate the instruction thread currently being executed by a particular execution unit. In one embodiment, the executed thread identifier214may be part of the execution unit. In another embodiment, the executed thread identifier214may be part of the performance monitoring system200. In one embodiment, the processor may include a single or limited number of executed thread identifiers214that may be shared amongst multiple execution units. In one embodiment, the executed thread identifier214may receive an active thread identification (ID)204from the executed thread identifier's associated execution unit. In one embodiment, as the execution transitions from one active instruction thread to another, the execution unit may update the value stored within the executed thread identifier214.

In one embodiment, the performance monitor subsystem210can be configured to monitor at least one aspect of the execution of an instruction thread by an execution unit and to generate performance information related to the monitored aspects. In one embodiment, the performance monitor subsystem210may be associated with a single execution unit. However, other embodiments may exist where the performance monitor subsystem210is shared amongst a number of execution units. For example, in one embodiment, a particular performance monitor subsystem210may monitor execution events that occur or relate to multiple execution units, such as, system interrupts.

In one embodiment, the performance monitor subsystem210may be configured to monitor execution aspects by receiving notice of execution events202from the monitored execution unit. In one embodiment, the performance monitor subsystem210may monitor as plurality of events or execution aspects. For example, in one embodiment, a performance monitor subsystem210associated with a branch prediction unit may monitor execution events, such as, for example, conditional and unconditional branches taken, predicted, and encountered, direct and indirect branches taken, predicted, and encountered, calls, and returns, etc. However, this is merely one illustrative embodiment to which the disclosed subject matter is not limited.

In one embodiment, the performance monitoring system200may include at least one memory212configured to store the performance information related to the execution of at least one instruction thread. In one embodiment, the performance monitor116ofFIG. 1may include the performance monitor subsystem210and the memory212.

In one embodiment, the memory212may include a plurality of memories, wherein each of the plurality of memories is configured to store both an instruction thread identifier and performance information related to the execution of the identified instruction thread. In one embodiment, for each active thread ID204a new memory pair may be used to store the execution event202information. A first or key memory may be used to identify what thread ID is associated with the memory pair, while a second or value memory may store the actual performance information related to the execution of the associated thread ID. In one embodiment, the performance information may be stored in the memory212as an associated array with the various thread IDs as the keys of the array. However, this is merely on embodiment, and the disclosed subject matter is not limited to this example embedment. It is understood that embodiments, may exist in which a single memory212is used for each category of performance information being monitored, and the memory212is shared between all threads.

In one embodiment, the performance manager230may be configured to control the performance monitor subsystem210to collect performance information related only to the selected thread. It is contemplated that various embodiments of the performance manger230may be utilized to provide different implementations and means of control, and are within the scope of the disclosed subject matter. A few example, non-limiting embodiments will now be described.

In one embodiment, the performance manager230may be configured to compare the executed thread identifier214with selected thread identifier220and, if the selected thread is not being executed, prevent the performance monitor subsystem210from monitoring the execution of the instruction thread. However, if the executed thread identifier214indicates that the selected thread identifier220is currently being executed by the execution unit, the performance manager203may instruct the performance monitor subsystem210to collect or monitor the execution of the instruction thread. In such an embodiment, the execution events related to non-selected threads may be ignored by the performance monitor subsystem210. As previously mentioned, in some embodiments, each execution unit may be associated with a selected thread identifier220. Whereas in other embodiments, the selected thread identifier220may be associated with the entire processor. It is contemplated that embodiments between these tow extremes may exist and are within the scope of the disclosed subject matter.

In an alternate embodiment, the performance manager230may be configured to detect when the executed thread identifier214changes to be substantially equivalent to the selected thread identifier220, and replace the performance information stored by the memory212with performance information associated with the selected thread. In this embodiment, the performance manager230may allow the performance monitor subsystem210to collect performance information related to a number of threads. However, the performance manager230may take it upon itself to separate the performance information by instruction thread. As the execution unit begins or resumes executing the selected thread, the performance manager230may overwrite the existing performance information related to a non-selected thread, and replace it with last known value of the performance information related with the selected thread. In one embodiment, the performance manager230may replaced the non-selected performance information with a zero or starter value. Likewise, when the execution unit transitions from executing the selected thread to executing a non-selected thread, the performance manager203may store the last known values of the selected performance information for later use. These values may be restored if or when the execution unit transitions back to the selected thread.

In one embodiment, the performance manager230may be configured to store the replaced performance information associated with the non-selected thread. In one embodiment, the performance manager230may push or pop performance information onto or off of a stack. However, other storage techniques are contemplated and within the disclosed subject matter.

In one embodiment, the performance manager230may be configured to provide for dynamically changing the selected thread. In such an embodiment, the performance manager230may store performance information associated with multiple threads, and swap “active” or selected performance information in and out of the memory212. In one embodiment, the performance manager230may utilize the system memory or general registers of the processor to store the inactive performance information. In another embodiment, the memory212may be sufficient to store the various sets of performance information and the performance manager230may merely select which portion of the memory212is used for each thread's associated performance information or which portion of the memory212is to be actively used at a given time.

In one embodiment, the performance reporter240may be configured to report the performance information related to the selected instruction thread. In one embodiment, a user may request that the performance reporter204provide the user with performance information related to a selected thread. The performance reporter240may then retrieve this information and report the information to the user via a performance report242. In one embodiment, the performance reporter240may be configured to retrieve performance information from any or merely a subset of the performance monitor subsystems210or memories212. In one embodiment, the performance reporter240may be configured to provide access to other non-performance related units of a system or processor. In one specific embodiment, the performance monitor204may include a control register access bus (CRAB) that is configured to provide access to the control registers of a processor.

In one embodiment, the performance reporter240may be configured to report the performance information from one of the plurality of memories212, wherein the reported memory includes an identified thread substantially equal to the selected thread. In one embodiment, the memory212may include a plurality of memories, as described above, in which the performance information is stored in an associative array in which the executed thread IDs are used as keys. The performance reporter240may use the selected thread ID as a key to access performance information stored with the memory212. The performance reporter240may then report this selected performance information to the user or as dictated by the embodiment. It is understood that this is merely one illustrative embodiment to which the disclosed subject matter is not so limited.

FIG. 3is a flowchart of an embodiment of a technique for the monitoring of processor performance in accordance with the disclosed subject matter. Block310illustrates that in one embodiment, an instruction thread that is to be monitored may be selected. In one embodiment, this selection may occur as part of a deliberate action by a user or as a consequence of the occurrence of a user-configured event. In one embodiment, the selected thread identifier120ofFIG. 1or the selected thread identifier220ofFIG. 2may perform or facilitate this selection as described above.

Block320illustrates that, in one embodiment, a plurality of instruction threads may be executed. In one embodiment, the plurality of instruction threads may include the selected instruction thread. In one embodiment, the threads may be executed by a variety of execution units. In one embodiment, the execution units110,110′ &110″ or the execution logic112,112′ &112″ ofFIG. 1may perform this execution as described above. In one embodiment, the execution may result in the execution events202and/or active thread ID204ofFIG. 2, as described above.

Block330illustrates that, in one embodiment, the performance of at least the selected thread may be monitored. In one embodiment, the monitoring may include monitoring a plurality of execution events. In one embodiment, the performance monitor116ofFIG. 1or the performance monitoring system200ofFIG. 2may result in this monitoring as described above.

Block332illustrates that, in one embodiment, the performance of a plurality of threads may be monitored. In one embodiment, performance monitoring may occur regardless of whether or not the currently executed thread is the selected thread. In one embodiment, the performance monitor116ofFIG. 1or the performance monitor subsystem210and the memory212ofFIG. 2may perform this monitoring. In another embodiment, the performance monitor116ofFIG. 1or the performance monitor subsystem210and the memory212ofFIG. 2, respectively, may be aided by the performance manager130ofFIG. 1or the performance manager230ofFIG. 2, respectively to perform this monitoring.

Block338illustrates that, in one embodiment, only the performance of the selected thread may be monitored. In one embodiment, if the execution unit is executing a non-selected thread the performance information associated with the non-selected thread may either be ignored or not monitored. In one embodiment, the performance manager130ofFIG. 1or the performance manager230ofFIG. 2may assist the performance monitor116ofFIG. 1or the performance monitoring system200ofFIG. 2, respectively, in monitoring the performance of only the selected thread.

Block340illustrates that, in one embodiment, the performance information associated with the selected thread may be reported. In one embodiment, the performance information may be reported to a user. In one embodiment, the performance reporter140ofFIG. 1or the performance reporter240ofFIG. 2may report the performance information.