Techniques for dynamically tuning processor features.

Abstract

A data processing system, apparatus, method and processor for dynamically tuning a processor are provided. In a data processing system, a processor executes a program in a first execution window with microarchitectural features disabled and a program in a second execution window with microarchitectural features enabled. A dynamic tuning unit (DTU) automatically determines whether the processor achieved poorer performance in the second execution window, updates a utility state for selected addresses of the program in response to determining that poorer performance was achieved, and automatically disables the microarchitectural features for selected addresses in the execution window in response to the utility state.

Description

[Technical field]

[0001] The present disclosure relates generally to data processing systems, and more particularly to techniques for dynamically tuning processors within a data processing system. [Background technology]

[0002] A central processing unit (CPU) in a data processing system may include a variety of different features that, in some circumstances, improve the performance of the CPU compared to a CPU that does not have the features. For example, in some circumstances, a CPU that has speculative execution capabilities may perform better than a comparable CPU that does not have speculative execution capabilities.

[0003] A CPU's features may also be tunable or configurable, in that the features support more than one setting. For purposes of this disclosure, a configurable feature of a CPU may be referred to as a "microarchitectural feature." For example, a CPU may be able to enable and disable a microarchitectural feature. Additionally or alternatively, a CPU may be able to apply different settings to a microarchitectural feature when the microarchitectural feature is enabled. In other words, a microarchitectural feature may support a range of settings.

[0004] However, a micro-architectural feature that is enabled (i.e., turned on) may result in improved performance of some parts of an application while causing degradation of performance of other parts of the application. Moreover, whether a micro-architectural feature causes improved or degraded performance of an application (or portion of an application) may depend on other circumstances associated with the execution of the application (or portion of an application).

[0005] For example, micro-architectural features may cause an application to achieve better performance with some types and / or amounts of data, but poorer performance with other types and / or amounts of data. Also, a data processing system may run multiple applications simultaneously, and the performance of one application may vary depending on the type and number of other applications running on the data processing system, as well as the type and / or amount of data being processed by the other applications. Furthermore, modern processors may have many different micro-architectural features, and these features may have complex interactions that result in differences in performance in different situations.

[0006] For at least the reasons discussed above, tuning microarchitectural features in a manner that achieves improved performance in a wide variety of different situations is difficult. [Brief description of the drawings]

[0007] Features and advantages of the present invention will become apparent from the appended claims, the following detailed description of one or more exemplary embodiments, and the corresponding drawings.

[0008] [Figure 1] 1 is a block diagram illustrating an exemplary embodiment of a data processing system having techniques for dynamically tuning a processor within the data processing system.

[0009] [Diagram 2] 2 is a flow chart of an exemplary process for dynamically tuning the processor of FIG. 1.

[0010] [Diagram 3] 2 is a block diagram showing the operation of a finite state machine within the processor of FIG. 1;

[0011] [Figure 4]2 is a pseudocode description of the operations for dynamically tuning the processor of FIG. 1.

[0012] [Diagram 5] FIG. 1 is a block diagram of a processor that may have more than one core, may have an integrated memory controller, and may have integrated graphics, according to one or more embodiments.

[0013] [Figure 6] FIG. 1 is a system block diagram according to one or more embodiments.

[0014] [Figure 7] FIG. 2 is a block diagram of a more specific exemplary system according to one or more embodiments. [Figure 8] FIG. 2 is a block diagram of a more specific exemplary system according to one or more embodiments.

[0015] [Figure 9] FIG. 1 is a block diagram of a system-on-chip according to one or more embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] As described above, the present disclosure introduces techniques for dynamically tuning a processor in a data processing system. In particular, the present disclosure provides run-time evaluation of different settings for one or more microarchitectural mechanisms to determine a desired setting for current conditions, and provides dynamic application of the desired setting. Further, the evaluation may be repeated over time to determine and apply desired settings for changing conditions.

[0017] As described in more detail below, in one embodiment, a dynamic tuning unit in the processor causes the processor to execute software using the microarchitectural features of the processor in a first setting (e.g., disabled) for a first execution window and using the microarchitectural features in a second setting (e.g., enabled) for a second execution window, where the windows are of the same size. The dynamic tuning unit determines whether performance has improved or deteriorated based on the number of cycles required to complete each of these windows. For example, if the second window completed in significantly fewer cycles than the first window, the dynamic tuning unit may determine that the second setting of the microarchitectural features resulted in improved performance. Also, if the processor completed the second window in fewer cycles than the first window, the processor was able to execute, on average, more instructions per cycle (IPC) in the second window. Thus, improved performance may be evaluated in terms of more efficient instructions per cycle (IPC), with improved performance being reflected in more efficient IPC.

[0018] The dynamic tuning unit may use such evaluation in conjunction with the finite state machine to determine desired settings of the micro-architectural features. Additionally, the dynamic tuning unit may evaluate different portions of the software being executed, and the dynamic tuning unit may determine and apply different desired settings of the micro-architectural features to these different portions of the software. For example, the dynamic tuning unit may enable micro-architectural features for some portions of a workload and disable the micro-architectural features for other portions of the workload. For purposes of this disclosure, the process of causing a micro-architectural feature of a processor to use different settings (e.g., enable or disable) for different portions of a workload may be referred to as "selective throttling" of that micro-architectural feature.

[0019] 1 is a block diagram illustrating an exemplary embodiment of a data processing system 10 having techniques for dynamically tuning a processor 12 within the data processing system 10. The data processing system 10 is a virtual system having various virtual components and functions that are illustrative of the techniques introduced herein.

[0020] As shown in the figure, in addition to a CPU or processor 12, data processing system 10 includes other hardware resources, such as random access memory (RAM) 14, non-volatile storage (NVS) 16, network interface controller (NIC) 18, etc. In the embodiment of FIG. 1, processor 12 also includes two cores 20A-20B, and other modules, such as a clock 22, etc. As shown in the figure, core 20A includes various processing resources, such as an arithmetic logic unit (ALU) 24, a set of general purpose registers 26, a prefetch unit 28, etc. Core 20B may also include the same or similar types of components.

[0021] Also, in other embodiments, a processor may include fewer or more cores. For example, a processor may include a single core, or tens or hundreds of cores. A processor may also be implemented as an integrated circuit or "chip" that is attached to a substrate to form a package. Alternatively, a processor may be implemented as a package that includes more than one chip.

[0022] 1 embodiment, NV 16 includes software, such as an operating system (OS) 52 and applications 54. Data processing system 10 may copy the software into RAM 14 for execution. Data processing system 10 may also execute software on multiple cores simultaneously. Further, each core may include multiple logical processors (LPs), and each core may execute software on multiple LPs simultaneously. For example, in a data processing system having a CPU that includes four cores with two LPs per core, the data processing system may simultaneously execute eight different applications, eight instances of a single application, etc.

[0023] 1 embodiment, prefetch unit 28 is tunable, in that processor 12 can turn prefetch unit 28 on or off and / or can apply different settings to prefetch unit 28 when prefetch unit 28 is turned on. In other words, prefetch unit 28 is a microarchitectural feature. In particular, prefetch unit 28 includes feature settings 29 that can be updated to affect whether and / or how prefetch unit 28 operates.

[0024] Additionally, as described in more detail below, prefetch unit 28 includes a dynamic tuning unit 30 having control logic for dynamically tuning prefetch unit 28 (e.g., by dynamically adjusting feature settings 29). Additionally, a data processing system may include multiple micro-architectural features and a separate dynamic tuning unit for each of these micro-architectural features. For purposes of this disclosure, some or all of the control logic of the dynamic tuning unit may be referred to as "tuning control logic."

[0025] In the embodiment of FIG. 1, the control logic within the dynamic tuning unit 30 includes a retired instruction counter 32, a global valid flag 34, a current cycle counter 36, a previous cycle counter 38, a refresh counter 31, and a utility finite state machine (FSM) 42, as described in more detail below. The control logic also includes various tuning parameters 40 for adjusting how the dynamic tuning unit 30 operates. In the embodiment of FIG. 1, the tuning parameters 40 include window size, commitment threshold, importance threshold, selected address list, selected address count, and refresh threshold parameters, as described in more detail below. The control logic also includes a performance evaluation unit (PEU) 33 that determines whether enabling the prefetch unit 28 will result in better or worse performance, and a tuning execution unit (TIU) 35 that implements the tuning decision by enabling or disabling the prefetch function of the prefetch unit 28 for the selected address after the utility state for the selected address reaches a determined good state or a determined bad state, respectively, as described in more detail below.

[0026] Prefetch unit 28 also includes an evaluation table 50, which dynamic tuning unit 30 uses to evaluate the performance of different feature settings of prefetch unit 28. In the embodiment of FIG. 1, evaluation table 50 includes a row or entry 51 for each selected address (SA) in application 54, the row including the SA's commitment counter (IC), feature setting (FS), and availability state (US). In FIG. 1, subscripts are used to identify variables or values ​​that correspond to a given SA. Further details on an exemplary embodiment of a process using evaluation table 50 are provided below. An SA may also be referred to as an instruction pointer (IP).

[0027] Thus, the control logic within dynamic tuning unit 30 includes various control structures (e.g., PEU 33, TIU 35, and utility FSM 42) and various data storage structures (e.g., refresh counter 31, counter of retired instructions 32, etc.). These data storage structures may be implemented as one or more registers, as part of one or more registers, or as any other suitable type or types of data storage structures. Similarly, the control structures may be implemented using any suitable type or types of hardware structures. For example, as shown below, some or all of the control logic implementing some or all of the operation of dynamic tuning unit 30 may be implemented in hardware circuitry within a chip. Thus, the dynamic tuning unit (DTU) may also be referred to as a DTU circuit (or DTU circuitry), the PEU may be referred to as a PEU circuit (or PEU circuitry), the TIU may be referred to as a TIU circuit (or TIU circuitry), etc. Additionally, terms such as "logic" may be used to refer to hardware logic circuitry, other types of hardware components, or combinations of hardware components.

[0028] 2 is a flow chart of an exemplary process for dynamically tuning processor 12. In particular, the process of FIG. 2 illustrates how dynamic tuning unit 30 evaluates the performance of processor 12 with different settings of prefetch unit 28 and dynamically tunes prefetch unit 28 for improved performance. For illustrative purposes, the process is described in the context of dynamic tuning unit 30 evaluating and adjusting the performance of processor 12 while the processor is executing application 54 to enable processor 12 to achieve better performance while executing application 54. Thus, application 54 may be referred to as "dynamically-tunable software." However, dynamic tuning unit 30 may use the same types of steps to improve the performance of other dynamically-tunable software.

[0029] 2 may begin with dynamic tuning unit 30 determining whether dynamically tunable software (such as application 54) has started or launched, as indicated by block 110. If such software is not running, dynamic tuning unit 30 may wait for the dynamically tunable software to launch.

[0030] However, when the application 54 launches, as shown in block 112, the dynamic tuning unit 30 may load a list of addresses of instructions in the application 54 into a “selected address list” parameter in the tuning parameters 40. In particular, this list of addresses identifies all instructions in the application 54 that are to be evaluated for performance at different settings of the prefetch unit 28. As described in more detail below, the dynamic tuning unit 30 will then use the selected address list to evaluate different portions of the application 54 and dynamically tune the prefetch unit 28 for these different portions based on this evaluation. The dynamic tuning unit 30 may also load a count of SAs into the “selected address count” parameter. In particular, in one embodiment, the dynamic tuning unit 30 includes heuristic control logic that automatically analyzes the application 54 to generate the selected address list (and selected address count) based on an evaluation of which instructions in the application 54 are most likely to enable performance improvements due to selective throttling of the prefetch unit 28. After or while generating the selected address list and selected address count, dynamic tuning unit 30 may load these values ​​into tuning parameters 40.

[0031] As indicated at block 114, dynamic tuning unit 30 may then perform some initialization operations to prepare itself. For example, dynamic tuning unit 30 may create a reputation table 50 for application 54 that includes a row or entry for each SA in application 54 and initializes the utility state of each SA to a neutral initial state. For purposes of this disclosure, addresses of instructions that are not selected may be referred to as "unselected addresses" (UAs). For example, FIG. 4 illustrates actions triggered by the retirement of an SA and actions triggered by the retirement of a UA.

[0032] Referring again to FIG. 1, as described in more detail below, dynamic tuning unit 30 may then use utility FSM 42 to adjust the state of each SA.

[0033] 3 is a block diagram illustrating the operation of serviceability FSM 42. As shown, this FSM includes three intermediate states and two final states. The intermediate states include an initial state of "neutral," as well as "likely bad" and "likely good" states. The final states are "bad" and "good." As indicated by the top set of arrows with the label "Better," serviceability FSM 42 changes the serviceability state of an SA from an intermediate state to the next state to the right in response to a determination that a particular setting of prefetch unit 28 resulted in better performance than a default or previous setting. Similarly, as indicated by the bottom set of arrows with the label "Worse," serviceability FSM 42 changes the serviceability state of an SA from an intermediate state to the next state to the left in response to a determination that a particular setting of prefetch unit 28 resulted in worse performance than a default or previous setting. For purposes of this disclosure, the serviceability states "bad," "likely bad," "neutral," "likely good," and "good" may be indicated using values ​​1-5, respectively. Also, the absence of an arrow at a particular location in the serviceability FSM 42 indicates that once the state of the SA reaches a final state, the SA will remain in that state (until reset), regardless of the outcome of subsequent performance. However, in other embodiments, the serviceability FSM may include more than three intermediate states. Nevertheless, to reach a final state, the SA must have at least two successive changes in the same direction (i.e., at least two successive increments or decrements).

[0034] One important aspect of FSM 42 is that it provides bimodality in that it allows the usefulness state of the SA to move in two different directions. For example, the SA may fluctuate back and forth between states such as "possibly bad" and "possibly good" for several different windows, so that a brief state of improved or degraded performance (such as may occur when application 54 undergoes a program phase transition) does not cause dynamic tuning unit 30 to lock in a particular setting of the micro-architectural features. Instead, as described above, to reach a final state, the SA must have at least two successive changes in the same direction.

[0035] 3 also illustrates several variables that the dynamic tuning unit 30 uses in conjunction with the utility FSM 42 to dynamically assess and adjust the utility state of the exemplary SA. In particular, FIG. 1 Based at least in part on the SA 1 of the US 1 (These variables are also shown in first row 51 of evaluation table 50 in FIG. 1 ). In particular, FIG. 3 illustrates dynamic tuning unit 30 evaluating performance upon completion of a “current cycle” that was performed with global enable flag 34 set. FIG. 3 also illustrates that, in certain circumstances, dynamic tuning unit 30 may use utility FSM 42 to evaluate and adjust SA 1 to a “better” utility state or a “worse” utility state. In particular, any adjustments are made when (a) cycle differences 39 greater than or equal to a significance threshold, and (b) ICs greater than or equal to an engagement threshold. 1 If these preliminary conditions are met and current cycle counter 36 is less than previous cycle counter 38, dynamic tuning unit 30 uses the "better" function of FSM 42 to transition the US from the intermediate utility state to the next utility state to the right. 1Also, if these preliminary conditions are met and current cycle counter 36 is greater than previous cycle counter 38, dynamic tuning unit 30 uses the "worse" function of FSM 42 to change the US from the intermediate utility state to the next utility state to the left. 1 The process of evaluating and adjusting the utility state is described more fully below.

[0036] 2, the act of preparing dynamic tuning unit 30 may also include clearing variables such as retired instruction counter 32, global valid flag 34, current cycle counter 36, previous cycle counter 38, and refresh counter 31. As described in more detail below, dynamic tuning unit 30 uses retired instruction counter 32 to count the number of retired instructions within an execution window. The retired instruction counter may also be referred to as a "window-length counter."

[0037] Dynamic tuning unit 30 also uses a global valid flag 34 to indicate whether prefetch unit 28 is enabled for an execution window. The global valid flag may also be referred to as a "global qualified bit."

[0038] Dynamic tuning unit 30 also uses current-cycle counter 36 to count the number of cycles that have occurred so far in the current window. Then, before starting a new window, dynamic tuning unit 30 may copy the value from current-cycle counter 36 to previous-cycle counter 38 so that the total number of cycles in the new window can then be compared to the total number of cycles in the previous window. The current-cycle counter may also be referred to as the "current-window clock."

[0039] Dynamic tuning unit 30 also uses a refresh counter 31 to count the number of cycles over multiple windows. As described in more detail below, when the refresh counter 31 reaches a predetermined refresh threshold, dynamic tuning unit 30 may perform a global refresh to unlock any SAs that have reached a final state, which allows dynamic tuning unit 30 to assign different states to these SAs depending on the conditions that have changed.

[0040] The preparatory operations may also include setting some of the tuning parameters 40 with desired values ​​(including, for example, a window size value, an involvement threshold value, an importance threshold value, and a refresh threshold value). The preparatory operations may also include executing a window's worth of instructions from the application 54 with the prefetch unit 28 disabled to obtain a baseline measure for the current cycle's counter 36. In particular, this value will indicate how many cycles were required to execute a window's worth of instructions when the prefetch unit 28 was disabled.

[0041] As indicated by block 116, after dynamic tuning unit 30 has completed the preparatory operations, core 20A may continue to execute application 54. Also, as indicated by blocks 118 and 120, concurrently with the execution of application 54, dynamic tuning unit 30 may collect metrics, use these metrics to evaluate the performance of application 54, and adjust the settings of prefetch unit 28 based on these evaluations. Further details regarding the process of executing application 54, collecting execution metrics, evaluating the performance of application 54 based on these metrics, and adjusting the settings of prefetch unit 28 accordingly are provided below with respect to FIG.

[0042] As indicated at block 130, dynamic tuning unit 30 may determine whether application 54 has terminated. If application 54 has terminated, processing may end. However, if application 54 has not terminated, dynamic tuning unit 30 may determine whether refresh counter 30 has reached a refresh threshold, as indicated at block 142. If the refresh threshold has not been reached, core 20A may continue to execute the application, and dynamic tuning unit 30 may continue to use evaluation table 50 and utility FSM 42 to evaluate the performance of application 54 and adjust prefetch unit 28, as described above.

[0043] However, if the refresh threshold is reached, dynamic tuning unit 30 may reset the utility state of each SA in rating table 50 to a neutral state, thereby clearing the final state. Dynamic tuning unit 30 may also reset IC.

[0044] As a result, the refresh process allows dynamic tuning unit 30 to apply different final states to a given SA at different stages of execution, thereby providing improved performance in a wide variety of situations.

[0045] Figure 4 is a pseudocode description of the operations for dynamically tuning the processor of Figure 1. In particular, Figure 4 includes pseudocode for an example embodiment of an execution stream that implements blocks 116, 118, and 120 of Figure 2, as well as a key that defines certain acronyms used in the execution stream.

[0046] 4 to add data to rating table 50 for a window of execution that includes the retirement of a predetermined number of instructions from application 54. In the illustrated embodiment, dynamic tuning unit 30 uses a “window size” tuning parameter 40 to specify this number. Also, after the end of each window, dynamic tuning unit 30 may update the utility status of one or more SAs. For example, if prefetch unit 28 was enabled for an SA during the window, if the SA has executed a significant number of times, if performance has improved significantly (compared to the window during which prefetch unit 28 was not enabled for the SA), and if the utility status for the SA is not yet in a final state, dynamic tuning unit 30 may change the utility status of the SA in rating table 50 to a “better” state.

[0047] As described above, dynamic tuning unit 30 may determine whether the performance for the current window is better than the performance for the previous window based on the number of cycles required to complete the current window compared to the number of cycles required to complete the previous window. Performance is considered to have improved if the current window is completed in significantly fewer cycles.

[0048] The operations of evaluating the performance of a window's application and updating the availability state based on that evaluation are described in more detail below.

[0049] 4 may begin with dynamic tuning unit 30 preparing to evaluate a new window by saving values ​​from current cycle counter 36 to previous cycle counter 38 and resetting current cycle counter 36 and retired instructions counter 32. Dynamic tuning unit 30 may also reset the participation counters in evaluation table 50 for each SA.

[0050] Thereafter, as application 54 executes and retires a window's worth of instructions, dynamic tuning unit 30 may increment current cycle counter 36 once per cycle, also incrementing retired instruction counter 32 as an instruction is retired, and incrementing the associated participation counter in evaluation table 50 whenever a retired instruction is present at one of the selected addresses.

[0051] 4, the operator "++" indicates an increment operation, and the operations between the "Start Window" and the "End Window" represent operations performed on the virtual execution stream.

[0052] In particular, in terms of a hypothetical scenario, FIG. 4 shows that during each cycle, dynamic tuning unit 30 increments current cycle counter 36 (CCC). 1 For Cycle , no instructions are retired and therefore dynamic tuning unit 30 does not increment retired instruction counter 32. 2 During "SA", core 20A retires instructions from the reorder buffer. In particular, core 20A 1 In other words, Core 20A will retire SA 1As a result, the dynamic tuning unit 30 increments the retired instruction counter 32 (RIC) and the refresh counter 31 (RC). 1 In other words, the dynamic tuning unit 30 increments an involvement counter (IC) in the evaluation table 50 for IC 1 Increment .

[0053] After that, "Cycle 3 During "Cycle ", core 20A retires an instruction at an unselected address (UA). As a result, dynamic tuning unit 30 increments CCC, RIC, and RC, but dynamic tuning unit 30 does not increment any of the participation counters. 4 During "Cycle ", no instructions are retired, so the dynamic tuning unit 30 increments only CCC. 5 During the "Core 20A" 1 As a result, the dynamic tuning unit 30 again retires RIC, RC, and IC. 1 Then, increment "Cycle 6 During this time, Core 20A is SA 2 As a result, the dynamic tuning unit 30 retires the RIC, RC, and SA. 2 The commitment counter for the instruction in (i.e., IC 2 During subsequent cycles, dynamic tuning unit 30 continues to perform operations as described above, as necessary, based on which instructions are retired.

[0054] Additionally, when core 20A retires an SA, dynamic tuning unit 30 may update the FS field of that SA in evaluation table 50 to reflect the current setting of prefetch unit 28. For example, dynamic tuning unit 30 may copy a value from feature setting 29 from prefetch unit 28 into the FS field for the SA.

[0055] However, once the value in counter 32 of retired instructions is equal to the predetermined window size indicated in tuning parameters 40, dynamic tuning unit 30 terminates or closes the window. Q , and then terminate the window. The subscript Q thus indicates the number of cycles required to execute and retire one window's worth of instructions. Similarly, the value in counter 36 for the current cycle will reflect that number of cycles, and the value in refresh counter 31 will have been incremented by the number of instructions retired in the current window (compared to its initial value at the start of the window). Alternatively, rather than incrementing refresh counter 31 whenever an instruction is retired, dynamic tuning unit 30 could simply add the window size to refresh counter 31 at the end of each window.

[0056] Once the most recent (or "current") window closes, dynamic tuning unit 30 may analyze the collected data and adjust the availability state for the SAs that were involved in that window. In particular, in the embodiment of FIG. 4, dynamic tuning unit 30 determines whether global valid flag 34 is set, which indicates that prefetch unit 28 was valid for the current window. However, if global valid flag 34 is not set, processing moves to the other branch where dynamic tuning unit 30 sets global valid flag 34.

[0057] However, if the global valid flag 34 is set, the core 20A executes the current window with the prefetch unit 28 enabled, and the window includes execution of instructions in a likely medium utility state, meaning that these particular instructions would have been executed with the prefetch unit 28 enabled. As a result, the dynamic tuning unit 30 analyzes the collected data to determine whether enabling the prefetch unit 28 resulted in a significant performance improvement or degradation, and adjusts the state of the SA accordingly. To determine whether there was a significant loss or gain in performance of the current window compared to the previous window, the dynamic tuning unit 30 may subtract the current cycle counter 36 from the previous cycle counter 38 to generate a "cycle difference" 39 indicating how many fewer cycles (or how many more cycles) were used in the current window. The dynamic tuning unit 30 may compare the cycle difference 39 to a predetermined significance threshold. If cycle difference 39 is not greater than or equal to the significance threshold, dynamic tuning unit 30 may skip further evaluation and simply reset global valid flag 34, causing dynamic tuning unit 30 to disable prefetch unit 28 for the next window.

[0058] However, if the difference is significant, dynamic tuning unit 30 may consider each SA and determine whether the utility state for that SA should be changed. In particular, as shown in the For loop, for each SA, dynamic tuning unit 30 determines (a) whether the engagement counter for that SA >= a predetermined engagement threshold, and (b) whether the SA is in an intermediate (i.e., non-final) state. If the SA has not had much engagement within the current window, dynamic tuning unit 30 does not change the utility state for that SA in rating table 50. Similarly, if the SA is not in an intermediate state, dynamic tuning unit 30 does not change the utility state for that SA.

[0059] However, if the SA is highly engaged and is in an intermediate state, dynamic tuning unit 30 adjusts the utility state for that SA depending on whether performance has improved or deteriorated. In particular, if fewer cycles have been used within the current window, performance has improved, so dynamic tuning unit 30 increments the utility state for that SA along one of the "better" arrows in utility FSM 42. However, if more cycles have been used within the current window, performance has deteriorated, so dynamic tuning unit 30 decrements the utility state for that SA along one of the "worse" arrows in utility FSM 42.

[0060] For illustrative purposes, the above operations are described in the context of a For loop. However, in one embodiment, dynamic tuning unit 30 actually performs the evaluation and update for all SAs in parallel. For example, as described above with respect to block 112 of FIG. 2, each row / entry in evaluation table 50 may include a valid flag (e.g., one bit), and dynamic tuning unit 50 may set the valid flag for a row in conjunction with loading the SA (i.e., the address of the instruction to be evaluated for performance) into the row. Thus, the SAs may be those addresses in evaluation table 50 that are present in rows with their valid flags set. Thereafter, whenever the window ends, dynamic tuning unit 50 may evaluate the performance impact and update the performance metrics for all valid SAs in parallel.

[0061] Once all SAs have been processed (or if cycle difference 39 is not greater than or equal to the significance threshold), dynamic tuning unit 30 may reset global enable flag 34, as described above, causing dynamic tuning unit 30 to disable prefetch unit 28 for the next window. The process of Figure 4 may return to the beginning, with core 20A executing the next window with prefetch unit 28 disabled, then executing the next window with prefetch unit 28 enabled, and so on.

[0062] Furthermore, when core 20A is executing application 54, core 20A will not use prefetch unit 28 for an SA if rating table 50 indicates that the SA has a final availability state of “bad” even if global valid flag 34 is set. And, core 20A will use prefetch unit 28 for an SA if rating table 50 indicates that the SA has a final availability state of “good” even if global valid flag 34 is clear.

[0063] Thus, dynamic tuning unit 30 analyzes the performance of the software during run-time and dynamically adjusts micro-architectural features such as prefetch unit 28 for improved performance. Also, as noted above with respect to FIG. 3, to reach a final state, an SA must have at least two consecutive changes in the same direction. Thus, if enabling prefetch unit 28 results in significantly improved performance for two consecutive global valid windows, dynamic tuning unit 30 may change the utility state for the SAs that contributed significantly to these global valid windows from "neutral" (for example) to "potentially good," and then from "potentially good" to "good." (For purposes of this disclosure, the term "two consecutive globally-enabled windows" refers to two windows executed with the global enable flag set, with no other windows executed between those two windows, except for a window executed with the global enable flag cleared.) And, if enabling prefetch unit 28 results in significantly degraded performance for two consecutive global enable windows, dynamic tuning unit 30 may change the utility state for the (significantly involved) SA from "neutral" (for example) to "possibly bad," and then from "possibly bad" to "bad." However, depending on the circumstances, the utility state for the SA may change through two or more intermediate states.

[0064] For purposes of illustration, this disclosure has focused on an embodiment of a single dynamically tuned microarchitectural feature. However, in other embodiments, a processor may include multiple dynamically tuned microarchitectural features. For example, a core may include two or more microarchitectural features, each of which may include its own dynamic tuning unit and its own evaluation table. Each dynamic tuning unit may include functions similar to those described above with respect to dynamic tuning unit 30. And each evaluation table may include functions similar to those described above with respect to evaluation table 50.

[0065] Also, as mentioned above, the microarchitectural features may support a range of settings, not just on and off. The dynamic tuning unit may then include the FS used for the SA when collecting metrics for the current window and updating the evaluation table. As a result, the evaluation table may indicate the FS used for each SA. The dynamic tuning unit may optimize performance based on these FS. For example, a processor may have a feature setting that selects from a variety of different speeds (or sizes, or other types of settings), and the dynamic tuning unit may compare performance between windows using the different speed settings (or size settings, or other types of settings). The dynamic tuning unit may adjust the utility state for the different SAs based on these comparisons. For example, for a microarchitectural feature that has a range of settings from most conservative to most aggressive, the dynamic tuning unit may iterate from one end of the range to the other for each of these settings. If the maximum optimal performance exists at a particular setting within the range, the dynamic tuning unit may identify that setting by stepwise testing each setting or level, one by one.

[0066] Also, in other embodiments, the dynamic tuning unit may use two different significance thresholds, one applied to determine whether an improvement in performance is significant and another applied to determine whether a degradation in performance is significant, and therefore such thresholds may be referred to as an "improvement significance threshold" and a "degradation significance threshold."

[0067] Additionally, the dynamic tuning unit may use any suitable values ​​for variables such as window size, commitment threshold, importance threshold, and refresh threshold. For example, in one embodiment or scenario, the dynamic tuning unit may use a window size of several thousand instructions (e.g., 8,000-32,000), an importance threshold of 10% or 12.5%, an commitment threshold of 10%-20%, and a refresh threshold of 200,000. However, smaller or larger values ​​may be used for each of these variables in other embodiments or scenarios. Additionally, values ​​such as the importance threshold may be empirically tuned to adjust the sensitivity of throttling mechanisms to particular microarchitectural features.

[0068] As described, a dynamic tuning unit enables a processor to achieve improved performance by dynamically adapting settings of one or more micro-architectural features based on current conditions. Moreover, the dynamic tuning unit may be implemented with control logic that is relatively simple and does not require significant processing resources such as power.

[0069] In at least some scenarios, a dynamic tuning unit according to the present disclosure may enable a processor to achieve significantly improved processing performance. For example, in one simulation scenario, a processor including a branch predicate microarchitectural feature was used to execute a workload to test three different configurations. In a first test, the processor executed the workload with the microarchitectural feature disabled for the entire workload. In a second test, the processor executed the workload with the microarchitectural feature enabled for the entire workload. In a third test, the processor executed the workload with the microarchitectural feature dynamically enabled as described herein for a portion of the workload and with the microarchitectural feature disabled for another portion of the workload. The second test showed that enabling the feature resulted in an approximately 5.9% performance improvement compared to the first test. The third test showed that dynamically tuning the feature as disclosed herein resulted in an approximately 8% performance improvement compared to the first test. Thus, the dynamic tuning improved the benefits of the microarchitectural feature by approximately 30%.

[0070] This improvement may be due, at least in part, to a reduction in the impact of negative outliers, which are portions of a workload that actually cause microarchitectural features to reduce processor performance. For example, a prefetch microarchitectural feature may generally reduce or hide memory latency in the absence of some workloads where the microarchitectural feature may result in cache pollution with negative consequences that outweigh the benefits of the prefetch.

[0071] In one or more embodiments, many different types of micro-architectural features may be dynamically tuned by the dynamic tuning unit. These micro-architectural features may include, without limitation, a branch predication unit, a prefetch unit, and other components within the processor. Additionally or alternatively, these micro-architectural features may include configurable operating characteristics or settings of the processor, including, without limitation, settings such as core clock speed, the size of one or more buffers, or other storage logic configurations.

[0072] Also, in the above description, current cycle counter 36 indicates how many cycles are consumed when the microarchitectural features are enabled, and previous cycle counter 38 indicates how many cycles are consumed when the microarchitectural features are disabled. More generally, for purposes of this disclosure, the counter that indicates how many cycles are consumed when the microarchitectural features are enabled may be referred to as the "enabled-cycles counter," and the counter that indicates how many cycles are consumed when the microarchitectural features are disabled may be referred to as the "disabled-cycles counter."

[0073] Additional Embodiments

[0074] 5-9 are block diagrams of exemplary computer architectures. Such architectures may include a processor tuning control logic of a dynamic tuning unit as described herein. The same or similar elements in FIGS. 5-9 have similar reference numbers. Other system designs and configurations known in the art for laptops, desktops, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, mobile phones, portable media players, handheld devices, and various other electronic devices are also suitable. In general, a wide variety of systems or electronic devices capable of incorporating a processor and / or other execution logic as disclosed herein are generally suitable.

[0075] 5 is a block diagram of a processor 1100 that may have more than one core, may have an integrated memory controller, and may have integrated graphics, according to one or more embodiments. The solid box in FIG. 5 illustrates a processor 1100 with a single core 1102A, a system agent 1110, and a set of one or more bus controller units 1116, while the optional dashed box illustrates an alternative processor 1100 with multiple cores 1102A-N, a set of one or more integrated memory controller units in a system agent unit 1110, and dedicated logic 1108.

[0076] Thus, different implementations of the processor 1100 may include: 1) a CPU with special purpose logic 1108 that is integrated graphics and / or scientific (throughput) logic (which may include one or more cores) and cores 1102A-N that are one or more general purpose cores (e.g., general purpose in-order cores, general purpose out-of-order cores, a combination of the two); 2) a coprocessor with many special purpose cores 1102A-N that are primarily targeted to graphics and / or scientific (throughput); and 3) a coprocessor with many general purpose in-order cores 1102A-N. Thus, the processor 1100 may be a general purpose processor, a coprocessor or a special purpose processor, such as a network or communication processor, a compression engine, a graphics processor, a GPGPU, a high throughput many integrated core (MIC) coprocessor (including 30 or more cores), an embedded processor, or the like. The processor may be implemented on one or more chips. The processor 1100 may be a part of a substrate and / or may be implemented on one or more substrates using any of a number of process technologies, such as, for example, BiCMOS, CMOS, or NMOS.

[0077] The memory hierarchy includes one or more levels of cache units 1104A-N within the cores, a set of shared cache units 1106 or one or more shared cache units 1106, and an external memory (not shown) coupled to a set of unified memory controller units 1114. The set of shared cache units 1106 may include one or more mid-level caches, such as L2, level 3 (L3), level 4 (L4), or other levels of cache, a last level cache (LLC), and / or combinations thereof. While in one embodiment, a ring-based interconnect unit 1112 interconnects the dedicated logic 1108, the set of shared cache units 1106, and the system agent unit 1110 / unified memory controller unit 1114, alternative embodiments may use any number of well-known techniques for interconnecting such units. In one embodiment, coherence is maintained between the one or more cache units 1106 and the cores 1102A-N.

[0078] The system agent unit 1110 includes these components to coordinate the operation of the cores 1102A-N. The system agent unit 1110 may include, for example, a power control unit (PCU) and a display unit. The PCU may include the logic and components necessary to manage the power state of the cores 1102A-N and the integrated graphics logic 1108. The display unit is for driving one or more externally connected displays.

[0079] The cores 1102A-N may be homogenous or heterogeneous in terms of architectural instruction sets, i.e., two or more cores 1102A-N may be capable of executing the same instruction set, while other cores may be capable of executing only a subset of that instruction set or a different instruction set. As described herein, such cores 1102A-N may translate certain memory access instructions into a subline of memory access instructions.

[0080] 6 is a block diagram of a system 1200 according to one or more embodiments. The system 1200 may include one or more processors 1210, 1215 coupled to a controller hub 1220. In one embodiment, the controller hub 1220 includes a graphics memory controller hub (GMCH) 1290 and an input / output hub (IOH) 1250 (which may be on separate chips). The GMCH 1290 includes a memory controller that controls operations in the coupled memory and a graphics controller that is coupled to the memory 1240 and the coprocessor 1245. The IOH 1250 couples the input / output (I / O) devices 1260 to the GMCH 1290. Alternatively, one or both of the memory and the graphics controller are integrated within the processor, the memory 1240 and the coprocessor 1245 are directly coupled to the processor 1210, and the controller hub 1220 is in a single chip with the IOH 1250.

[0081] The optional nature of the additional processor 1215 is indicated in Figure 6 by the dashed lines. Each processor 1210, 1215 may include one or more processing cores as described herein and may be some version of the processor 1100.

[0082] Memory 1240 may be, for example, dynamic random access memory (DRAM), phase change memory (PCM), or a combination of the two. For at least one embodiment, controller hub 1220 communicates with processors 1210, 1215 via a multi-drop bus, such as a front side bus (FSB), a point-to-point interface, such as a Quick Path Interconnect (QPI), or a similar connection 1295.

[0083] In one embodiment, coprocessor 1245 is a special purpose processor, such as, for example, a high throughput MIC processor, a network or communication processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, or the like. In one embodiment, controller hub 1220 may include an integrated graphics accelerator.

[0084] There may be various differences between the physical resources 1210, 1215 in terms of merit across a wide range of criteria, including architectural characteristics, microarchitectural characteristics, thermal characteristics, power consumption characteristics, and the like.

[0085] In one embodiment, the processor 1210 executes instructions that control general types of data processing operations. Embedded within the instructions may be coprocessor instructions. The processor 1210 recognizes these coprocessor instructions as being of a type to be executed by the attached coprocessor 1245. Thus, the processor 1210 issues these coprocessor instructions (or control signals representing the coprocessor instructions) on a coprocessor bus or other interconnect to the coprocessor 1245. The coprocessor 1245 accepts the received coprocessor instructions and executes them.

[0086] 7 and 8 are block diagrams of more specific exemplary systems 1300 and 1400 according to one or more embodiments. As shown in FIG. 7, multiprocessor system 1300 is a point-to-point interconnect system and includes a first processor 1370 and a second processor 1380 coupled via a point-to-point interconnect 1350. Each of processors 1370 and 1380 may be some version of processor 1100. In one embodiment, processors 1370 and 1380 are processors 1210 and 1215, respectively, while coprocessor 1338 is coprocessor 1245. In another embodiment, processors 1370 and 1380 are processors 1210 and coprocessor 1245, respectively.

[0087] Processors 1370 and 1380 are shown including integrated memory controller (IMC) units 1372 and 1382, respectively. Processor 1370 also includes point-to-point (PP) interfaces 1376 and 1378 as part of its bus controller unit. Similarly, a second processor 1380 includes PP interfaces 1386 and 1388. Processors 1370, 1380 may exchange information over PP interface 1350 using PP interface circuits 1378, 1388. As shown in FIG. 7, IMCs 1372 and 1382 couple the processors to respective memories, i.e., memory 1332 and memory 1334, which may be part of a main memory locally attached to the respective processors.

[0088] Processors 1370, 1380 may exchange information with chipset 1390 via respective PP interfaces 1352, 1354 using point-to-point interface circuits 1376, 1394, 1386, 1398, respectively. Chipset 1390 may optionally exchange information with coprocessor 1338 via high performance interface 1339. In one embodiment, coprocessor 1338 is a special purpose processor, such as, for example, a high throughput MIC processor, a network or communication processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, or the like.

[0089] A shared cache (not shown) may be included within either processor or external to both processors and further connected to the processors via the PP interconnect so that when the processors are placed in a low power mode, either or both of the processors' local cache information may be stored in the shared cache.

[0090] Chipset 1390 may be coupled to a first bus 1316 via an interface 1396. In one embodiment, first bus 1316 may be a bus such as a Peripheral Component Interconnect (PCI) bus, or a PCI Express bus or other third generation I / O interconnect bus, although the scope of the invention is not so limited.

[0091] As shown in FIG. 7, various I / O devices 1314 may be coupled to the first bus 1316 along with a bus bridge 1318 that couples the first bus 1316 to a second bus 1320. In one embodiment, one or more additional processors 1315, such as a co-processor, a high throughput MIC processor, a GPGPU, an accelerator (e.g., a graphics accelerator or a digital signal processing (DSP) unit), a field programmable gate array, or other processor, are coupled to the first bus 1316. In one embodiment, the second bus 1320 may be a low pin count (LPC) bus. In one embodiment, various devices may be coupled to the second bus 1320, including, for example, a keyboard and / or mouse 1322, a communication device 1327, and a storage unit 1328, such as a disk drive or other mass storage device, that may contain instructions / code and data 1330. Additionally, audio I / O 1324 may be coupled to the second bus 1320. It should be noted that other architectures are possible: for example, instead of the point-to-point architecture of Figure 7, the system could implement a multi-drop bus or other such architecture.

[0092] 8 depicts a block diagram of a second, more specific, exemplary system 1400, according to one or more embodiments. Certain aspects of FIG. 7 have been omitted from FIG. 8 to avoid obscuring other aspects of FIG. 8.

[0093] Figure 8 shows that the processors 1370, 1380 may include integrated memory and I / O control logic ("CL") 1372 and 1382, respectively. Thus, the CLs 1372, 1382 include an integrated memory controller unit and include I / O control logic. Figure 8 shows that not only are the memories 1332, 1334 coupled to the CLs 1372, 1382, but also that the I / O devices 1414 are coupled to the control logic 1372, 1382. Legacy I / O devices 1415 are coupled to the chipset 1390.

[0094] FIG. 9 is a block diagram of a system on a chip (SoC) 1500 according to one or more embodiments. The dashed boxes are optional features in a more advanced SoC. In FIG. 9, an interconnect unit 1502 is coupled to an application processor 1510 including a set of one or more cores 1102A-N (including constituent cache units 1104A-N) and a shared cache unit 1106, a system agent unit 1110, a bus controller unit 1116, an integrated memory controller unit 1114, a set of one or more coprocessors 1520 that may include integrated graphics logic, image processors, audio processors, and video processors, a static random access memory (SRAM) unit 1530, a direct memory access (DMA) unit 1532, and a display unit 1540 for coupling to one or more external displays. In one embodiment, the coprocessors 1520 include special purpose processors, such as, for example, network or communication processors, compression engines, GPGPUs, high throughput MIC processors, embedded processors, or the like.

[0095] conclusion

[0096] In this disclosure, phrases such as "an embodiment," "one embodiment," and "another embodiment" are generally intended to refer to possible embodiments. These phrases are not intended to limit the present invention to the configuration of a particular embodiment. As used herein, these phrases may refer to the same or different embodiments, which may be combined into other embodiments. In light of the principles and exemplary embodiments described and illustrated herein, it will be appreciated that the illustrated embodiments may be modified in arrangement and detail without departing from the principles described and / or illustrated herein.

[0097] Also, according to the present disclosure, a device may include instructions and other data that, when accessed by a processor, cause the device to perform certain operations. For purposes of this disclosure, instructions that cause a device to perform operations may be generally referred to as software. Software and the like may also be referred to as control logic. Software used during the boot process may also be referred to as firmware. Software stored in non-volatile memory may also be referred to as firmware. Software may be configured using any suitable structure or combination of structures. Thus, terms such as program and module may be generally used to cover a broad range of software configurations, including, without limitation, application programs, subprograms, routines, functions, procedures, drivers, libraries, data structures, processes, microcode, and other types of software components. It should also be understood that a software module may include more than one component, and that these components may work together to complete the operation of the module. Also, the operations that the software causes the device to perform may include creating an operational context, instantiating certain data structures, and the like. Embodiments may be implemented as software executing on a programmable system including at least one processor, a storage system (e.g., volatile memory and / or one or more non-volatile storage elements), at least one input device, and at least one output device.

[0098] Any suitable operating environment and programming language (or combination of operating environment and programming language) may be used to implement the software components described herein. For example, program code may be implemented in a high-level procedural or object-oriented programming language, or in an assembly or machine language. The mechanisms described herein are not limited to any particular programming language. In any case, the language may be a compiled or interpreted language.

[0099] A medium that contains data and enables other components to retrieve the data may be referred to as a machine-accessible medium or machine-readable medium. Thus, an embodiment may include a machine-readable medium that includes instructions to perform some or all of the operations described herein. Such a medium may be generally referred to as an apparatus, and in particular as a program product. In one embodiment, software for multiple components is stored on one machine-readable medium. In other embodiments, two or more machine-readable media may be used to store software for one or more components. For example, instructions for one component may be stored on one medium and instructions for other components may be stored on another medium. Alternatively, some of the instructions for one component may be stored on one medium and the remaining instructions for that component (as well as instructions for other components) may be stored on one or more other media. Similarly, software described above as residing on a particular device in one embodiment may be residing on one or more other devices in other embodiments. For example, in a distributed environment, some software may be stored locally and some software may be stored remotely. Similarly, operations described above as being performed on one particular device in one embodiment may be performed by one or more other devices in other embodiments.

[0100] Other embodiments may be implemented in data and stored in a non-transitory storage medium that, when used by at least one machine, causes the at least one machine to manufacture at least one integrated circuit that performs one or more operations according to the present disclosure. Additionally, further embodiments may be implemented in a computer-readable storage medium that includes information that, when manufactured into an SoC or other processor, configures the SoC or other processor to perform one or more operations according to the present disclosure. One or more aspects of at least one embodiment may be implemented by exemplary instructions stored on a machine-readable medium that represent various logical units within a processor and that, when read into a machine, cause the machine to create the logical units to perform the techniques described herein. The instructions that represent the various logical units may be referred to as "IP cores," which may be stored on a tangible machine-readable medium and provided to various customers or manufacturing facilities to be loaded into manufacturing equipment that actually creates the logical units or processors. One or more aspects of at least one embodiment may include a machine-readable medium that includes instructions or design data that define the functionality of the structures, circuits, devices, processors, and / or systems described herein. For example, the design data may be formatted in a Hardware Description Language (HDL).

[0101] The machine-readable medium for some embodiments may include, without limitation, tangible, non-transitory storage components such as magnetic disks, optical disks, magneto-optical disks, dynamic random access memory (RAM), static RAM, read-only memory (ROM), solid-state drives (SSD), phase-change memory (PCM), etc., as well as other components including processors, controllers, and data storage facilities. For purposes of this disclosure, the term "ROM" may be used generally to refer to non-volatile memory devices such as erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash ROM, flash memory, etc.

[0102] It should also be understood that the hardware and software components illustrated herein represent functional elements that are to some extent self-contained, such that each may be designed, constructed, or updated substantially separately from the others. In alternative embodiments, the components may be implemented as hardware, software, or a combination of hardware and software to provide the functions described and illustrated herein. For example, in some embodiments, some or all of the control logic implementing some or all of the described operations may be implemented in hardware logic (e.g., as microcode in an integrated circuit chip, as a programmable gate array (PGA) in a chip, as an application specific integrated circuit (ASIC) in a chip, as other suitable types of hardware circuits in a chip, or as two or more different instances and / or combinations of multiple types of hardware logic in one or more chips). Also, terms such as "circuit" and "circuitry" may be used interchangeably herein. These terms, and terms similar to "logic," may be used to refer to analog circuitry, digital circuitry, hardwired circuitry, programmable circuitry, processor circuitry, microcontroller circuitry, hardware logic circuitry, state machine circuitry, any other type of hardware component, or any suitable combination of hardware components.

[0103] Moreover, the present teachings may be used to advantage in many different types of data processing systems. Such data processing systems may include, without limitation, accelerators, systems on chips (SoCs), wearable devices, handheld devices, smartphones, phones, entertainment devices such as audio devices, video devices, audio / video devices (e.g., television systems and set-top boxes), vehicle processing systems, personal digital assistants (PDAs), tablet computers, laptop computers, portable computers, personal computers (PCs), workstations, servers, client-server systems, distributed computing systems, supercomputers, high performance computing systems, computing clusters, mainframe computers, minicomputers, and other devices that process or transmit information. Thus, unless expressly specified or required otherwise by context, reference to any particular type of data processing system (e.g., PCs) should be understood to encompass other types of data processing systems as well. A data processing system may also be referred to as an apparatus. A component of a data processing system may also be referred to as an apparatus.

[0104] Also, unless expressly specified otherwise, components described as being coupled to each other, communicating with each other, responding to each other, or the like, need not be in continuous communication with each other or directly coupled to each other. Similarly, unless expressly specified otherwise, when a component is described as receiving data from or transmitting data to another component, the data may be transmitted or received through one or more intermediate components. Furthermore, some components of a data processing system may be implemented as adapter cards having an interface (e.g., connectors) for communicating on a bus. Alternatively, devices or components may be implemented as embedded controllers using components such as programmable or non-programmable logic devices or arrays, ASICs, embedded computers, smart cards, and the like. For purposes of this disclosure, the term "bus" includes paths that may be shared by more than two devices, as well as point-to-point paths. Similarly, terms such as "line," "pin," and the like should be understood to refer to a wire, set of wires, or other suitable conductor or set of conductors. For example, a bus may include one or more serial links, which may include one or more lanes, which may consist of one or more different signaling pairs, and changing the electrical characteristics that these conductors possess may refer to signals on the lines. Also, for purposes of this disclosure, the term "processor" refers to a hardware component capable of executing software. For example, a processor may be implemented as a central processing unit (CPU), a processing core, or other suitable type of processing element. A CPU may include one or more processing cores, and a device may include one or more CPUs.

[0105] Also, while one or more example processes have been described in terms of particular operations performed in a particular sequence, numerous modifications may be applied to these processes to derive numerous alternative embodiments of the invention. For example, alternative embodiments may include processes that use fewer than all of the disclosed operations, processes that use additional operations, and processes in which individual operations disclosed herein are combined, further divided, rearranged, or otherwise modified.

[0106] Similarly, components that have been described in exemplary embodiments as being present within other components may be arranged differently in alternative embodiments, for example, at least some of the components described above as being present in the dynamic tuning unit may not be present in the dynamic tuning unit in alternative embodiments.

[0107] Embodiments include the following examples.

[0108] Example A1 is a processor including micro-architectural facilities, a DTU circuit, and an invalid cycle counter within the DTU circuit. The invalid cycle counter indicates how many cycles were consumed while the processor was executing a program in a first execution window with the micro-architectural facilities disabled. The DTU circuit further includes a valid cycle counter indicating how many cycles were consumed while the processor was executing a program in a second execution window with the micro-architectural facilities enabled. The DTU circuit further includes a PEU circuit that automatically determines whether the processor achieved worse performance in the second execution window compared to the first execution window based on the invalid cycle counter and the valid cycle counter. The processor further comprises an evaluation table having a utility state for the selected address, where (a) the utility state is updated by the PEU circuit to indicate worse performance in response to a determination that the processor achieved worse performance in a second execution window with the micro-architectural features enabled compared to a first execution window with the micro-architectural features disabled, and (b) the utility state is updated by the PEU circuit to indicate a confirmed bad state in response to multiple successive determinations that the processor achieved worse performance with the micro-architectural features enabled after at least two iterations of the execution window with the micro-architectural features enabled. The DTU circuit further comprises a TIU circuit that automatically disables the micro-architectural features for the selected address in a subsequent execution window in response to the utility state for the selected address in the evaluation table indicating a confirmed bad state.

[0109] Example A2 is the processor of Example A1, where at least a portion of the DTU circuitry resides within the microarchitectural features.

[0110] Example A3 is the processor of Example A1, where in response to a determination that the processor achieved better performance in a second execution window with the micro-architectural features enabled compared to a first execution window with the micro-architectural features disabled, the utility state for the selected address is updated by the PEU circuit to indicate the better performance. And, in response to a plurality of successive determinations that the processor achieved better performance with the micro-architectural features enabled after iterations of at least two execution windows with the micro-architectural features enabled, the utility state for the selected address is updated by the PEU circuit to indicate a confirmed good state. And, in response to the utility state for the selected address in the evaluation table indicating a confirmed good state, the TIU circuit automatically enables the micro-architectural features for the selected address in a subsequent execution window. Example A3 may also include the features of Example A2.

[0111] Example A4 is the processor of Example A1, where the DTU circuitry includes an FSM that controls updating of a serviceability state for the selected address, the FSM providing a determined bad state, a determined good state, and at least three undetermined states. The undetermined states include a neutral state, a possibly good state, and a possibly bad state. Also, the serviceability state for the selected address starts in a neutral state, and the serviceability state for the selected address progresses from (a) a neutral state to a possibly bad state, and (b) a possibly bad state to a determined bad state in response to successively updating the serviceability state. Example A4 may also include any one or more features of Examples A2-A3.

[0112] Example A5 is the processor of example A1, wherein each execution window includes a predetermined number of retired instructions. Example A5 may also include any one or more features of examples A2-A4.

[0113] Example A6 is the processor of Example A1, wherein the DTU circuitry includes a predetermined significance threshold that the PEU circuitry uses to determine whether the processor achieves significantly worse performance in a second execution window with the micro-architectural features enabled compared to a first execution window with the micro-architectural features disabled. Example A6 may also include any one or more of the features of Examples A2-A5.

[0114] Example A7 is the processor of Example A1, wherein the DTU circuit has a predetermined involvement threshold that the PEU circuit uses to determine whether an instruction at the selected address was executed at least a threshold number of times during the second execution window. Also, the PEU circuit updates the utility state for the selected address to exhibit worse performance with micro-architectural features enabled only if the selected address was executed at least the threshold number of times during the second execution window. Example A7 may also include any one or more features of Examples A2-A6.

[0115] Example A8 is the processor of example A7, wherein the evaluation table includes an involvement counter for the selected address that is incremented in response to executing an instruction at the selected address, and the PEU circuit uses the involvement counter and the predetermined involvement threshold to determine whether the instruction at the selected address has executed at least a threshold number of times during the second execution window.

[0116] Example B1 is a data processing system including a RAM, a processor coupled to the RAM, microarchitectural facilities in the processor, a DTU circuit in the processor, and an invalid cycle counter in the DTU circuit. The invalid cycle counter indicates how many cycles were consumed while the processor was executing a program in a first execution window with the microarchitectural facilities disabled. The DTU circuit also includes a valid cycle counter indicating how many cycles were consumed while the processor was executing a program in a second execution window with the microarchitectural facilities enabled. The DTU circuit further includes a PEU circuit that automatically determines whether the processor achieved worse performance in the second execution window compared to the first execution window based on the invalid cycle counter and the valid cycle counter. The processor further includes an evaluation table that includes a utility state for a selected address. In response to a determination that the processor achieved worse performance in a second execution window with the micro-architectural features enabled compared to a first execution window with the micro-architectural features disabled, the utility state is updated by the PEU circuit to indicate worse performance, and in response to multiple successive determinations that the processor achieved worse performance with the micro-architectural features enabled after at least two iterations of the execution window with the micro-architectural features enabled, the utility state is updated by the PEU circuit to indicate a confirmed bad condition. The DTU circuit further includes a TIU circuit that automatically disables the micro-architectural features for the selected addresses in the subsequent execution window in response to the utility state for the selected addresses in the evaluation table indicating a confirmed bad condition.

[0117] Example B2 is the data processing system of Example B1, where at least a portion of the DTU circuitry resides within a micro-architectural facility.

[0118] Example B3 is the data processing system of Example B1, where in response to a determination that the processor achieved better performance in a second execution window with the micro-architectural features enabled compared to a first execution window with the micro-architectural features disabled, the utility state for the selected address is updated by the PEU circuit to indicate the better performance. And, in response to a plurality of successive determinations that the processor achieved better performance with the micro-architectural features enabled after iterating through at least two execution windows with the micro-architectural features enabled, the utility state for the selected address is updated by the PEU circuit to indicate a confirmed good state. And, in response to the utility state for the selected address in the evaluation table indicating a confirmed good state, the TIU circuit automatically enables the micro-architectural features for the selected address in a subsequent execution window. Example B3 may also include the features of Example B2.

[0119] Example B4 is the data processing system of Example B1, where the DTU circuitry includes an FSM that controls updating of the serviceability state for the selected address, the FSM providing a determined bad state, a determined good state, and at least three undetermined states. The undetermined states include a neutral state, a possibly good state, and a possibly bad state. The serviceability state for the selected address starts in a neutral state, and the serviceability state for the selected address reaches the determined bad state in response to successively updating the serviceability state from (a) the neutral state to the possibly bad state, and (b) the possibly bad state to the determined bad state. Example B4 may also include any one or more features of Examples B2-B3.

[0120] Example B5 is the data processing system of example B1, wherein each execution window includes a predetermined number of retired instructions. Example B5 may also include any one or more features of examples B2-B4.

[0121] Example B6 is the data processing system of Example B1, wherein the DTU circuitry includes a predetermined significance threshold that the PEU circuitry uses to determine whether the processor achieves significantly worse performance in a second execution window with the micro-architectural features enabled compared to a first execution window with the micro-architectural features disabled. Example B6 may also include any one or more of the features of Examples B2-B5.

[0122] Example B7 is the data processing system of Example B1, wherein the DTU circuit has a predetermined involvement threshold used by the PEU circuit to determine whether an instruction at the selected address was executed at least a threshold number of times during the second execution window, and the PEU circuit updates the utility state for the selected address to exhibit worse performance with micro-architectural features enabled only if the selected address was executed at least the threshold number of times during the second execution window. Example B7 may also include any one or more features of Examples B2-B6.

[0123] Example B8 is the data processing system of example B7, wherein the evaluation table includes an involvement counter for the selected address that is incremented in response to executing an instruction at the selected address, and the PEU circuit uses the involvement counter and the predetermined involvement threshold to determine whether the instruction at the selected address has executed at least a threshold number of times during the second execution window.

[0124] Example C1 is a method performed on a processor including micro-architectural features and DTU circuitry. The method includes (a) executing a program in a first execution window with the micro-architectural features disabled and (b) executing a program in a second execution window with the micro-architectural features enabled. The method further includes (a) the DTU circuitry automatically determining whether the processor achieved worse performance in the second execution window compared to the first execution window, (b) updating a utility state for selected addresses of the program to indicate worse performance in response to determining that the processor achieved worse performance in the second execution window, (c) automatically updating the utility state for the selected addresses to indicate a confirmed bad state in response to multiple successive determinations that the processor achieved worse performance with the micro-architectural features enabled, and (d) automatically disabling the micro-architectural features for the selected addresses of the execution window after the second execution window in response to the utility state for the selected addresses indicating a confirmed bad state.

[0125] Example C2 is the method of Example C1, in which the step of automatically determining whether the processor achieved worse performance in a second execution window compared to the first execution window is performed by a PEU circuit in the DTU circuit, the step of automatically updating a serviceability state for the selected address to indicate a determined bad condition is also performed by the PEU circuit, and the step of automatically disabling micro-architectural features for the selected address of the execution window after the second execution window is also performed by a TIU circuit in the DTU circuit.

[0126] Example C3 is the method of Example C1, further comprising: (a) updating a serviceability state for the selected address to indicate the better performance in response to a determination that the processor achieved better performance in a second execution window with the micro-architectural features enabled compared to a first execution window with the micro-architectural features disabled, (b) updating a serviceability state for the selected address to indicate a confirmed good state in response to a plurality of successive determinations that the processor achieved better performance with the micro-architectural features enabled after at least two iterations of the execution window with the micro-architectural features enabled, and (c) automatically enabling the micro-architectural features for the selected address in a subsequent execution window in response to the serviceability state for the selected address indicating the confirmed good state. Example C3 may also include the features of Example C2.

[0127] Example C4 is the method of Example C1, further comprising: (a) using a predetermined involvement threshold to automatically determine whether an instruction at the selected address was executed at least a threshold number of times during the second execution window, and (b) automatically updating a utility state for the selected address to exhibit worse performance with micro-architectural features enabled only if the selected address was executed at least the threshold number of times during the second execution window. Example C4 may also include any one or more features of Examples C2-C3.

[0128] In view of the wide variety of beneficial variations that may be readily derived from the exemplary embodiments described herein, this detailed description is intended to be illustrative only and should not be construed as limiting the scope of coverage. [Other possible items] [Item 1] 1. A processor comprising: A microarchitectural mechanism; A dynamic tuning unit (DTU) circuit; an invalid cycle counter in the DTU circuit, the invalid cycle counter indicating how many cycles were consumed while the processor was executing a program in a first execution window with the micro-architectural facilities disabled; and a valid cycle counter in the DTU circuitry, the valid cycle counter indicating how many cycles were consumed while the processor was executing a program in a second execution window with the micro-architectural facilities enabled; and a performance evaluation unit (PEU) circuit in the DTU circuit, the PEU circuit automatically determining whether the processor achieved worse performance in the second execution window compared to the first execution window based on the invalid cycle counter and the valid cycle counter; an evaluation table within the processor, the evaluation table having a utility state for a selected address, (a) the utility state is updated by the PEU circuit to indicate worse performance in response to a determination that the processor achieved worse performance in the second execution window with the micro-architectural features enabled compared to the first execution window with the micro-architectural features disabled, and (b) the utility state is updated by the PEU circuit to indicate a confirmed bad state in response to multiple successive determinations that the processor achieved worse performance with the micro-architectural features enabled after at least two iterations of the execution window with the micro-architectural features enabled; a tuning execution unit (TIU) circuit within the DTU circuit, the TIU circuit automatically disabling the microarchitectural facility for the selected address in a subsequent execution window in response to the availability state for the selected address in the evaluation table indicating the determined fault condition; Equipped with a processor. [Item 2] 2. The processor of claim 1, wherein at least a portion of the DTU circuitry resides within the microarchitectural facilities. [Item 3] in response to determining that the processor achieved better performance in the second execution window with the micro-architectural features enabled as compared to the first execution window with the micro-architectural features disabled, the utility state for the selected address is updated by the PEU circuit to indicate better performance; updating, by the PEU circuit, the usefulness state for the selected address to indicate a determined good state in response to a plurality of successive determinations that the processor achieved better performance with the microarchitectural features enabled after at least two iterations of execution windows with the microarchitectural features enabled; the TIU circuitry automatically enables the micro-architectural facility for the selected address in a subsequent execution window in response to the availability status for the selected address in the evaluation table indicating the determined good condition. Item 1. The processor of item 1. [Item 4] the DTU circuitry includes a finite state machine (FSM) that controls updating of the serviceability state for the selected address, the FSM providing the determined bad state, the determined good state, and at least three undetermined states; The undetermined state includes a neutral state, a possibly good state, and a possibly bad state; the availability state for the selected address begins in the neutral state; the serviceability state for the selected address (a) reaches the confirmed serviceability state from the neutral state to the possibly bad state and (b) reaches the confirmed serviceability state from the possibly bad state to the confirmed serviceability state in response to successively updating the serviceability state from the possibly bad state to the confirmed serviceability state. Item 1. The processor of item 1. [Item 5] 2. The processor of claim 1, wherein each execution window includes a predetermined number of retired instructions. [Item 6] 2. The processor of claim 1, wherein the DTU circuit has a predetermined significance threshold that the PEU circuit uses to determine whether the processor achieves significantly worse performance in the second execution window with the microarchitectural features enabled compared to the first execution window with the microarchitectural features disabled. [Item 7] 2. The processor of claim 1, wherein the DTU circuit has a predetermined involvement threshold used by the PEU circuit to determine whether an instruction at the selected address has been executed at least a threshold number of times during the second execution window, and the PEU circuit updates the utility state for the selected address to indicate poorer performance with the micro-architectural features enabled only if the selected address has been executed at least the threshold number of times during the second execution window. [Item 8] 8. The processor of claim 7, wherein the evaluation table has an involvement counter for the selected address that is incremented in response to executing the instruction at the selected address, and the PEU circuit uses the involvement counter and the predetermined involvement threshold to determine whether the instruction at the selected address has been executed at least the threshold number of times during the second execution window. [Item 9] Random Access Memory (RAM) a processor coupled to the RAM; a microarchitectural facility within said processor; A dynamic tuning unit (DTU) circuit within the processor; an invalid cycle counter in the DTU circuit, the invalid cycle counter indicating how many cycles were consumed while the processor was executing a program in a first execution window with the micro-architectural facilities disabled; and a valid cycle counter in the DTU circuitry, the valid cycle counter indicating how many cycles were consumed while the processor was executing a program in a second execution window with the micro-architectural facilities enabled; and a performance evaluation unit (PEU) circuit in the DTU circuit, the PEU circuit automatically determining whether the processor achieved worse performance in the second execution window compared to the first execution window based on the invalid cycle counter and the valid cycle counter; an evaluation table within the processor, the evaluation table having a utility state for a selected address, where (a) the utility state is updated by the PEU circuit to indicate worse performance in response to a determination that the processor achieved worse performance in the second execution window with the micro-architectural features enabled compared to the first execution window with the micro-architectural features disabled, and (b) the utility state is updated by the PEU circuit to indicate a confirmed bad state in response to multiple successive determinations that the processor achieved worse performance with the micro-architectural features enabled after at least two iterations of execution windows with the micro-architectural features enabled; a tuning execution unit (TIU) circuit within the DTU circuit, the TIU circuit automatically disabling the microarchitectural facility for the selected address in a subsequent execution window in response to the availability state for the selected address in the evaluation table indicating the determined fault condition; A data processing system comprising: [Item 10] 10. The data processing system of claim 9, wherein at least a portion of the DTU circuitry resides within the microarchitectural facility. [Item 11] in response to determining that the processor achieved better performance in the second execution window with the micro-architectural features enabled as compared to the first execution window with the micro-architectural features disabled, the utility state for the selected address is updated by the PEU circuit to indicate better performance; updating, by the PEU circuit, the usefulness state for the selected address to indicate a determined good state in response to a plurality of successive determinations that the processor achieved better performance with the microarchitectural features enabled after at least two iterations of execution windows with the microarchitectural features enabled; the TIU circuitry automatically enables the micro-architectural facility for the selected address in a subsequent execution window in response to the availability status for the selected address in the evaluation table indicating the determined good condition. 10. The data processing system according to item 9. [Item 12] the DTU circuitry includes a finite state machine (FSM) that controls updating of the serviceability state for the selected address, the FSM providing the determined bad state, the determined good state, and at least three undetermined states; The undetermined state includes a neutral state, a possibly good state, and a possibly bad state; the availability state for the selected address begins in the neutral state; the serviceability state for the selected address (a) reaches the confirmed serviceability state from the neutral state to the possibly bad state and (b) reaches the confirmed serviceability state from the possibly bad state to the confirmed serviceability state in response to successively updating the serviceability state from the possibly bad state to the confirmed serviceability state. 10. The data processing system according to item 9. [Item 13] 10. The data processing system of claim 9, wherein each execution window includes a predetermined number of retired instructions. [Item 14] 10. The data processing system of claim 9, wherein the DTU circuit has a predetermined significance threshold that the PEU circuit uses to determine whether the processor achieves significantly worse performance in the second execution window with the microarchitectural features enabled compared to the first execution window with the microarchitectural features disabled. [Item 15] 10. The data processing system of claim 9, wherein the DTU circuit has a predetermined involvement threshold used by the PEU circuit to determine whether an instruction at the selected address has been executed at least a threshold number of times during the second execution window, and the PEU circuit updates the utility state for the selected address to indicate poorer performance with the micro-architectural features enabled only if the selected address has been executed at least the threshold number of times during the second execution window. [Item 16] 16. The data processing system of claim 15, wherein the evaluation table has an involvement counter for the selected address that is incremented in response to executing the instruction at the selected address, and the PEU circuit uses the involvement counter and the predetermined involvement threshold to determine whether the instruction at the selected address has been executed at least the threshold number of times during the second execution window. [Item 17] executing, on a processor including micro-architectural features and dynamic tuning unit (DTU) circuitry, (a) a program in a first execution window with the micro-architectural features disabled, and (b) a program in a second execution window with the micro-architectural features enabled; the DTU circuit automatically determining whether the processor achieved poorer performance in the second execution window compared to the first execution window; responsive to determining that the processor achieved worse performance in the second execution window, updating a utility state for selected addresses of the program to indicate worse performance; automatically updating the usefulness state for the selected address to indicate a determined bad condition in response to a plurality of successive determinations that the processor achieved worse performance with the micro-architectural features enabled; automatically disabling the microarchitectural mechanism for the selected address of an execution window after the second execution window in response to the availability state for the selected address indicating the determined fault condition; A method comprising: [Item 18] The step of automatically determining whether the processor achieves worse performance in the second execution window compared to the first execution window is performed by a performance evaluation unit (PEU) circuit in the DTU circuit; the step of automatically updating the availability status for the selected address to indicate a confirmed fault condition is performed by the PEU circuit; After the second execution window, the step of automatically disabling the microarchitectural features for the selected address of the execution window is performed by a tuning execution unit (TIU) circuit within the DTU circuit. Item 18. The method according to item 17. [Item 19] in response to determining that the processor achieved better performance in the second execution window with the micro-architectural features enabled as compared to the first execution window with the micro-architectural features disabled, updating the utility state for the selected address to indicate better performance; updating the usefulness state for the selected address to indicate a determined goodness state in response to a plurality of successive determinations that the processor achieved better performance with the micro-architectural features enabled after at least two iterations of execution windows with the micro-architectural features enabled; automatically enabling the micro-architectural mechanism for the selected address in a subsequent execution window in response to the availability state for the selected address indicating the determined good condition; Item 18. The method of item 17, further comprising: [Item 20] using a predetermined involvement threshold to automatically determine whether an instruction at the selected address has been executed at least a threshold number of times during the second execution window; automatically updating the utility state for the selected address to indicate poorer performance with the micro-architectural features enabled only if the selected address has been executed at least the threshold number of times during the second execution window; Item 18. The method of item 17, further comprising:

Claims

1. 1. A processor comprising: A first cache; a second cache coupled to the first cache; an arithmetic logic unit (ALU) for performing arithmetic operations; a circuit coupled to the ALU, after the processor executes a workload during a first execution window with micro-architectural facilities disabled and during a second execution window with the micro-architectural facilities enabled, the circuit comprising: determining whether the processor achieved better performance in the second execution window compared to the first execution window based on a number of cycles required; In response to determining that the processor achieved the better performance in the second execution window, update a state of an address associated with an instruction toward a good final state, and when the state of the address reaches the good final state, the processor enables the micro-architectural facility for the address associated with the instruction. Circuit and A processor comprising:

2. 2. The processor of claim 1, wherein the circuitry is further configured to update the state of the address associated with the instruction to the good final state in response to determining at least twice consecutively that the processor achieved the better performance with the micro-architectural facilities enabled.

3. The processor of claim 1 or 2, wherein the circuitry comprises a finite state machine.

4. a memory for storing a table, the table including a plurality of entries, each of the plurality of entries comprising: an address field for storing address information of the address of the instruction; a status field storing the status of the address of the instruction; a counter field storing an engagement count associated with said instruction; Includes A processor according to any one of claims 1 to 3.

5. The processor of claim 4 , wherein the circuitry periodically resets at least the state fields of the plurality of entries in the table.

6. The processor of claim 4 , wherein the circuitry initializes the state of the address of the instruction to a neutral state.

7. The circuitry determines the state of the address associated with the instruction by: The good final state, the good state, the neutral state, the bad state, and the bad final state The processor according to claim 1 , further comprising: a processor for controlling the input / output terminals of the input / output terminals to be in one of the following states:

8. 8. The processor of claim 1, further comprising a retired instruction counter that maintains a count of retired instructions.

9. a previous cycle counter that maintains a first count of cycles for executing instructions in the first execution window; a current cycle counter that maintains a second count of cycles for executing instructions in the second execution window; The processor of claim 1 , further comprising:

10. 10. The processor of claim 9, wherein the circuitry determines the better performance using the first count of cycles to execute instructions and the second count of cycles to execute instructions.

11. determining, with circuitry of the processor, whether the processor achieved better performance in a second execution window compared to a first execution window based on a number of cycles required, where micro-architectural features of the processor are disabled for the first execution window and enabled for the second execution window; updating a state of an address associated with an instruction toward a good final state in response to determining that the processor achieved the better performance in the second execution window; enabling the microarchitectural facilities for the address associated with the instruction when the state of the address reaches the good final state; A method comprising:

12. 12. The method of claim 11, further comprising: in response to determining at least twice consecutively that the processor achieved the better performance with the micro-architectural facilities enabled, updating the state of the address associated with the instruction to the good final state.

13. The method further comprises storing a table in a memory, the table including a plurality of entries, each of the plurality of entries comprising: an address field for storing address information of the address of the instruction; a status field storing the status of the address of the instruction; a counter field storing an engagement count associated with said instruction; Includes 13. The method according to claim 11 or 12.

14. 14. The method of claim 13, further comprising periodically resetting at least the status fields of the plurality of entries of the table.

15. 14. The method of claim 13, further comprising initializing the state of the address of the instruction to a neutral state.

16. When executed by a processor, the processor: causing the processor to determine whether a second execution window achieved better performance compared to a first execution window based on a number of cycles required, wherein micro-architectural features of the processor are disabled for the first execution window and enabled for the second execution window; updating a state of an address associated with an instruction toward a good final state in response to determining that the processor achieved the better performance in the second execution window; enabling said microarchitectural mechanisms for said address associated with said instruction when said state of said address reaches said good final state A non-transitory storage machine-readable medium comprising at least one instruction.

17. The at least one instruction, when executed by the processor, causes the processor to: updating the state of the address associated with the instruction to the good final state in response to determining at least twice consecutively that the processor achieved the better performance with the micro-architectural features enabled.

20. The non-transitory storage machine-readable medium of claim 16.

18. The at least one instruction, when executed by the processor, causes the processor to store in memory a table, the table including a plurality of entries, each of the plurality of entries comprising: an address field for storing address information of the address of the instruction; a status field storing the status of the address of the instruction; a counter field storing an engagement count associated with said instruction; Includes 18. A non-transitory storage machine-readable medium according to claim 16 or 17.

19. 20. The non-transitory storage machine-readable medium of claim 18, wherein the at least one instruction, when executed by the processor, causes the processor to periodically reset at least the state fields of the plurality of entries in the table.

20. 20. The non-transitory storage machine-readable medium of claim 18, wherein the at least one instruction, when executed by the processor, causes the processor to initialize the state of the address of the instruction to a neutral state.

Images