Dynamic performance biasing in processors

Abstract

Dynamic performance biasing in a processor is disclosed. Techniques are provided in embodiments for dynamically biasing the performance of logical processors in cores of a processor. One embodiment includes identifying a first logical processor associated with a first thread of an application and a second logical processor associated with a second thread, obtaining a first thread preference indicator and a second thread preference indicator associated with the first thread and the second thread, respectively, calculating a first relative performance bias value for the first logical processor based at least in part on a relative relationship of the first thread preference indicator to the second thread preference indicator, and adjusting a performance bias of the first logical processor based on the first relative performance bias value. Embodiments can further include increasing the performance bias of the first logical processor based at least in part on the first relative performance bias value indicating a first performance preference higher than a second performance preference.

Description

TECHNICAL FIELD

[0001] This disclosure relates generally to the field of computing architecture, and more particularly to dynamic performance biasing in a processor. BACKGROUND

[0002] Simultaneous multithreading (SMT) is a processing technique employed by superscalar computer processing units (CPUs) with hardware multithreading. SMT enables multiple threads to run simultaneously on the logical processors of the same physical core in a CPU. Instructions are fetched from multiple threads in each execution cycle. This can be accomplished by sharing the different pipeline resources of the core. Instructions fetched from multiple threads can be executed or acted upon by any pipeline stage during the same cycle. Generally, the sharing of hardware resources is unbiased, and thus, such resources are equally shared among concurrently executing threads. Similarly, execution cycles are typically equally divided among all logical processors on an SMT core. As computer architecture has evolved, ongoing efforts have been made to further improve the efficiency of processing elements and optimize the performance of processing elements. BRIEF DESCRIPTION OF DRAWINGS

[0003] For a more complete understanding of the present disclosure, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings in which like numerals represent like parts, in which:

[0004] Figure 1 is a simplified block diagram of a computing system for dynamic performance biasing of a logical processor in accordance with certain embodiments;

[0005] Figure 2 is a simplified flowchart of potential operations associated with dynamic performance biasing of a logical processor in accordance with certain embodiments;

[0006] Figure 3 is a simplified flowchart of further potential operations associated with dynamic performance biasing of a logical processor in accordance with certain embodiments;

[0007] Figure 4 is a block diagram depicting an example of dynamic performance biasing of a logical processor in accordance with certain embodiments;

[0008] Figure 5 is a simplified flowchart of further potential operations associated with dynamic performance biasing of a logical processor in accordance with certain embodiments;

[0009] Figure 6 is a simplified flowchart of further potential operations associated with scheduling threads with dynamic performance biasing of a logical processor;

[0010] Figures 7A-7B is a block diagram depicting an example of scheduling threads with dynamic performance biasing of a logical processor;

[0011] Figure 8 is a simplified block diagram of another example computing system for dynamic performance biasing of a core in accordance with certain embodiments;

[0012] Figure 9 is a simplified flow diagram of potential operations associated with dynamic performance biasing of a core and a logical processor in accordance with certain embodiments;

[0013] Figure 10 is a simplified flow diagram of further potential operations associated with dynamic performance biasing of a core and a logical processor in accordance with certain embodiments;

[0014] Figure 11 is a simplified flow diagram of further potential operations associated with dynamic performance biasing of a core and a logical processor in accordance with certain embodiments;

[0015] Figure 12 is a simplified flow diagram of further potential operations associated with scheduling threads with dynamic performance biasing of a core;

[0016] Figures 13A-13B is a block diagram depicting an example of scheduling threads with dynamic performance biasing of a core;

[0017] Figure 14 is a simplified block diagram of an embodiment of a virtualized computing system for dynamic performance biasing of a core and / or a logical processor in accordance with certain embodiments;

[0018] Figure 15 is a block diagram of a register architecture in accordance with certain embodiments;

[0019] Figure 16A is a block diagram illustrating an exemplary in-order pipeline, as well as an exemplary register renaming, out-of-order issue / execution pipeline in accordance with certain embodiments;

[0020] Figure 16B is a block diagram illustrating an exemplary embodiment of an in-order architecture core to be included in a processor, as well as an exemplary register renaming, out-of-order issue / execution architecture core to be included in a processor in accordance with certain embodiments;

[0021] Figures 17A-17B is a block diagram illustrating a more specific exemplary in-order core architecture that will be one of several logical blocks (including other cores of the same or different type) in a chip in accordance with certain embodiments;

[0022] Figure 18is a block diagram of a processor that can have more than one core, that can have an integrated memory controller, and that can have an integrated graphics device, according to some embodiments;

[0023] Figures 19-22 is a block diagram of an exemplary computer architecture, according to some embodiments; and

[0024] Figure 23 is a block diagram of converting binary instructions in a source instruction set to binary instructions in a target instruction set using a software instruction translator, according to some embodiments. DETAILED DESCRIPTION

[0025] The following disclosure provides various possible embodiments or examples for implementing the features disclosed in this specification. The features relate to a computing system for dynamic performance biasing based on thread characteristics. Dynamic performance biasing can be implemented using hardware and software. A hint can be provided to the computing system hardware by an actor, where the hint indicates a performance preference for a particular thread or logical processor associated with the thread. Such actors can include, but are not necessarily limited to, an operating system, a system application, a user application, and / or a setting changed by a user. The hint can be provided in the form of a special setting or thread preference indicator programmed for the thread. The thread preference indicator can be used to calculate a relative performance bias value for each logical processor associated with the thread for which the thread preference indicator was provided. Resources can be dynamically and efficiently allocated and / or partitioned based on one or more of the calculated performance bias values.

[0026] In other embodiments, other types of performance bias values can be calculated during processing, and these other types of performance bias values can be used to dynamically bias other types of components during processing. For example, in a multi-core processor architecture, a core relative performance bias can be calculated from a thread preference indicator, and the core relative performance bias can be used to dynamically allocate resources shared among cores. In at least some embodiments, a multi-core processor can be configured for both dynamic core performance biasing of resources shared among cores and dynamic logical processor performance biasing of resources shared among logical processors of a core. In still further embodiments, in a multi-socket architecture, a processor performance bias value for a processor can be calculated from a thread preference indicator and potentially from a core performance bias value. The processor performance bias value can be used to dynamically allocate resources shared among processors. In at least some embodiments, a multi-core processor can be configured for both dynamic processor performance biasing of resources shared among processors and dynamic core performance biasing of resources shared among cores of a processor and / or dynamic logical processor performance biasing of resources shared among logical processors of a core.

[0027] To illustrate certain example techniques for computing systems using dynamic logic processor performance biasing and other performance biases (e.g., cores, processors), it is important to understand the activities that may be occurring in such systems with multiple threads executing concurrently, and the computer system implemented to provide indications of performance preferences for the threads of an application. The following basic information can be considered as the basis upon which this disclosure is appropriately interpreted. For ease of reference, it should be noted that "dynamic performance biasing" is also referred to herein as "performance biasing," as it is understood that any such biasing is performed dynamically.

[0028] Simultaneous multithreading (SMT) enables multiple threads to run concurrently on the same physical core of a logical processor. During execution, an application can instantiate multiple threads with varying degrees of importance or criticality to the application. While SMT achieves higher efficiency than other types of multithreading such as block and interleaved multithreading, hardware typically lacks the ability to follow actual operating system and software biases or preferences, and therefore, hardware can only estimate relative performance.

[0029] However, at least one new technology, provided by Intel, Speed ​​Shift technology allows applications to provide hardware with indications or hints regarding the energy performance preferences of logical processors within an SMT core. In this specific technology, this hint can be provided via the Energy Performance Preference (EPP) field in the IA32_HWP_REQUEST_MSR register of each logical processor. However, the EPP field is used to calculate the overall performance state of all cores in the domain, and threads running on the same core are treated equally. Therefore, logical processors associated with important or even critical threads cannot leverage core design and SMT to enhance or optimize performance when the application needs it most.

[0030] Currently, resources within an SMT core are shared equally among all logical processors. Generally, each logical processor gets an equal share of core resources and an equal share of the portion of shared resources allocated to the core. Without software assistance, hardware allocates resources to each logical processor based on hardware control flow, which can result in equal allocation of resources. For example, hardware does not provide any preference to logical processors in different pipeline stages. Additionally, the share of each core unit (e.g., core-level cache, shared cache, bus, memory resources such as preachers, access ports, internal registers, other out-of-order microarchitectural features, etc.) is used equally by different logical processors running on the same core. Execution cycles are also divided equally among all logical processors on a core. Furthermore, pipeline components run at the same speed, which is increased or decreased dynamically as needed and when needed, but not adjusted based on performance preference of a particular thread. Such components include, but are not necessarily limited to, a decoder unit, a rename unit, an allocator unit, a scheduler unit, an execution unit, and / or a memory access unit. Additionally, in some microarchitectures, thread scheduling on a core pipeline is divided among threads of the core. Hardware scheduling attempts to allocate the same amount of compute resources to all threads of a hardware core.

[0031] Turning to Figure 1Embodiments of a computing system 100 configured for logical processor (LP) performance biasing can address the above (and more) issues associated with computing systems having one or more simultaneous multithreading cores. An example computing system 100 can include one or more system applications (e.g., 120), one or more user applications (e.g., 130), and an operating system 140, any or all of which can be stored in a memory 188. The system and user applications can include thread preference selectors (e.g., 122, 132, 142) and thread schedulers (e.g., 124, 134, 144). A thread preference indicator 150 can be stored in any suitable storage or memory, such as a hardware register, and can be fetched by a processor 170. Cores of the processor 170, such as core A 160A and core B 160B, can each include logical processor (LP) computation circuitry (e.g., 162A, 162B) and a plurality of logical processors (e.g., 164A(1), 164A(2), 164B(1), 164B(2)) with respective threads (e.g., 165A(1), 165A(2), 165B(1), 165B(2)). Hardware resources dedicated to a core, such as core A resources 190A and core B resources 190B, can include, for example, core-dedicated caches (e.g., 192A, 192B). Shared hardware resources 180 can be shared among the cores and can include a shared cache 182, a bus interface 184, and a memory 186. In at least one embodiment, a memory 188 is a portion of the memory 186, which can be a main memory (e.g., random access memory (RAM)) of the computing system 100. Storage (e.g., hard disks, solid state drives, etc.) for storing data and code that can be provisioned in the computing system 100 is not shown in FIG. 1. Other shared hardware resources to which performance biasing can be applied can include, but are not necessarily limited to, internal registers, access ports, out-of-order microarchitectural features, etc. Figure 1

[0032] Embodiments of the computing system 100 can exploit differences in thread preference information across different logical processors in the same SMT core (e.g., 160A, 160B) and enhance resource sharing across the logical processors within a core based on thread performance preferences (also referred to herein as "thread preferences"). In one example, thread preference information for the logical processors in an SMT core can be based on speed movement energy performance preference (EPP) settings. It should be appreciated, however, that any suitable technique capable of providing thread preference information (e.g., in the form of a thread preference indicator) for each logical processor, whether currently available or subsequently developed, can be exploited by the hardware to efficiently manage resources among the logical processors within an SMT core and to provide performance to the associated application that is most in need of performance. ​​

[0033] In embodiments, the core reads a respective thread preference indicator 150 for each logical processor of the core. The thread preference indicator can be programmed, configured, or otherwise set by, for example, a user application, an operating system, a system application, or a user. In at least some embodiments, the operating system enables the thread preference indicator (which can be set by a user application, system application, user, or operating system) to be suitably stored, for example, in a hardware register. The thread preference indicator can be based on thread characteristics (e.g., priority, importance, utilization, etc.) of threads running on the logical processor, as well as the importance of the logical processor to the associated application. Additionally, the priority or importance of the application itself can also be considered when programming the thread preference indicator. The core merges the thread preference indicators assigned to it for its logical processors, and computes a relative performance bias value for each logical processor based on the relative relationship of the thread preference indicators. These relative performance bias values represent a proportion of the performance bias required for each logical processor. Hardware adjusts the performance bias for each logical processor based on its relative performance bias value. More specifically, the hardware can dynamically adjust the core hardware resource usage, shared hardware resource usage, speed (i.e., utilization) of different components in the execution cycle and pipeline for each logical processor.

[0034] A computing system, such as computing system 100, for performance bias across logical processors within a core can provide some advantages. Hardware can utilize thread preference information differences to efficiently manage resources among logical processors within an SMT core, and enhance the performance of the associated application that most needs performance. By using each logical processor thread preference information, hardware can speculatively bias the performance of logical processors in an SMT core. For example, a logical processor running a thread programmed to have a higher performance bias as indicated by the thread's thread preference indicator (e.g., a high-priority thread such as a download or upload in a file transfer application) can be given a greater share of hardware resources, execution cycles, and / or component speeds than another logical processor running a thread programmed to have a lower performance bias as indicated by the thread's thread preference indicator (e.g., a low-priority thread such as a download or upload in the background of a user interactive application). Conversely, a logical processor running a thread programmed to have a lower performance bias as indicated by the thread's thread preference indicator (e.g., a low-priority or less important thread) can be given a smaller share of hardware resources, execution cycles, and / or component speeds than another logical processor running a thread programmed to have a higher performance bias as indicated by the thread's thread preference indicator (e.g., a high-priority or more important thread).

[0035] In at least one embodiment, hardware can utilize thread preference indicators across different logical processors within a core by calculating a logical processor (LP) performance bias value for each logical processor and biasing resource availability and performance to the logical processor(s) with the highest (LP) performance bias value. The logical processor performance bias value for a particular logical processor can be calculated based on the thread preference indicator associated with that particular logical processor relative to the thread preference indicators associated with other logical processors in the same core. This approach can result in better responsiveness and application experience.

[0036] A brief discussion is now provided regarding some of the possible infrastructure that can be included in computing system 100. A variety of types of software components can be provided on computing system 100. For example, system application 120, user application 130, and operating system 140 are all examples of software provisioned on computing system 100. A thread preference selector (e.g., 122, 132, and 142) can be provided for each software component. In at least one embodiment, a thread preference selector can be implemented as software that allows an operating system, system or user application, and / or a user of an application to select and program, configure, or otherwise set a thread preference indicator 150 for threads associated with an application. In at least one embodiment, a single thread preference indicator can be set for each thread of an application to indicate the performance preference of the thread.

[0037] In at least one embodiment, thread preference indicators 150 can be stored in any suitable storage structure, including but not limited to: a machine state register (MSR), a control register (e.g., general purpose or specialized), a configuration register, or a status register. In one possible non-limiting example, a thread preference indicator can be stored in an energy performance preference field in an IA32 HWP REQUEST MSR register for each logical processor. In this non-limiting example, each thread preference indicator can be selected as a value between 0-255, where the lower the value the higher the performance preference. For example, a thread preference indicator of 10 has a higher performance preference than a thread preference indicator of 100, which has a higher performance preference than a thread preference indicator of 200. In other embodiments, a thread preference indicator can be stored in memory, such as a cache, for at least a period of time.

[0038] In at least some embodiments, the thread preference of an application can be selected and set by a single software component or application, such as system application 120, user application 130, operating system 140, or a user of the application. However, in other embodiments, the thread preference can be selected and set by multiple software components, such as user application 130 and operating system 140. In these embodiments, some coordination can occur, for example, in the hardware of the appropriate core (e.g., core A 160A, core B 160B) in which the thread is running or in the operating system software (e.g., operating system 140). In an example scenario, if a first thread preference indicator is set by user application 130 and a second thread preference indicator is set by operating system 142, hardware (e.g., respective LP computation circuit 162A or 162B of core 160A and 160B) or software (e.g., thread preference selector 142 of operating system 140) can be invoked to determine which thread preference indicator is to be applied to the associated logical processor.

[0039] The software components of computing system 100 can also include a thread scheduler (e.g., 124, 134, 144) for maximizing the utilization of the thread preferences of threads by intelligently dispatching the threads to the logical processors of a core such that the dispatch creates a difference in the thread preferences associated with the core. For example, a thread can be dispatched to a core in which the thread will have the highest performance preference relative to other threads running in the core. This can ensure that the logical processors associated with the higher performance preference receive a greater share of the resources, execution cycles, and component utilization of the SMT core than would be the case if the same number of SMT cores were used across the logical processors without the difference.

[0040] In at least some embodiments, the threads of an application can be intelligently dispatched to the logical processors by a single software component, such as thread scheduler 124 of system application 120, thread scheduler 134 of user application 130, or thread scheduler 144 of operating system 140. However, in other embodiments, hardware can be used to intelligently dispatch the threads to the logical processors.

[0041] In one example implementation for creating a difference in thread preference indicators associated with logical processors in a core, a bit can be set (e.g., via a CPU ID bit) to enable an application to discover the utilization capability. An application with a thread scheduler can keep track of the thread preference indicators for all logical processors in the cores of the system. When a new thread or work is to be scheduled on a logical processor, the thread scheduler can determine which cores contain logical processors with different thread preference indicators than the new thread or work. If multiple cores have logical processors associated with different thread preference indicators, the new thread can be scheduled on the core that produces the greatest difference in thread preference indicators and / or that gives the new thread the highest performance preference relative to other threads running in that core.

[0042] The computing system 100 illustrates a processor 170 that is a simultaneous multi-threaded multi-core processor. For illustrative purposes, in Figure 1 Examples of logical processors and threads are shown in Core A 160A. Logical processor 1 164A(1) is shown with thread 1 165A(1) and logical processor 2 164A(2) is shown with thread 2 165A(2). In Core B 160B, logical processor 3 164B(1) is shown with thread 3 165B(1) and logical processor 4 164B(2) is shown with thread 4 165B(2). However, it should be readily apparent that embodiments can be implemented in a single core processor or a multi-core processor with more than two cores. Further, any number of logical processors can be running (or can be idle) on a core at any given time.

[0043] In at least one embodiment, a core (e.g., cores A and B) can include hardware such as LP computation circuitry (e.g., 162A or 162B) that performs one or more operations to compute a relative performance bias value for each logical processor in the core and, if needed, adjust the resources, execution cycles, and / or component speeds allocated to each logical processor based on the respective computed performance bias value. Thus, the hardware in a core can bias the performance of the logical processors within that core based on the thread preference indicators. To implement this performance bias, the LP computation circuitry (e.g., 162A or 162B) in a core can be configured to obtain a thread preference indicator 150 associated with a thread dispatched to a logical processor in the core. The LP computation circuitry can obtain the thread preference indicator by reading, receiving, being provided, or otherwise gaining access to the thread preference indicator. The relative relationship of the thread preference indicators can be used to compute a logical processor relative performance bias (LP-RPB) value for each logical processor.

[0044] For a logical processor in a core, an LP-RPB value can be computed based on the thread preference indicator of the logical processor relative to other thread preference indicators of other logical processors in the core. For a particular logical processor, one example computation can include the following computation: LP-RPB value = max(thread preference indicator in core) / (sum(thread preference indicators in core) min allocation value). Based on the computed LP-RPB values, the LP computation circuit or other hardware in the core can then dynamically adjust the hardware resource usage, number of execution cycles, and / or speed of different components in the pipeline of each logical processor of the core based on their respective LP-RPB values. The LP computation circuit can be further configured to monitor thread preference indicator changes and logical processor changes (e.g., going idle, going active) and dynamically update the resource allocation, number of execution cycles, and component speeds in the pipeline.

[0045] In the embodiments described herein, hardware resource usage can be dynamically adjusted by the hardware (e.g., 162A, 162B). For example, the hardware can allocate or distribute hardware resources based on the performance preferences of the logical processors in the same core. In one example, the hardware resources can be distributed proportionally among the logical processors based on the computed LP-RPB values. The hardware resources can include core-specific resources, such as core A resources 190A and core B resources 190B, and shared hardware resources 180. Particular examples of hardware resources that can be dynamically adjusted include, but are not limited to, core-specific caches, shared caches, shared buses, and shared memory. Core-specific resources can be allocated to and used by the logical processors of a single core. For example, the share of cache 192A can be dynamically adjusted and allocated to logical processors 164A(l) and 164A(2), and the share of cache 192B can be dynamically adjusted and allocated to logical processors 164B(l) and 164B(2). Shared hardware resources 180 can be allocated to logical processors across multiple cores. For example, respective shares of memory 186 can be allocated to core A 160A and core B 160B. The share of memory allocated to core A can be used to dynamically allocate a subset of that share to logical processors 164A(l) and 164A(2) based on their respective LP performance bias values. The share of memory allocated to core B can be used to dynamically allocate a subset of that share to logical processors 164B(l) and 164B(2) based on their respective LP performance bias values.

[0046] In the embodiments described herein, the number of execution cycles of a logical processor can be dynamically adjusted by hardware (e.g., 162A, 162B) based on thread preference. An execution cycle is a period of time during which one instruction in a thread is fetched from memory and executed. In one example, execution cycles can be proportionally divided among logical processors based on a calculated LP-RPB value. For example, hardware can dynamically assign more execution cycles to logical processors on a core that have a higher performance preference than logical processors that have a lower performance preference. Conversely, hardware can dynamically assign fewer execution cycles to logical processors on a core that have a lower performance preference than logical processors that have a higher performance preference.

[0047] In the embodiments described herein, hardware (e.g., 162A, 162B) can give more preference in different pipeline stages to logical processors that have a higher performance preference than other threads running on the same core. Pipeline stages can include, for example, fetch, decode, allocate, rename, schedule, register / memory read, execute, write, exception handling, and commit. At least some pipeline stages include certain components for which utilization can be adjusted based on thread preference. Increasing utilization of a component can increase the speed of the component, and conversely, decreasing utilization of a component can decrease the speed of the component. In particular, hardware can provide additional push (e.g., utilization) to components of pipeline stages that are executing or handling logical processors that have a higher performance preference than other logical processors in the same core. Reference will be made to Figures 16A-16B Pipeline stages and components are shown and discussed in more detail herein.

[0048] The embodiments herein can be implemented using any suitable approach to achieve the desired performance biasing between logical processors in a core. In one example, the shares of hardware resources and execution cycles can be proportionally distributed among the logical processors of a core based on computed LP-RPB values. The LP-RPB values can be computed in various ways based on the relative relationships of thread preference indicators across the logical processors in a core. As used herein, the "relative relationships" of thread preference indicators are intended to mean the relationships, connections, or dependencies between the thread preference indicators. Accordingly, when computing the LP-RPB values for the logical processors, the computation is based on the thread preference indicators of the thread of that logical processor being considered, estimated, ordered, compared, etc. relative to the other thread preference indicators of the other threads in the core. For example, for a computed LP-RPB value based on thread preference indicators having significantly different performance preference levels (e.g., 10 and 255), the shares of hardware resources and execution cycles can each be allocated among the logical processors and have a greater proportional difference than when the thread preference indicators indicate less distinct performance preference levels (e.g., 10 and 20). In another example, a predetermined percentage distribution can be used. For example, for three logical processors in a core having different thread preference indicators, the hardware resources and execution cycles can be divided among the logical processors in a predetermined percentage (e.g., 60%-30%-10%) that corresponds to the logical processors ordered according to the thread preference indicators (e.g., highest to lowest performance preference). In another example, for three logical processors having different performance preferences, the hardware resources and execution cycles can be divided among the logical processors in a predetermined percentage (e.g., 60%-20%-20% or 40%-40%-20%) that only provides a greater increasing bias to the logical processor associated with the thread preference indicator indicating the highest performance preference (e.g., thread preference indicator 0) and / or that only provides a greater decreasing bias to the logical processor associated with the thread preference indicator indicating the lowest performance preference (e.g., thread preference indicator 255).

[0049] Figure 2 is a simplified flowchart of possible operations that can be associated with embodiments of logical processor performance biasing in the computing system 100. For ease of illustration, the logical processor performance biasing is described in three stages, and Figure 2 represents stage Al. In at least one embodiment, the set of operations corresponds to Figure 2the activities of the application. The SMT core (e.g., core A 160A, core B 160B) or portions thereof can utilize the set of operations. The SMT core can include means, such as hardware, for performing the operations. In one example, at least some of the operations shown in flow 200 can be performed by the LP compute circuit 162A or 162B depending on the core in which the logical processor to which the thread is dispatched resides. For ease of reference, it will be assumed herein that the threads of an application are to be dispatched to logical processors 164A(1) and 164A(2) of core A 160A to be further described herein Figure 2 .

[0050] Phase Al identifies whether the application uses a thread preference indicator and whether the application, operating system, or user has programmed a different thread preference indicator for threads to be run on logical processors in an SMT core (e.g., core A 160A). At 202, the threads of an application to be run on a core (e.g., core A 160A) are detected. At 204, a determination can be made whether simultaneous multithreading is enabled on the core. If SMT is not enabled, the flow ends. If SMT is enabled on the core, at 206, a determination is made whether a thread preference indicator is enabled for the threads of the application. For example, if a component (e.g., operating system, user application, system application, virtual machine, user, etc.) has employed the use of a thread preference indicator to set thread preferences for the threads of the application, the thread preference indicator bit can be set by the component.

[0051] If at 206 it is determined that the thread preference indicator is enabled (e.g., the thread preference indicator bit is set), at 208 all of the logical processors in the core (e.g., 164A(1) and 164A(2)) are identified. At 210, the thread preference indicators of all threads running on the identified logical processors of the core are obtained. In one non-limiting example, the value of the thread preference indicator can be in the range of 0 to 255, where a value of 0 assigned to a first thread indicates that the maximum preference for performance is to be given to the first thread and a value of 255 assigned to a second thread indicates that the minimum preference for performance is to be given to the second thread. In at least one example, any value of 0 to 255 can be assigned to a thread to indicate a particular level of preference for performance to be given.

[0052] At 212, the thread preference indicators of the identified logical processors are compared. At 214, a determination is made whether all of the thread preference indicators of the threads belonging to the same core have the same value. If the thread preference indicators of the threads belonging to the same core all have the same value, at 216 resources are allocated and divided between the identified logical processors according to the normal policy of the system. The flow passes to Figure 5to stage A3 described in the background, to monitor changes in thread preference indicators and logical processors of a core. If a determination is made at 214 that there is at least one different value between thread preference indicators of threads belonging to the same core, then flow passes to stage A2 as described in the background Figure 3

[0053] Figure 3 is a simplified flowchart of possible operations that can be associated with embodiments of logical processor performance biasing in computing system 100. Figure 3 represents stage A2 of logical processor performance biasing. In at least one embodiment, a set of operations corresponds to activities of Figure 3 SMT core (e.g., core A 160A, core B 160B) or portions thereof can utilize the set of operations. The SMT core can include means, such as hardware, for performing these operations. In one example, at least some of the operations shown in flow 300 can be performed by LP computation circuitry 162A or 162B depending on the core in which the logical processor to which the thread is dispatched resides. To facilitate reference, further description herein will assume that the thread to which the application will be applied is dispatched to logical processors 164A(1) and 164A(2) of core A 160A. Figure 3 .

[0054] In stage A2, at 302, a logical processor (LP) relative performance bias value is computed based on relative relationships of thread preference indicators across logical processors in an SMT core (e.g., core A 160A). In particular, an LP relative performance bias (LP-RPB) value can be computed for a logical processor within a core based on relative relationships of thread preference indicators of threads dispatched to the logical processor with thread preference indicators of threads dispatched to other logical processors within the same core. The relative can be computed based on values of the thread preference indicators. In one example, the relative relationships of thread preference indicators are used to compute a scaled value of the thread preference indicators based on their performance preference levels. For example, as previously described herein, if the thread preference indicators have values in the range of 0-255, the scaled value can vary based on the particular level of performance preference. So, for example, thread preference indicators 10, 200, and 250 can have different scales than thread preference indicators 10, 50, and 225. In at least one implementation, the LP-RPB value can be computed based on the scale (e.g., as a percentage).

[0055] ​In another implementation, the relative relationship of thread preference indicators can be used to determine an order of logical processors in a core based on performance preference (e.g., highest to lowest) indicated by thread preference indicators of threads dispatched to those logical processors. In this implementation, the LP-RPB values can be based on a predetermined proportion of the ordered logical processors. For example, three logical processors in core A can be ordered based on thread preference indicators 0, 100, and 200 of threads dispatched to the three logical processors in core A. Three logical processors in core B can be ordered based on thread preference indicators 25, 50, and 255 of threads dispatched to the three logical processors in core B. In each of these scenarios, the LP-RPB values calculated for the three logical processors in each core can be based on the same predetermined proportion (e.g., 50%-30%-20%) regardless of the specific values of the thread preference indicators associated with each core.

[0056] In yet another example, the relative relationship of thread preference indicators can be used to distinguish thread preference indicators representing the highest performance preference of a logical processor in a core. For example, in addition to the LP-RPB value of the logical processor associated with the highest performance preference as indicated by the thread preference indicator, the LP-RPB values calculated for the logical processors in a core can be equal. The LP-RPB value of the logical processor associated with the highest performance preference can be greater than the other LP-RPB values. For example, three LP-RPB values calculated for three logical processors having thread preference indicators 10, 200, and 255 can be based on a predetermined proportion (e.g., 50%-25%-25%) where the LP-RPB value of the logical processor having the highest performance preference (e.g., thread preference indicator 10) is the highest proportion (e.g., 50%). The LP-RPB values of the remaining logical processors can be the same lower proportion (e.g., each 25%). It should be appreciated that the relative relationship of thread preference indicators can also (or instead) be used to distinguish thread preference indicators representing the lowest performance preference of a logical processor in a core.

[0057] While some examples have been described above, generally, any desired performance bias between logical processors of the same core can be implemented based on different thread preference indicators associated with the logical processors, and LP-RPB values can be computed accordingly to implement the desired bias. Moreover, in some embodiments, a single LP-RPB value can be computed to implement performance bias of resources, execution cycles, and component speeds in the logical processors. However, in other embodiments, unique LP-RPB values can be computed to apply to each of the hardware resources, execution cycles, and component speeds (or any combination thereof) in the logical processors. Moreover, it should be appreciated that the LP-RPB values can not necessarily be expressed as percentages, but can be expressed in any suitable form that can be used to determine the amount of resources, execution cycles, or utilization allocated to each logical processor.

[0058] Operations 304-312 can be performed for each logical processor in the core as needed while the associated thread is running. If desired, the performance bias of each logical processor can be adjusted based on the computed LP-RPB value for each logical processor. Generally, if a logical processor on the core has a higher relative performance bias, then that logical processor is given a greater share of the core pipeline, including higher utilization of the pipeline components that handle that logical processor, a greater number of execution cycles than given to other logical processors, and a greater share of hardware resources than allocated to other logical processors. The share of hardware resources can include a greater share of core-specific hardware resources, and potentially a greater share of the portion of shared hardware resources allocated to the core.

[0059] At 304, a logical processor (e.g., logical processor 1 164A(1)) and its computed LP-RPB are identified. As needed and when needed, logical processors can be identified for dynamic adjustment of their performance bias based on hardware resources allocated as needed (e.g., requested hardware resources), execution cycles to be divided between logical processors (e.g., a new thread scheduled), and / or for initiation of pipeline components that handle that logical processor. If desired, the performance bias of the identified logical processor can be adjusted (e.g., increased or decreased) based on the LP-RPB value computed for the logical processor.

[0060] The performance bias of the identified logical processor is adjusted in 306-310. At 306, the identified logical processor is assigned a share of one or more hardware resources based on the LP-RPB calculated for the identified logical processor. The hardware resources to be assigned can include core-specific hardware resources (e.g., core A resources 190A) and / or shared hardware resources (e.g., 180). If the identified logical processor has an LP-RPB value indicating a higher performance bias for the identified logical processor compared to all other logical processors in the same core (e.g., logical processor 2 164A(2)), the identified logical processor is assigned a greater share of the hardware resources. Conversely, if the identified logical processor has an LP-RPB value indicating a lower performance bias for the identified logical processor compared to all other logical processors in the same core (e.g., logical processor 2 164A(2)), the identified logical processor is assigned a smaller share of the hardware resources. Finally, the identified logical processor can have an LP-RPB value indicating that the performance bias for the logical processor is higher than one or more logical processors in the same core but lower than one or more other logical processors in the same core. In this scenario, the share of hardware resources assigned to the identified logical processor can be greater than the share assigned to a logical processor in the same core having a lower performance bias and less than the share assigned to a logical processor in the same core having a higher performance bias.

[0061] At 308, the identified logical processor is given a number of execution cycles based on the LP-RPB value calculated for the identified logical processor. If the identified logical processor has an LP-RPB value indicating a higher performance bias for the identified logical processor compared to all other logical processors in the same core (e.g., logical processor 2 164A(2)), the identified logical processor is assigned a greater number of execution cycles. Conversely, if the identified logical processor has an LP-RPB value indicating a lower performance bias for the identified logical processor compared to all other logical processors in the same core (e.g., logical processor 2 164A(2)), the identified logical processor is assigned a smaller number of execution cycles. Finally, the identified logical processor can have an LP-RPB value indicating that the performance bias for the logical processor is higher than one or more logical processors in the same core but lower than one or more other logical processors in the same core. In this scenario, the number of execution cycles assigned to the identified logical processor can be higher than the number of execution cycles assigned to a logical processor in the same core having a lower performance bias and less than the number of execution cycles assigned to a logical processor in the same core having a higher performance bias.

[0062] At 310, the speed at which the identified one or more components of the logical processor are executed or otherwise disposed can be dynamically changed based on the LP-RPB value calculated for the logical processor. If the identified logical processor has an LP-RPB value that indicates a higher performance preference for the identified logical processor as compared to all other logical processors in the same core (e.g., logical processor 2 164A(2)), then the utilization of the pipeline component that is disposed of the logical processor can be dynamically increased, and thus the speed of the component is increased. Conversely, if the identified logical processor has an LP-RPB value that indicates a lower performance preference for the identified logical processor as compared to all other logical processors in the same core (e.g., logical processor 2 164A(2)), then the utilization of the pipeline component that is disposed of the logical processor can be dynamically decreased, and thus the speed of the component is decreased. Finally, the identified logical processor can have an LP-RPB value that indicates a preference for the logical processor that is higher than one or more logical processors in the same core, but lower than one or more other processors in the same core. In this scenario, the utilization of the pipeline component that is disposed of the logical processor can be dynamically changed so that it is higher than the utilization by the logical processors in the same core that have a lower performance preference, and lower than the utilization by the logical processors in the same core that have a higher performance preference.

[0063] When the hardware resources, execution cycles, and / or component speeds have been dynamically adjusted for the logical processors in the same core, the flow can go to stage A3 as depicted in Figure 5

[0064] Figure 4 is a block diagram depicting an example scenario of logical processor performance biasing in accordance with an embodiment of the disclosure. Figure 4 illustrates how the sharing of the pipeline can be biased to ensure that performance is biased towards the logical processor that requests more performance in an SMT core. Figure 4 The example in FIG. 4A involves a logical processor 1 (LP 1) and a logical processor 2 (LP 2). The input condition 402 is based on the thread preference indicators of LP 1 and LP 2 indicating a higher performance preference for LP 1 as compared to LP 2. In this example, this higher performance preference for LP 1 is indicated by the value of the thread preference indicator of LP 1 being less than the value of the thread preference indicator of LP 2.

[0065] ​At 404, relative performance bias values are computed for the logical processors based on the associated thread preference indicators. In this example, the relative performance bias value for LP 1 is determined to be greater than the relative performance bias value for LP 2. These relative performance bias values indicate that LP 1 is to receive a higher share of hardware resources, a greater number of execution cycles, and increased pipeline component utilization as compared to the hardware resources, execution cycles, and pipeline component utilization provided to LP 2. Accordingly, when instructions 1 of LP 1 at 410, instructions 2 of LP 1 at 408, and instructions 1 of LP 2 at 406 are fetched at 412, the performance bias of LP 1 and LP 2 is adjusted based on the relative performance bias values of LP 1 and LP 2. The performance bias of LP 1 can be increased by providing more hardware resources, execution cycles, and / or component utilization to LP 1 than to LP 2. The performance bias of LP 2 can be decreased by providing less hardware resources, execution cycles, and / or component utilization to LP 2 than to LP 1. This performance bias of the logical processors is based on the inputs from stage A2 shown at 404.

[0066] Figure 5 is a simplified flowchart of possible operations that can be associated with embodiments of logical processor performance bias in computing system 100. Figure 5 represents stage A3 of LP relative performance bias. In at least one embodiment, a set of operations corresponds to the activities of Figure 5 SMT core (e.g., core A 160A, core B 160B) or portions thereof can utilize this set of operations. The SMT core can include means, such as hardware, for performing these operations. In one example, at least some of the operations shown in flow 500 can be performed by LP compute circuitry 162A or 162B depending on the core in which the logical processor to which the thread is dispatched resides. To facilitate reference, further description of Figure 5 .

[0067] In stage A3, the logical processors in the core and thread preference indicators are monitored to enable dynamic updates to hardware resource allocation, execution cycle allocation, and pipeline component utilization based on changes to the thread preference indicators associated with the logical processors on the core and / or based on changes to the logical processors on the core (e.g., going idle / active). At 502, changes to the thread preference indicators and the logical processors in the core are monitored.

[0068] At 504, a change in thread preference indicators or logical processors in the core is detected. In one scenario, a change in thread preference indicators can be detected when any one (or more) of the thread preference indicators of the threads currently running in the logical processors of the core have increased or decreased since the LP-relative performance bias values were last calculated (e.g., at 302). In another scenario, a change in thread preference indicators can be detected at 504 if there was no initial difference in the thread preference indicators, when any one (or more) of the thread preference indicators of the threads currently running in the logical processors of the core have increased or decreased since the thread preference indicators were read (e.g., at 210).

[0069] A change can also be detected in a logical processor in the core if a thread running in the logical processor ends execution and the logical processor becomes idle. In another example, a change in a logical processor can be detected if a new thread of an application is dispatched to a previously idle logical processor in the core. If a change in at least one thread preference indicator or at least one logical processor is determined to have occurred, all of the logical processors in the core are identified at 506. At 508, the thread preference indicators of the threads associated with each of the logical processors in the core are obtained. Flow then passes back to stage A2 to recalculate the LP-relative performance bias values and to adjust resource allocation, number of execution cycles, and / or pipeline component speed for the logical processors based on the new LP-RPB values.

[0070] Turning to Figure 6 , Figure 6 is a simplified flow diagram of possible operations that can be associated with embodiments of logical processor performance biasing in computing system 100. In at least one embodiment, the set of operations corresponds to activities of Figure 6 In at least one embodiment, a software component (e.g., operating system 140, system application 120, user application 130, etc.) or portions thereof can utilize the set of operations. The software component can include a device such as processor 170 for performing the operations. In one example, depending on the particular software component configured to utilize the set of operations, at least some of the operations shown in flow 600 can be performed by a thread scheduler (e.g., 124, 134, or 144).

[0071] At 602, thread preference indicators of threads running in logical processors (e.g., logical processors 164A(l), 164A(2), 164B(l), and 164B(2)) across all cores of a processor are tracked. At 604, a new thread of an application to be scheduled on a logical processor is detected. At 606, a comparison of the thread preference indicator of the new thread is performed relative to thread preference indicators of existing threads already scheduled in the plurality of cores in the processor. At 608, a determination is made whether there is a difference on at least one core based on the comparison. If the thread preference indicator of the new thread is different from at least one thread preference indicator of another thread already scheduled in a logical processor of a core, there is a difference in the core. If there is no difference on any of the cores, the new thread can be assigned to any of the cores according to an existing scheduling policy at 610, and the flow ends thereafter.

[0072] If there is a difference on at least one core, a determination of a maximum difference at 612 can be used to identify an optimal core for the new thread. There is a maximum difference in a core if the core has more difference that the new thread would have than all other cores have for the new thread. In another embodiment, the optimal core is a core in which a highest logical processor performance bias value can be calculated for the new thread based on logical processors currently active in the core. In yet another embodiment, the optimal core is a core in which the new thread would have a highest performance preference (e.g., lowest thread preference indicator) compared to other cores. At 614, the new thread is scheduled on the identified optimal core.

[0073] Figures 7A-7B is a block diagram depicting an example scenario of utilization of maximizing logical processor performance bias to schedule threads of an application according to an embodiment of the present disclosure. In this illustrative example, thread preference indicators can be set between 0 and 255, where 0 represents a highest thread performance preference and thus seeks a most performance bias (e.g., a highest proportion of resources), and 255 represents a lowest thread performance preference and thus seeks a least performance bias (e.g., a lowest proportion of resources).

[0074] Figure 7AExample cores A and B are shown, each of which has two logical processors, LP 1 and LP 2 on core A and LP 3 and LP 4 on core B. Thread 1 is running on LP 1 and has thread preference indicator 10, while LP 2 is idle. Thread 2 is running on LP 3 and has thread preference indicator 255, while LP 4 is idle. At 702, new thread 3 has thread preference indicator 10 and is to be dispatched to one of the idle logical processors, LP 2 on core A or LP 4 on core B. If new thread 3 is dispatched to LP 2, there will be no disparity in core A. As indicated by the thread preference indicators of thread 1 and thread 3 being set to 10, both thread 1 and thread 3 seek a higher performance bias based on their high thread performance preference. However, if new thread 3 is dispatched to LP 4 on core B, there will be disparity in core B, as thread 2 has thread preference indicator 255 and new thread 3 has thread preference indicator 10.

[0075] Figure 7B New thread 3 is shown dispatched to LP 4 of core B. Based on the relative relationship between thread preference indicator values 10 and 255, an LP relative performance bias value can be calculated for LP 3 and LP 4. Accordingly, LP 4 gets a higher proportion of the resources of core B as compared to LP 3 and also gets a performance boost (e.g., higher utilization of pipeline components). LP 4 can also be dispatched a greater number of execution cycles as compared to LP 3.

[0076] Turning to Figure 8, a block diagram illustrates an embodiment of a computing system 800 configured for dynamic relative performance biasing for cores of a multi-core system. At least one embodiment can be implemented with cores that support simultaneous multithreading (also referred to herein as "SMT-enabled"). At least one other embodiment can be implemented with cores that do not support simultaneous multithreading (also referred to herein as "non-SMT-enabled"). In computing system 800, dynamic LP performance biasing is extended to control core-level optimizations based on a thread preference indicator. As previously described herein, a thread preference indicator can be used to compute a core relative performance bias value in a similar manner. However, the core relative performance bias value can be used in a multi-core processor to bias shared hardware resources, including non-core resources, among the cores of the multi-core processor. Shared hardware resources can include, for example, shared caches (e.g., L3 cache), on-die memory controllers, point-to-point processor interconnects, bus interfaces, memory, etc. Additionally, if any pipelines or other components are shared across cores, the core relative performance bias value can be used to bias execution cycles and / or component speeds across cores. Core performance biasing based on a thread preference indicator can enable dynamic control of the amount of resources used by a core to give an application more power savings or performance as needed and when needed.

[0077] In the example of this embodiment, computing system 800 can include one or more system applications (e.g., 820), one or more user applications (e.g., 830), and an operating system (e.g., 840), any or all of which can be stored in memory 888. The system and user applications can include thread preference selectors (e.g., 822, 832, 842) and thread schedulers (e.g., 824, 834, 844). Thread preference indicator 850 can be stored in any suitable storage or memory, such as a hardware register, and can be fetched by processor 870. Processor 870 can include core computing circuitry 872 and a plurality of cores, such as core A 860A, core B 860B, core C 860C, and core D 860D. In a multi-core system that does not support SMT, each core can include a single logical processor with an associated thread at any given moment. In a multi-core system that supports SMT, each core can include a plurality of logical processors with associated threads at any given moment. Figure 8In the example, core A includes LP 1 864(1) with thread 1 865(1), core B includes LP 2 864(2) with thread 2 865(2), core C includes LP 3 864(3) with thread 3 865(3), and core D includes LP 4 864(4) with thread 4 865(4). Cores A-D can each have core- specific resources (e.g., core A resources 890A, core B resources 890B, core C resources 890C, and core D resources 890D). Shared hardware resources are allocated across cores, and can include, for example, shared cache 882, bus interface 884, and memory 886. In at least one embodiment, memory 888 is a portion of memory 886, which can be a main memory (e.g., random access memory (RAM)) of computing system 800. Storage (e.g., hard disk, solid state drive, etc.) for storing data and code can be used in computing system 800 and is not shown in Figure 8 . Other shared hardware resources for which performance bias can apply can include, but are not necessarily limited to, internal registers, access ports, out-of-order microarchitectural features, etc.

[0078] For SMT-enabled systems, in at least some embodiments, each core can include LP compute circuitry (shown in Figure 1 ) to utilize thread preference information between different logical processors in the same SMT-enabled core as described with reference to Figures 1-5 . However, in embodiments that include core relative performance bias, allocation of shared hardware resources between logical processors in the same SMT-enabled core is computed based on the logical processor's LP relative performance bias value and the amount of shared hardware resources allocated to the core.

[0079] Embodiments of computing system 800 (both SMT-enabled and non-SMT-enabled) can utilize thread preference information to exploit differences across different cores in the same processor (e.g., 870) based on thread performance preferences, and to enhance resource sharing by biasing resources between cores. In SMT-enabled embodiments, after biasing resources toward one core over one or more other cores, the biasing of resources can be adjusted based on thread performance preferences as described with reference to Figures 1-5As described, LP performance biasing can be performed in each core in which a difference in thread preference indicators associated with logical processors in the core occurs. In this scenario, the new amount of resources assigned to the core as a result of the core performance biasing is performed within the core. For each logical processor, any suitable technique capable of providing thread preference information (e.g., in the form of thread preference indicators 850), whether currently available or later developed, can be utilized by the hardware to efficiently manage resources among cores (e.g., non-SMT enabled and SMT enabled) of a processor. The technique can also be utilized by the hardware to efficiently manage resources among logical processors within an SMT enabled core and provide performance to the associated application that most needs performance.

[0080] In an embodiment, the processor reads thread preference indicators 850 for all logical processors of all cores in the system. For example, as previously described herein with reference to thread preference indicators 150, the thread preference indicators can be programmed, configured, or otherwise set by a user application, operating system, system application, or user. The processor 870 consolidates the thread preference indicators assigned to the logical processors and calculates a value representing the relative relationship of performance biasing for each core. The hardware adjusts the relative core performance biasing for each core based on the calculated core performance biasing value. More specifically, the hardware can dynamically adjust hardware resource usage (e.g., allocation of shared hardware resources 880) across cores, which can provide more power savings and / or enhanced performance.

[0081] A computing system, such as computing system 800, for cross-core performance biasing can provide some advantages. In a system containing non-SMT enabled cores, the hardware can utilize differences in thread preference information across cores to efficiently manage resources among the cores. By using thread preference information for each logical processor, the hardware can speculatively bias the performance of a core in a non-SMT enabled system. For example, a core having a logical processor running a thread programmed to have a higher performance bias as indicated by the thread's thread preference indicator (e.g., a high priority or more important thread) can be given a larger share of shared hardware resources than another core having a logical processor running a thread programmed to have a lower performance bias as indicated by the thread's thread preference indicator (e.g., a low priority or less important thread). Conversely, a non-SMT enabled core having a logical processor running a thread programmed to have a lower performance bias as indicated by the thread's thread preference indicator (e.g., a low priority or less important thread) can be given a smaller share of shared hardware resources than another core having a logical processor running a thread programmed to have a higher performance bias as indicated by the thread's thread preference indicator (e.g., a high priority or more important thread).

[0082] In at least one embodiment, the hardware can leverage thread preference indicators for different SMT-unenabled cores across the processor by calculating a core-relative performance bias value for each core and biasing resource availability and performance toward the core with the highest core performance bias value. The core-relative performance bias value for a specific SMT-unenabled core can be calculated based on a single thread preference indicator associated with a core relative to single thread preference indicators associated with other cores. This approach can result in better responsiveness and application experience in SMT-unenabled systems.

[0083] Cross-core performance bias can also provide advantages in SMT-enabled systems. In an SMT-enabled system, the thread preference information of each logical processor for the multiple threads associated with each core can be used by the hardware to speculatively bias the core's performance. For example, a core having multiple logical processors running threads with higher performance preferences (e.g., high-priority or more important threads) as indicated by the thread preference indicators of those threads can be given a larger share of shared hardware resources compared to another core having multiple logical processors running threads with lower performance preferences (e.g., high-priority or more important threads) as indicated by the thread preference indicators of those threads. Conversely, an SMT-enabled core having multiple logical processors running threads with lower performance preferences (e.g., low-priority or less important threads) as indicated by the thread preference indicators of those threads can be given a smaller share of shared hardware resources compared to another core having multiple logical processors running threads with higher performance preferences (e.g., high-priority or more important threads) as indicated by the thread preference indicators of those threads.

[0084] In at least one embodiment, the hardware can utilize thread preference indicators associated with SMT-enabled cores within the processor by calculating a core-relative performance bias value for each core and biasing resource availability and performance towards the core with the highest core performance bias value. The core-relative performance bias value for a particular core can be calculated based on the thread preference indicator associated with that core relative to thread preference indicators associated with other cores. In at least some scenarios, if the thread preference indicators for each core are different (i.e., each core is associated with multiple different thread preference indicators), the core performance bias value can be determined based on the highest performance preference programmed for each core. Additionally, resources allocated to a particular core with multiple logical processors will be shared by the logical processors within that core. This approach can result in better responsiveness and application experience within an SMT-enabled system.

[0085] Computing system 800 may include the same or similar infrastructure as computing system 100. Accordingly, a brief discussion of some of the infrastructures of computing system 800, which includes infrastructures different from those of computing system 100, is now provided. Computing system 800 illustrates processor 870, which in at least one embodiment may be a non-SMT-enabled system. In a non-SMT-enabled system, each core may have a single logical processor running a single thread at a time, such as core A with LP 1 running thread 1, core B with LP 2 running thread 2, core C with LP 3 running thread 3, and core D with LP 4 running thread 4. However, it should be apparent that computing system 800 is an example, and embodiments with core performance bias on non-SMT-enabled cores may include two or more cores. Alternatively, processor 870 in at least one embodiment may be an SMT-enabled system. In an SMT-enabled system, each core may have multiple logical processors (e.g., Figure 1 As shown in the diagram, each logical processor runs a thread associated with a thread preference indicator. For example, in computing system 800, core AD may each have two (or more) logical processors, and each logical processor may run a thread with a thread preference indicator.

[0086] In at least one embodiment, the processor (e.g., processor 870) may include hardware such as core computing circuitry 862 that performs one or more operations to calculate a performance bias value for each core in the processor and, if necessary, adjust the resources, execution cycles, and / or component speeds allocated to each core based on the corresponding calculated performance bias value. Thus, the hardware in the processor can bias the performance of cores (e.g., core AD) within the processor based on a thread preference indicator. To implement this performance bias, the core computing circuitry may be configured to acquire a thread preference indicator 850 associated with a thread of a logical processor assigned to a core. The core computing circuitry can acquire the thread preference indicator by reading, receiving, being provided with the thread preference indicator, or otherwise gaining access to the thread preference indicator. The relative relationships of the thread preference indicators can be used to calculate a core-relative performance bias (C-RPB) value for each core. In a system without SMT enabled, for each core, the core computing circuitry calculates the C-RPB value based on a corresponding single thread preference indicator associated with that core relative to other single thread preference indicators associated with other cores.

[0087] In a system with SMT enabled, for each core, the core computation circuitry can calculate the C-RPB value based on one or more corresponding thread preference indicators associated with that core relative to one or more thread preference indicators associated with other cores. In one possible implementation, a thread preference indicator indicating the highest performance preference in each core can be used to evaluate the relative relationships used to calculate the C-RPB value for each core. In other implementations, other factors may be considered when determining the relative relationships used to calculate the C-RPB value. For example, other factors may include the amount of variation in each core, the number of logical processors in each core, the number of logical processors with a higher (or lower) performance preference, etc.

[0088] Once the C-RPB value is calculated for a system without SMT or with SMT enabled, the core computing circuitry 872 or other hardware in the processor can then dynamically adjust the hardware resource usage, number of execution cycles, and / or component speed for each core of the shared hardware resources shared across cores. This adjustment can be made based on the calculated C-RPB value. The core computing circuitry can be further configured to monitor changes in thread preference indicators and logical processor changes (e.g., becoming idle or active) and dynamically update the shared hardware resource allocation, number of execution cycles, and component speed.

[0089] In the embodiments described herein, hardware resource usage can be dynamically adjusted by hardware (e.g., 862). In one example, shared hardware resources can be distributed proportionally among cores based on a calculated C-RPB value. Shared hardware resources 880 may include shared cache 882 (e.g., L3 cache), bus interface 884, and memory 886. Other examples of shared hardware resources may include, but are not limited to, on-die memory controllers, point-to-point processor interconnects, access ports, internal registers, microarchitectural features, etc. Shared hardware resources 880 can be allocated across multiple cores in a processor. For example, shares of shared cache 882 and memory 886 can be dynamically adjusted and allocated to core AD. The bandwidth of bus interface 884 can be dynamically adjusted and allocated to core AD.

[0090] As previously described with reference to the logic processor herein, if pipeline components or other components are shared across cores, the number of execution cycles allocated to a core can be dynamically adjusted by the hardware (e.g., 862) based on thread preferences. Additionally, the hardware (e.g., 862) can give a core with a higher performance preference more preference in shared pipeline components or other shared components compared to other cores running on the same processor. Although performance biases can be implemented across multiple cores in a processor for any shared resources, number of execution cycles, or component speeds associated with those cores, for ease of illustration, further description of the computing system 800 herein may refer only to performance biases for shared hardware resources. However, it should be understood that such biases can also be applied to execution cycles and / or component speeds shared across cores.

[0091] Embodiments of the computing system 800 can be implemented using any suitable method to achieve the desired performance bias among cores in the processor. In one example, the share of shared hardware resources can be distributed proportionally among the processor cores based on a calculated C-RPB value. The C-RPB value can be calculated using various methods based on the relative relationships of thread preference indicators across cores. For example, for a C-RPB value calculated based on thread preference indicators with significantly different performance preference levels (e.g., 10 and 255), the share of shared hardware resources can be allocated among cores and have a larger proportional difference than when the thread preference indicators indicate smaller differences in performance preference levels (e.g., 10 and 20). In another example, a predetermined percentage distribution can be used. For example, assume four cores AD have corresponding logical processors LP1 to LP4, and the logical processors are associated with threads having different thread preferences indicated by their respective thread preference indicators. Shared hardware resources (e.g., 880) can be allocated among cores according to a predetermined percentage (e.g., 40%-30%-20%-10%) corresponding to cores ordered according to thread preference indicators (e.g., highest to lowest performance preference) of the logical processors of these cores. In another example, for four cores associated with different thread preference indicators, hardware resources can be allocated among cores according to a predetermined percentage (e.g., 70%-10%-10%-10% or 30%-30%-30%-10%), which provides a larger increasing bias only to the core associated with the thread preference indicator indicating the highest performance preference and / or only a larger decreasing bias only to the core associated with the thread preference indicator indicating the lowest performance preference.

[0092] In a system without SMT enabled, the entire share of hardware resources allocated to a specific core (e.g., core A 860A) can be used by the logical processors of that core (e.g., LP 1 864(1)). However, in a system with SMT enabled, if a logical processor is associated with threads having different thread preference indicators, the share of hardware resources allocated to a specific core (e.g., core A 860A) can be dynamically biased across multiple logical processors within the core. LP performance bias can be referenced as previously mentioned herein. Figures 1-5 The described implementation.

[0093] Figure 9 This is a simplified flowchart of possible operations that can be associated with an embodiment of core performance bias in computing system 800. For ease of illustration, core performance bias is described in three phases (phase B1, phase B2, and phase B3). Figure 9 This represents stage B1. In at least one embodiment, a set of operations corresponds to... Figure 9 The activities. A processor (e.g., processor 870) or a portion thereof may utilize this set of operations. The processor may include means such as hardware for performing these operations. In one example, at least some of the operations shown in flow 900 may be performed by core computing circuitry 872.

[0094] Phase B1 identifies whether the application uses thread preference indicators and whether the application, operating system, or user has programmed different thread preference indicators for the threads to run on the logical processors in a core (e.g., cores 860A-860D). At 902, the application's threads to run on a core (e.g., core A 860A) are detected. The core can be SMT-enabled or SMT-disabled. At 906, a determination is made as to whether to enable thread preference indicators for the application's threads. For example, if a component (e.g., operating system, user application, system application, virtual machine, user, etc.) has already adopted the use of thread preference indicators to set thread preferences for the application's threads, that component may set the thread preference indicator bit. If thread preference indicators are not enabled (e.g., the thread preference indicator bit is not set), the process ends. It should be apparent that software components can use any suitable technique to provide indication of setting thread preference indicators for the application's threads.

[0095] If the thread preference indicator is determined to be enabled at 906 (e.g., the thread preference indicator bit is set), then at 908 all logical processors (e.g., 864A(1)-864A(4)) across all cores are identified. At 910, the thread preference indicator for all threads running on the identified logical processors of the core is obtained. As previously described herein, in a non-limiting example, the value of the thread preference indicator can be in the range of 0 to 255.

[0096] At 912, the thread preference indicators of the identified logical processors are compared. At 914, a determination is made as to whether all thread preference indicators of threads running on the logical processors in the core have the same value. If the thread preference indicators of threads in all cores have the same value, then at 916, shared hardware resources are allocated and divided among the identified cores according to the system's normal policy. The process is then passed to... Figure 11 Phase B3, as described, monitors changes to thread preference indicators and logical processors across multiple cores. If a determination is made at 914 that at least one distinct value exists between thread preference indicators across all cores, the flow is passed to... Figure 10 Phase B2 as described in the text.

[0097] Figure 10 This is a simplified flowchart of possible operations that can be associated with an embodiment of core-relative performance bias in computing system 800. Figure 10 Phase B2 represents the nuclear relative performance bias. In at least one embodiment, a set of operations corresponds to Figure 10 The activities. A processor (e.g., processor 870) or a portion thereof may utilize this set of operations. The core may include means such as hardware for performing these operations. In one example, at least some of the operations shown in process 1000 may be performed by core computing circuitry 872.

[0098] In stage B2, the core relative performance bias value is calculated. As indicated at 1002, the type of relative relationship used to calculate the core relative performance bias value depends on whether the system is SMT-enabled or SMT-disabled. If the system is SMT-disabled, the core relative performance bias value is calculated at 1004 based on the relative relationships of thread preference indicators across multiple cores in the processor, where each core is associated with a single logical processor and therefore can be associated with a single thread preference indicator. For example, the core relative performance bias (C-RPB) value can be calculated for the core based on the thread preference indicators of threads assigned to the logical processor of the core and the thread preference indicators of threads assigned to other logical processors of other cores in the processor. The relativity can be calculated based on the values ​​of the thread preference indicators. In cores without SMT enabled, the relative relationships of the thread preference indicators can be used as previously referenced herein. Figures 1-5The C-RPB value can be calculated using any of the methods discussed for calculating the LP-RPB value. For example, a relative relationship can be used to determine a proportion of a thread preference indicator, or a predetermined proportion of the ordered logical processors (and their associated cores) based on the associated thread preference indicator, or a predetermined proportion of the cores associated with the highest and / or lowest performance preferences indicated by the thread preference indicator. As previously described herein, the C-RPB value can be expressed as a percentage or in any other suitable form that can be used to determine the amount of shared hardware resources to be allocated to each core. Generally, any desired performance bias between processor cores can be achieved based on the different thread preference indicators associated with the cores, and the C-RPB value can be calculated accordingly to achieve the desired bias.

[0099] In a system without SMT enabled, 1006-1008 can be executed as needed for each core in the processor while threads in the core are running. If necessary, the performance bias of each core can be adjusted based on its calculated C-RPB value. Generally, if a core has a higher relative performance bias, it is given a larger share of shared hardware resources (e.g., shared cache 882, bus interface 884, memory 886, etc.), which may include non-core resources. At 1006, a core (e.g., core A 864A(1)) and its calculated C-RPB value are identified. Cores can be identified for dynamically adjusting their performance bias as needed and as required based on the allocation of shared hardware resources (e.g., when a new thread requests shared hardware resources). If necessary, the performance bias of the identified core can be adjusted (e.g., increased or decreased) based on the C-RPB value calculated for the core.

[0100] Example of adjusting core performance bias at point 1008. At point 1008, a share of one or more shared hardware resources is allocated to the identified core based on a C-RPB value calculated for that core. If the identified core has a C-RPB value indicating a higher performance preference for the identified core (e.g., core 860A) compared to all other cores in the same processor (e.g., cores 860B-860D), a larger share of shared hardware resources is allocated to the identified core. Conversely, if the identified core (e.g., core 860A) has a C-RPB value indicating a lower performance preference for the identified core compared to all other cores in the same processor (e.g., cores 860B-860D), a smaller share of hardware resources is allocated to the identified core. Finally, the identified core may have a C-RPB value indicating a performance preference higher than one or more cores in the same processor but lower than one or more other cores in the same processor. In this scenario, the share of shared hardware resources allocated to the identified core can be greater than the share allocated to cores with lower performance preferences within the same processor, but less than the share allocated to cores with higher performance preferences within the same processor.

[0101] Referring again to 1002, if the system is SMT enabled, the C-RPB value at 1010 is calculated based on the relative relationships of thread preference indicators across multiple cores in the processor, where each core is associated with one or more thread preference indicators. For example, the C-RPB value for a core can be calculated based on the relative relationships between one or more thread preference indicators associated with a thread running on a logical processor in the core and one or more thread preference indicators associated with a thread running on a logical processor in other cores of the processor. Relativity can be calculated based on the values ​​of the thread preference indicators. In one example, the thread preference indicator for threads from each core is selected based on the highest performance preference within the core. The relative relationships of these selected thread preference indicators from each core can be used as previously referenced herein. Figures 1-5 The C-RPB value can be calculated using any method discussed for calculating the LP-RPB value. For example, a relative relationship can be used to determine a proportion of the selected thread preference indicator, or a predetermined proportion of the ordered logic processors (and their associated cores) based on the associated thread preference indicator, or a predetermined proportion of the cores associated with the highest and / or lowest performance preferences indicated by the selected thread preference indicator.

[0102] In some scenarios involving SMT-enabled cores, other factors may be considered when determining the relative relationships used to calculate C-RPB values. These factors may include, but are not limited to, the amount of variation per core, the number of logical processors per core, and the number of logical processors with higher (or lower) performance preferences. Such factors may be considered when evaluating the relative relationships of selected thread preference indicators to calculate the C-RPB value for a core. As previously described herein, C-RPB values ​​may be expressed as a percentage or in any suitable form used to determine the amount of shared hardware resources to be allocated to each core.

[0103] In a system with SMT enabled, 1012-1016 can be executed for each core in the processor as needed, while threads in the core are running. If necessary, the performance bias of each core can be adjusted based on the calculated C-RPB value for each core. Generally, if a core has a higher relative performance bias, it is given a larger share of shared hardware resources (e.g., shared cache 882, bus interface 884, memory 886, etc.). At 1012, a core (e.g., core A 864A(1)) and its calculated C-RPB are identified. A core can be identified based on the need for hardware resources to be allocated (e.g., shared hardware resources are requested). If necessary, the performance bias of the identified core can be adjusted (e.g., increased or decreased) based on the C-RPB value calculated for the core.

[0104] Here's an example of indicating the adjustment of a core's performance bias at point 1014. At point 1014, a share of one or more shared hardware resources is allocated to the identified core based on the C-RPB calculated for that core. If the identified core has a C-RPB value indicating a higher performance preference for the identified core (e.g., core 860A) compared to all other cores in the same processor (e.g., cores 860B-860D), a larger share of shared hardware resources is allocated to the identified core. Conversely, if the identified core (e.g., core 860A) has a C-RPB value indicating a lower performance preference for the identified core compared to all other cores in the same processor (e.g., cores 860B-860D), a smaller share of hardware resources is allocated to the identified core. Finally, the identified core may have a C-RPB value indicating a performance preference higher than one or more cores in the same processor but lower than one or more other cores in the same processor. In this scenario, the share of shared hardware resources allocated to the identified core can be greater than the share allocated to cores with lower performance preferences within the same processor, but less than the share allocated to cores with higher performance preferences within the same processor.

[0105] In a system with SMT enabled, the logical processor of the core (e.g., 860A-860D) identified at 1012 can execute the following as referenced at 1016. Figure 3 The operations shown and described in stage A2 are as follows. In stage A2, at 302, a logical processor (LP) relative performance bias value is calculated based on the relative relationships of thread preference indicators of multiple logical processors across an SMT core (e.g., core A 860A). For example, an LP relative performance bias (LP-RPB) value is calculated for each logical processor within the core identified at 1012, based on the relative relationships between the thread preference indicators of threads assigned to that logical processor and the thread preference indicators of threads assigned to other logical processors in the same core. Generally, as previously referenced herein... Figures 1-5 As described, any desired performance bias between logical processors of the same core can be achieved based on different thread preference indicators associated with these logical processors, and LP-RPB values ​​can be calculated accordingly to achieve the desired bias.

[0106] While the associated thread is running, operations 304-312 can be performed as needed for each logical processor in the identified core. If necessary, the performance bias of each logical processor can be adjusted based on its calculated LP-RPB value. Generally, if a logical processor on a core has a higher relative performance bias, it is given a larger share of the core pipeline, including higher utilization of the pipeline components that handle that logical processor, a larger number of execution cycles than other logical processors, and a larger share of hardware resources than other logical processors. The share of hardware resources can include a larger share of core-specific hardware resources and potentially a larger share of the shared hardware resources allocated to the identified core at 1014.

[0107] At 304, identify the logic processor (e.g., LP 1 864(1)) and its computed LP-RPB. The logic processor may be identified based on the need for hardware resource allocation (e.g., hardware resources being requested), the need for execution cycles to be divided among logic processors (e.g., scheduling new threads), and / or the startup of pipeline components used to dispose of the logic processor. If necessary, the performance bias of the identified logic processor may be adjusted (e.g., increased or decreased) based on the LP-RPB value computed for the logic processor.

[0108] In steps 306-310, the performance bias of the identified logical processor is adjusted. At 306, a share of one or more core-specific hardware resources (e.g., core A resource 890A) is allocated to the identified logical processor based on an LP-RPB value calculated for that logical processor. If the identified logical processor has an LP-RPB value indicating a higher performance preference for the identified logical processor (e.g., LP1) compared to all other logical processors in the same core, a larger share of core-specific hardware resources is allocated to the identified logical processor. Conversely, if the identified logical processor has an LP-RPB value indicating a lower performance preference for the identified logical processor compared to all other logical processors in the same core, a smaller share of core-specific hardware resources is allocated to the identified logical processor. Finally, the identified logical processor may have an LP-RPB value indicating a performance preference higher than one or more logical processors in the same core but lower than one or more other processors in the same core. In this scenario, the share of core-specific hardware resources allocated to the identified logic processor can be greater than the share allocated to a logic processor with a lower performance preference within the same core, but less than the share allocated to a logic processor with a higher performance preference within the same core.

[0109] Still at 306, a share of one or more shared hardware resources (e.g., shared cache 882, bus interface 884, memory 886, etc.) can be allocated to the identified logical processor based on the LP-RPB value calculated for that logical processor. This allocation can be implemented as described above with reference to the allocation of core-specific hardware resources. However, for shared hardware resources, the shared hardware resources themselves may have already been allocated to the identified core based on a C-RPB value associated with the identified core, which contains the identified logical processor. Therefore, in this embodiment, the allocation of shared hardware resources among logical processors within a core can be based on the amount of shared hardware resources allocated to that core based on the core's C-RPB value.

[0110] At 308, as previously described herein, the identified logical processor is given a number of execution cycles based on the LP-RPB value calculated for that logical processor. At 310, as previously described herein, the speed at which one or more components of the identified logical processor are disposed of can be dynamically changed based on the LP-RPB value calculated for that logical processor. When hardware resources (e.g., core-specific and shared), execution cycles, and / or component speeds have been dynamically adjusted for logical processors within the same core, the process can proceed as follows: Figure 10 The return to stage B3 is described in the text.

[0111] Figure 11This is a simplified flowchart of possible operations that can be associated with an embodiment of core dynamic performance bias in computing system 800. Figure 11 Phase B3 represents the nuclear relative performance bias. In at least one embodiment, a set of operations corresponds to... Figure 11 The activities. A multi-core processor (e.g., processor 870) or a portion thereof may utilize this set of operations. The processor cores may be SMT-enabled or SMT-disabled. The processor may include means such as hardware for performing these operations. In one example, at least some of the operations shown in process 1100 may be performed by a core relative to computing circuitry 872.

[0112] In phase B3, monitoring of logical processors and thread preference indicators within the core enables dynamic updates to the allocation of shared hardware resources for both SMT-enabled and SMT-unenabled cores, based on changes to thread preference indicators associated with logical processors within the core and / or changes to logical processors within the core (e.g., becoming idle / active). For SMT-enabled cores, this monitoring can also enable dynamic updates to the allocation of core-specific hardware resources, execution cycle allocation, and pipeline component utilization.

[0113] At 1102, changes to the thread preference indicator and logical processors in the core are monitored. At 1104, a change to the thread preference indicator or a logical processor in at least one of the cores is detected. In one scenario, a change to the thread preference indicator can be detected when any (or more) of the thread preference indicators of the threads currently running in a logical processor of the core has increased or decreased since the core relative performance bias value was last calculated (e.g., at 1004 for a system without SMT or at 1010 for a system with SMT enabled). A change can be detected in a logical processor if a thread running in a logical processor of one of the cores terminates execution and that logical processor becomes idle. In another example, a change to a logical processor can be detected if a new thread of the application is assigned to a previously idle logical processor in the core.

[0114] If it is determined that there has been a change in at least one thread preference indicator or at least one logical processor, the logical processor across all cores is identified at 1106. At 1108, the thread preference indicator of the thread associated with the identified logical processor is retrieved. The process then proceeds back to stage B2 to recalculate the core relative performance bias value and to adjust the shared hardware resource allocation of the core based on the new C-RPB value. For systems with SMT enabled, the process may also proceed to stage B2 to recalculate the LP relative performance bias value for the logical processor in each core and to adjust hardware resource (e.g., core-specific and / or shared hardware resources) allocation, execution cycle allocation, and pipeline component utilization.

[0115] Turn Figure 12 , Figure 12 This is a simplified flowchart of possible operations that can be associated with embodiments of core performance bias in a multi-socket computing system, such as a computing system 800 that includes one or more processors in addition to processor 870. In at least one embodiment, a set of operations corresponds to Figure 12 The activities. In at least one embodiment, a software component (e.g., operating system 840, system application 820, user application 830, etc.) or portions thereof may utilize the set of operations. The software component may include means for performing these operations, such as processor 870 and / or other processors (not shown) in computing system 800. In one example, depending on the specific software component configured to utilize the set of operations, at least some of the operations shown in flow 1200 may be executed by a thread scheduler (e.g., 824, 834, or 844).

[0116] At 1202, thread preference indicators are tracked across all processor cores and across all cores' logical processors. At 1204, a new thread for the application is detected, which will be scheduled on a logical processor within a core of one of the processors. At 1206, the thread preference indicator for the new thread is compared with the thread preference indicators of existing threads already scheduled on one or more cores in each processor. At 1208, a determination is made based on this comparison to determine whether a difference exists on at least one processor. If the thread preference indicator for the new thread differs from at least one thread preference indicator of another thread already scheduled on a core of that processor, a difference exists in the processor. In one example of a system with SMT enabled, the difference can be determined by comparing the thread preference indicator for the new thread with the thread preference indicator within each core that indicates the highest performance preference. However, it should be apparent that any other suitable comparison can be used to determine the difference. If there are no differences on any processor (e.g., all thread preference indicators on all processors are the same as the thread preference indicator for the new thread), then at 1210 the new thread can be assigned to a core on any processor according to the existing scheduling policy, and the process can end.

[0117] If a difference exists on at least one core, the determination of the largest difference at 1212 can be used to identify the best processor for the new thread. A maximum difference exists in a processor if it has a larger cross-core difference when the new thread is scheduled on one of its cores than each of those other processors would have a difference when the new thread is scheduled on one of their cores. The best core can also, or alternatively, be the core in which the highest core performance bias value for the new thread can be calculated based on the currently active cores in the processor. In yet another embodiment, the best processor is the processor in which the new thread will have the highest performance preference (e.g., lowest thread preference indicator) relative to other processors. At 1214, the new thread is scheduled on the identified best processor.

[0118] Figures 13A-13B This is a block diagram depicting an example scenario of maximizing the utilization of core performance bias to schedule application threads according to embodiments of the present disclosure. In this illustrative example, the thread preference indicator can be set between 0 and 255, where 0 represents the highest thread performance preference and thus seeks the maximum performance bias (e.g., the highest proportion of resources), and 255 represents the lowest thread performance preference and thus seeks the minimum performance bias (e.g., the lowest proportion of resources).

[0119] Figure 13AExample processors 1 and 2 are shown, each with two cores: cores A and B on processor 1 and cores C and D on processor 2. In this example, each core has a single logical processor (e.g., a system without SMT enabled). However, it should be noted that these concepts can also be applied to systems with SMT enabled. Thread 1 is running on LP 1 of core A and has a thread preference indicator of 10, while LP 2 of core B is idle. Thread 2 is running on LP 3 of core C and has a thread preference indicator of 255, while LP 4 of core D is idle. A new thread 3 at 1302 has a thread preference indicator of 10 and will be assigned to one of the idle logical processors (LP 2 on core B of processor 1 or LP 4 on core D of processor 2). If the new thread 3 is assigned to LP 2, there will be no difference in processor 1. As indicated by the thread preference indicators of threads 1 and 3 being set to 10, both threads 1 and 3 seek higher performance biases based on their high thread performance preferences. However, if the new thread 3 is assigned to LP 4, there will be a difference in processor 2, since thread 2 has thread preference indicator 255 and the new thread 3 has thread preference indicator 10.

[0120] Figure 13B This illustrates the new thread 3 assigned to LP 4 in core D. Based on the relative relationship between the thread preference indicator values ​​10 and 255 in the corresponding cores C and D, a core relative performance bias value can be calculated for cores C and D. Accordingly, core D can receive a larger proportion of the shared resources of processor 2, such as, for example, shared bus resources, shared cache, and / or system (or main) memory.

[0121] Turn Figure 14The block diagram illustrates an embodiment of a virtual computing system 1400 configured for performance biasing of logical processors and / or cores in a virtualization system. At least one embodiment can be implemented using physical cores that support simultaneous multithreading. At least one other embodiment can be implemented using physical cores that do not support simultaneous multithreading. As illustrated, the virtual computing system 1400 can support both LP performance bias (for SMT-enabled cores) and core performance bias (for SMT-enabled and non-SMT-enabled cores). More specifically, by using thread preference indicators, the computing system 1400 can control logical processor-level optimization (for SMT-enabled cores) and / or core-level optimization (for SMT-enabled and non-SMT-enabled cores) in the virtualization system. Thread preference indicators can be used to calculate LP relative performance bias values ​​and / or core relative performance bias values ​​as previously described herein. LP relative performance bias values ​​can be used in SMT-enabled systems for performance biasing of core-specific hardware resources, shared hardware resources, execution cycles, and pipeline components among the logical processors within each core. Core-relative performance bias values ​​can be used to bias the performance of shared hardware resources across cores in both multi-core systems with and without surface-to-machine (SMT) technology. Core-specific resources may include, for example, core-specific caches (e.g., L2 caches). Shared hardware resources, including non-core resources, may include, for example, shared caches (e.g., L3 caches), on-die memory controllers, point-to-point processor interconnects, bus interfaces, memory, etc. Additionally, if any pipeline components or other components are shared across cores, core-relative performance bias values ​​can be used to bias execution cycles and / or component speeds across those cores.

[0122] In at least one embodiment, the virtual computing system 1400 may include one or more guest virtual machines such as guest virtual machines 1420 and 1430, a hypervisor 1440, and hardware including a processor 1470 and shared hardware resources 1480. Generally, virtualization obscures the hardware characteristics of a computing system and presents an abstract platform that can manage other platforms including different operating systems. The hypervisor 1440 (also referred to as a virtual machine manager) provides the ability to run multiple instances of an operating system and associated guest software simultaneously in a simulated computing environment (referred to herein as "guest virtual machines"). For example, in the virtualized computing system 1400, guest virtual machine 1420 runs operating system 1428 with associated system application 1426, and guest virtual machine 1430 runs operating system 1438 with associated user application 1436. The operating system and applications can run simultaneously by dynamically allocating hardware resources to the operating system (e.g., 1428 and 1438) and applications (e.g., 1426 and 1436) as needed. In this configuration, system application 1426 logically runs on top of operating system 1428, and user application 1436 logically runs on top of operating system 1438.

[0123] exist Figure 14 In the illustrated configuration, guest virtual machines 1420 and 1430, along with hypervisor 1440, can be stored in memory 1488. In this embodiment, hypervisor 1440 can be a Type 2 hypervisor running on an operating system or a managed hypervisor. In an alternative configuration, hypervisor 1440 can be a Type 1 hypervisor running directly on the hardware to control the hardware and manage the guest operating system, or a native / bare-metal hypervisor. In a Type 2 configuration, one or more additional guest virtual machines can be provisioned to run thread preference selector 1442 and thread scheduler 1444.

[0124] The physical hardware under hypervisor 1440 may include processor 1470 and shared hardware resources 1480. Processor 1470 includes core A 1460A and core B 1460B. In a system with SMT enabled, each core may include multiple logical processors (e.g., 1464A(1), 1464A(2), 1464B(1), 1464B(2)) with corresponding threads (e.g., 1465A(1), 1465A(2), 1465B(1), 1465B(2))). Core-specific resources such as core A resource 1490A and core B resource 1490B may include, but are not limited to, core-specific caches (e.g., 1492A, 1492B). Shared hardware resources 1480 may include, but are not limited to, shared cache 1482, bus interface 1484, and memory 1486. In at least one embodiment, memory 1488 is a portion of memory 1486, and memory 1488 may be the main memory (e.g., random access memory (RAM)) for computing system 1400. Storage available in computing system 1400 for storing data and code (e.g., hard disks, solid-state drives, etc.) is not included. Figure 14 As shown in the diagram. Performance biases can be applied to other shared hardware resources, including but not limited to internal registers, access ports, out-of-order microarchitectural features, etc.

[0125] LP performance bias and core performance bias can be supported by various infrastructures (which have been previously described herein) in the virtualized computing system 1400. Specifically, in at least one embodiment, the guest software of guest virtual machines 1420 and 1430 may include corresponding thread preference selectors 1422 and 1432 and corresponding thread schedulers 1424 and 1434. In at least one embodiment, hypervisor 1440 may include thread preference selector 1442 and thread scheduler 1444. A thread preference indicator 1450 may be provided to the hardware. In one example, the thread preference indicator 1450 may be stored in any suitable storage or memory, such as in the hardware registers of processor 1470. If core performance bias is supported in the virtualized computing system 1400, processor 1470 may include core computing circuitry 1472. If LP performance bias is supported in the virtualized computing system 1400, then cores A 1460A and B 1460B of processor 1470 may each include logical processor (LP) computing circuitry 1462A and 1462B. This example illustrates a possible implementation of embodiments of this disclosure. However, it should be understood that any number of different implementations are covered by the broad concepts described herein. For example, additional hypervisors, client machines, or virtual elements may similarly benefit from the broad teachings discussed herein.

[0126] As will be apparent from the preceding description herein, the virtualized computing system 1400 can be configured in any of the following ways: 1) an SMT-enabled system with LP performance bias, 2) an SMT-enabled system with both LP performance bias and core performance bias, or 3) a non-SMT-enabled system with core performance bias. In an SMT-enabled system with LP performance bias, cores 1460A and 1460B may include corresponding LP computing circuits 1462A and 1462B. In an SMT-enabled system with both LP performance bias and core performance bias, cores 1460A and 1460B may include corresponding LP computing circuits 1462A and 1462B, and processor 1470 may include core computing circuit 1472. In a non-SMT-enabled system, processor 1470 may include core computing circuit 1472 for implementing core performance bias. (See reference...) Figures 1-11 Any of the described LP performance biasing features and / or core performance biasing features can be implemented in a virtual environment, such as a virtualized computing system 1400 configured with appropriate hardware (e.g., LP computing circuits 1462A, 1462B, core computing circuits 1472, etc.) and software (e.g., thread preference selectors 1422, 1432, 1442, thread schedulers 1424, 1434, 1444).

[0127] It should be further noted that the relative performance biasing functionality described herein can be further extended to multiple processors across a multi-socket system for performance biasing of resources shared by different processors. Processor performance bias, core performance bias, and LP performance bias can be combined in any suitable manner. For example, in one embodiment, only processor performance bias can be applied to the system. In another embodiment, both processor performance bias and core performance bias can be applied to the system. In yet another embodiment, processor performance bias, core performance bias, and LP performance bias can be applied to the system. In yet another embodiment, both processor performance bias and LP performance bias can be applied to the system. LP performance bias and core performance bias can be performed as previously described herein. Processor performance bias can be performed in a manner similar to core performance bias as previously described herein. Furthermore, any of these embodiments can be implemented in a virtualized environment.

[0128] The accompanying drawings described below detail exemplary architectures and systems for implementing the embodiments described above. In some embodiments, one or more hardware components and / or instructions described above are emulated or implemented as software modules as detailed below. Other computer architecture designs known in the art, such as processors, mobile devices, computing systems, and components thereof, may also be used (or alternatively). Generally, suitable computer architectures for the embodiments disclosed herein may include, but are not limited to, those described below. Figures 15-23The configuration shown in the figure.

[0129] The embodiments of the instructions(s) described in detail above can be implemented in a “generic vector-friendly instruction format,” which is described in detail below. In other embodiments, another instruction format is used instead of such a format; however, the descriptions below of write mask registers, various data transformations (mixing, broadcasting, etc.), addressing, etc., generally apply to the descriptions of the embodiments of the instructions(s) above. Furthermore, exemplary systems, architectures, and pipelines are described in detail below. The embodiments of the instructions(s) above can be executed on such systems, architectures, and pipelines, but are not limited to those systems, architectures, and pipelines described in detail.

[0130] An instruction set may include one or more instruction formats. A given instruction format may define various fields (e.g., number of bits, bit positions) to specify the operation to be performed (e.g., opcode) and operand(s) and / or other data fields (e.g., mask) to which the operation will be performed, and so on. Some instruction formats are further decomposed by defining instruction templates (or subformats). For example, an instruction template for a given instruction format may be defined as a different subset of the fields of that instruction format (the included fields are generally in the same order, but at least some fields have different bit positions because fewer fields are included), and / or defined as a given field that is interpreted in a different way. Thus, each instruction of the ISA is expressed using a given instruction format (and, if defined, according to a given instruction template in the instruction template of that instruction format) and includes fields for specifying the operation and operands. For example, the exemplary ADD (addition) instruction has a specific opcode and instruction format, which includes an opcode field for specifying the opcode and an operand field for selecting operands (source 1 / destination and source 2); and the appearance of the ADD instruction in the instruction stream will cause the operand field to contain specific content for selecting the specific operand. Sets of SIMD extensions known as Advanced Vector Extensions (AVX) (AVX1 and AVX2) and utilizing Vector Extensions (VEX) encoding schemes have been introduced and / or released (see, for example, September 2014). See the IA-64 and IA-32 architecture software developer manual; and also see the October 2014 edition. (Advanced Vector Extension Programming Reference).

[0131] Figure 15This is a block diagram of a register architecture 1500 according to one embodiment of the present disclosure. In the illustrated embodiment, there are 32 512-bit wide vector registers 1510; these registers are referenced as zmm0 to zmm31. The lower-order 256 bits of the lower 16 zmm registers are overlaid on registers ymm0-15. The lower-order 128 bits of the lower 16 zmm registers (the lower-order 128 bits of the ymm registers) are overlaid on registers xmm0-15.

[0132] In other words, the vector length field is selected between a maximum length and one or more other shorter lengths, each of which is half the previous length, and instruction templates without a vector length field operate on the maximum vector length. Furthermore, in one embodiment, a Class B instruction template of a dedicated vector-friendly instruction format operates on compressed or scalar single / double-precision floating-point data and compressed or scalar integer data. Scalar operations are performed on the lowest-order data element positions in the zmm / ymm / xmm registers; depending on the embodiment, higher-order data element positions either remain the same as before the instruction or are zeroed out.

[0133] Write mask register 1515—In the illustrated embodiment, there are eight write mask registers (k0 to k7), each 64 bits in size. In an alternative embodiment, write mask register 1515 is 16 bits in size. As previously mentioned, in one embodiment, vector mask register k0 cannot be used as a write mask; when the encoding of the normal indicator k0 is used as the write mask, it selects the hardwired write mask 0xFFFF, effectively disabling write masking for that instruction.

[0134] General Purpose Register 1525 — In the illustrated embodiment, there are sixteen 64-bit general purpose registers that are used in conjunction with existing x86 addressing modes for addressing memory operands. These registers are referenced by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 through R15.

[0135] A scalar floating-point stack register file (x87 stack) 1545 is overlaid with an MMX compact integer flat register file 1550. In the illustrated embodiment, the x87 stack is an octal stack used to perform scalar floating-point operations on 32 / 64 / 80-bit floating-point data using x87 instruction set extensions; while the MMX registers are used to perform operations on 64-bit compact integer data and to store operands for some operations performed between the MMX and XMM registers.

[0136] Alternative embodiments of this disclosure may use wider or narrower registers. Furthermore, alternative embodiments of this disclosure may use more, fewer, or different register files and registers.

[0137] Processor cores can be implemented in different ways, for different purposes, and in different processors. For example, implementations of such cores may include: 1) general-purpose ordered cores intended for general-purpose computing; 2) high-performance general-purpose out-of-order cores intended for general-purpose computing; and 3) dedicated cores intended primarily for graphics and / or scientific (throughput) computing. Implementations of different processors may include: 1) CPUs, which include one or more general-purpose ordered cores and / or one or more general-purpose out-of-order cores intended for general-purpose computing; and 2) coprocessors, which include one or more dedicated cores intended primarily for graphics and / or scientific (throughput) computing. These different processors result in different computer system architectures, which may include: 1) a coprocessor on a separate chip from the CPU; 2) a coprocessor in the same package as the CPU but on a separate die; 3) a coprocessor on the same die as the CPU (in which case such a coprocessor is sometimes referred to as dedicated logic or a dedicated core, such as integrated graphics and / or scientific (throughput) logic); and 4) a system-on-a-chip that may include the described CPU (sometimes referred to as application cores or application processors), the coprocessors described above, and additional functionality on the same die. Exemplary core architectures are then described, followed by exemplary processors and computer architectures.

[0138] Figure 16A This is a block diagram illustrating an exemplary ordered pipeline and an exemplary out-of-order release / execution pipeline with register renaming, according to one or more embodiments of the present disclosure. Figure 16B This is a block diagram illustrating exemplary embodiments of ordered architecture cores to be included in a processor according to one or more embodiments of the present disclosure and exemplary out-of-order release / execution architecture cores with register renaming. Figures 16A-16B The solid-line boxes in the diagram illustrate ordered pipelines and ordered cores, while the optional additions to the dashed boxes illustrate register renaming, out-of-order release / execution pipelines, and cores. Since the ordered aspect is a subset of the out-of-order aspect, the out-of-order aspect will be described.

[0139] exist Figure 16A In the processor pipeline 1600, there are fetch stage 1602, length decoding stage 1604, decoding stage 1606, allocation stage 1608, renaming stage 1610, scheduling (also known as dispatch or issue) stage 1612, register read / memory read stage 1614, execution stage 1616, write-back / memory write stage 1618, exception handling stage 1622, and commit stage 1624.

[0140] Figure 16B A processor core 1690 is shown, which includes a front-end unit 1630 coupled to an execution engine unit 1650, and both the front-end unit 1630 and the execution engine unit 1650 are coupled to a memory unit 1670. Core 1690 can be a Reduced Instruction Set Computing (RISC) core, a Complex Instruction Set Computing (CISC) core, a Very Long Instruction Word (VLIW) core, or a hybrid or alternative core type. Alternatively, core 1690 can be a dedicated core, such as, for example, a network or communication core, a compression engine, a coprocessor core, a general-purpose computing graphics processing unit (GPGPU) core, a graphics core, etc. Furthermore, processor core 1690 and its components represent example architectures that can be used to implement cores 160A-B, 860A-D, and 1460A-B, and their respective components.

[0141] Front-end unit 1630 includes branch prediction unit 1632 coupled to instruction cache unit 1634 coupled to instruction translation lookup buffer (TLB) 1636 coupled to instruction fetch unit 1638 coupled to decoding unit 1640. Decoding unit 1640 (or decoder) decodes instructions and generates one or more micro-operations, microcode entry points, microinstructions, other instructions, or other control signals as output, which are decoded from, or otherwise reflect, the original instructions or derived from them. Decoding unit 1640 can be implemented using various different mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLAs), microcode read-only memory (ROMs), etc. In one embodiment, core 1690 includes microcode ROM or other media (e.g., in decoding unit 1640, or otherwise within front-end unit 1630) storing microcode for certain macro instructions. The decoding unit 1640 is coupled to the rename / allocator unit 1652 in the execution engine unit 1650.

[0142] Execution engine unit 1650 includes a renaming / allocator unit 1652 coupled to a retirement unit 1654 and a set 1656 of one or more scheduler units. The scheduler units 1656 represent any number of different schedulers, including reservation stations, central instruction windows, etc. The scheduler units 1656 are coupled to physical register file units 1658. Each physical register file unit in the physical register file units 1658 represents one or more physical register files, where different physical register files store one or more different data types, such as scalar integers, scalar floating-point numbers, compressed integers, compressed floating-point numbers, vector integers, vector floating-point numbers, status (e.g., an instruction pointer as the address of the next instruction to be executed), etc. In one embodiment, the physical register file units 1658 include vector register units, write mask register units, and scalar register units. These register units can provide architectural vector registers, vector mask registers, and general-purpose registers. Multiple physical register file units 1658 are overlapped by retirement units 1654 to illustrate various ways in which register renaming and out-of-order execution can be implemented (e.g., using multiple reorder buffers and multiple retirement register files; using multiple future files, multiple history buffers, and multiple retirement register files; using register mappings and register pools, etc.). Retirement units 1654 and multiple physical register file units 1658 are coupled to multiple execution clusters 1660. Multiple execution clusters 1660 include a set 1662 of one or more execution units and a set 1664 of one or more memory access units. Execution units 1662 can perform various operations (e.g., shift, addition, subtraction, multiplication) and can perform operations on various data types (e.g., scalar floating-point, compressed integer, compressed floating-point, vector integer, vector floating-point). While some embodiments may include multiple execution units dedicated to a particular function or set of functions, other embodiments may include only one execution unit or multiple execution units that all perform all functions.

[0143] Multiple scheduler units 1656, multiple physical register file units 1658, and multiple execution clusters 1660 are shown as possibly multiple, because some embodiments create separate pipelines for certain types of data / operations (e.g., scalar integer pipelines, scalar floating-point / compact integer / compact floating-point / vector integer / vector floating-point pipelines, and / or memory access pipelines each having their own scheduler unit, multiple physical register file units, and / or execution clusters—and in the case of separate memory access pipelines, some embodiments are implemented where only the execution cluster of that pipeline has multiple memory access units 1664). It should also be understood that, in the case of using separate pipelines, one or more of these pipelines may be out-of-order deployment / execution, and the remaining pipelines may be ordered.

[0144] A set of memory access units 1664 is coupled to a memory unit 1670, which includes a data TLB unit 1672, which is coupled to a data cache unit 1674, which is coupled to a Level 2 (L2) cache unit 1676. In one exemplary embodiment, the memory access unit 1664 may include a load unit, a memory address unit, and a memory data unit, each of which is coupled to the data TLB unit 1672 in the memory unit 1670. An instruction cache unit 1634 is also coupled to the Level 2 (L2) cache unit 1676 in the memory unit 1670. The L2 cache unit 1676 is coupled to one or more other levels of cache and ultimately to main memory.

[0145] As an example, the exemplary register renaming out-of-order release / execution core architecture may implement pipeline 1600 as follows: 1) Instruction fetch 1638 executes fetch stage 1602 and length decoding stage 1604; 2) Decoding unit 1640 executes decoding stage 1606; 3) Rename / allocator unit 1652 executes allocation stage 1608 and rename stage 1610; 4) (multiple) scheduler units 1656 execute scheduling stage 1612; 5) (multiple) physical register file units 1658 and memory unit 1670 execute register read / memory read stage 1614; execution cluster 1660 executes execution stage 1616; 6) memory unit 1670 and (multiple) physical register file units 1658 execute write-back / memory write stage 1618; 7) each unit may involve exception handling stage 1622; and 8) retirement unit 1654 and (multiple) physical register file units 1658 execute commit stage 1624.

[0146] Core 1690 may support one or more instruction sets (e.g., the x86 instruction set (with some extensions added with newer versions); the MIPS instruction set of MIPS Technologies, Inc., Sunnyvale, California; the ARM instruction set of ARM Holdings, Inc., Sunnyvale, California (with optional additional extensions such as NEON)), including the instructions described herein. In one embodiment, Core 1690 includes logic for supporting compressed data instruction set extensions (e.g., AVX1, AVX2), thereby allowing the use of compressed data to perform operations used by many multimedia applications.

[0147] It should be understood that a core may support multithreading (SMT) (execution of two or more parallel operations or a set of threads), and this multithreading can be accomplished in various ways, including time-division multithreading, simultaneous multithreading (where a single physical core provides a logical core for each thread in the simultaneous multithreading of the physical core), or combinations thereof (e.g., time-division fetching and decoding, and subsequent operations such as...). Simultaneous multithreading in hyper-threading technology.

[0148] Although register renaming is described in the context of out-of-order execution, it should be understood that register renaming can also be used in ordered architectures. While the illustrated processor embodiment also includes separate instruction and data cache units 1634 / 1674 and a shared L2 cache unit 1676, alternative embodiments may have a single internal cache for both instructions and data, such as, for example, a Level 1 (L1) internal cache or multiple levels of internal caches. In some embodiments, the system may include a combination of internal caches and external caches located outside the core and / or processor. Alternatively, all caches may be located outside the core and / or processor.

[0149] Figures 17A-17B The diagram illustrates a more specific exemplary ordered core architecture, where the core is one of several logic blocks within a chip (including other cores of the same and / or different types). Depending on the application, the logic block communicates with some fixed functional logic, memory I / O interfaces, and other necessary I / O logic via a high-bandwidth interconnect network (e.g., a ring network). Figures 17A-17B The ordered core architecture shown in the figure represents an example architecture that can be used to implement cores 160A-B, 860A-D, and 1460A-B, as well as at least some of their respective components.

[0150] Figure 17AThis is a block diagram of a single processor core according to one or more embodiments of the present disclosure, its connection to an on-die interconnect network 1702, and a local subset 1704 of its second-level (L2) cache. In one embodiment, the instruction decoder 1700 supports the x86 instruction set with a compact data instruction set extension. The L1 cache 1706 allows low-latency access to cache memory into scalar and vector units. Although in one embodiment (for design simplification), scalar unit 1708 and vector unit 1710 use separate register sets (scalar register 1712 and vector register 1714, respectively), and data transferred between these registers is written to memory and subsequently read back from the first-level (L1) cache 1706, alternative embodiments of the present disclosure may use different methods (e.g., using a single register set or including a communication path that allows data to be transferred between these two register sets without being written and read back).

[0151] The local subset 1704 of the L2 cache is part of the global L2 cache, which is divided into multiple separate local subsets, one for each processor core. Each processor core has a direct access path to its own local subset 1704 of the L2 cache. Data read by a processor core is stored in its L2 cache subset 1704 and can be accessed quickly in parallel with other processor cores accessing their own local L2 cache subsets. Data written by a processor core is stored in its own L2 cache subset 1704 and is dumped from other subsets if necessary. A ring network ensures the consistency of shared data. The ring network 1702 is bidirectional to allow agents such as processor cores, L2 caches, and other logic blocks to communicate with each other within the chip. Each ring data path is 1012 bits wide in each direction.

[0152] Figure 17B It is based on one or more embodiments of this disclosure Figure 17A An expanded diagram of a portion of the processor core. Figure 17B This includes the L1 data cache 1706A portion of the L2 cache 1704, and further details regarding the vector unit 1710 and vector register 1714. Specifically, the vector unit 1710 is a 16-wide vector processing unit (VPU) (see 16-wide ALU 1728) that executes one or more of integer, single-precision floating-point, and double-precision floating-point instructions. This VPU supports mixing of register inputs via mixing unit 1720, numerical conversion via value conversion units 1722A-B, and copying of memory inputs via copy unit 1724. A write mask register 1726 allows the writing of predicted vectors.

[0153] Figure 18 This is a block diagram of a processor 1800 that may have more than one core, may have an integrated memory controller, and may have an integrated graphics device, according to one or more embodiments of the present disclosure. Figure 18 The solid-line box illustration shows a processor 1800 having a single core 1802A, a system proxy unit 1810, and a set of one or more bus controller units 1816, while the optional additional illustration with dashed boxes shows an alternative processor 1800 having multiple cores 1802A-N, a set of one or more integrated memory controller units 1814 from the system proxy units 1810, and dedicated logic 1808. The processor 1800 and its components (e.g., cores 1802A-N, cache units(s) 1804A-N, shared cache units(s) 1806, etc.) represent example architectures that can be used to implement processors 170, 870, 1470, and at least some of their respective components.

[0154] Therefore, different implementations of processor 1800 may include: 1) a CPU, wherein dedicated logic 1808 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores), and cores 1802A-N are one or more general-purpose cores (e.g., general-purpose ordered cores, general-purpose out-of-order cores, or a combination of both); 2) a coprocessor, wherein cores 1802A-N are a large number of dedicated cores designed primarily for graphics and / or scientific (throughput); and 3) a coprocessor, wherein cores 1802A-N are a large number of general-purpose ordered cores. Thus, processor 1800 may be a general-purpose processor, coprocessor, or dedicated processor, such as, for example, a network or communication processor, a compression engine, a graphics processor, a GPGPU (General-Purpose Graphics Processing Unit), a high-throughput integrated many-core (MIC) coprocessor (including 30 or more cores), an embedded processor, etc. The processor may be implemented on one or more chips. Processor 1800 may be part of one or more substrates, and / or may be implemented on one or more substrates using any of a variety of process technologies (e.g., BiCMOS, CMOS, or NMOS).

[0155] The memory hierarchy includes one or more cache levels within the core, a set 1806 of one or more shared cache units, and external memory (not shown) coupled to a set 1814 of integrated memory controller units. The set 1806 of shared cache units may include one or more intermediate-level caches, such as Level 2 (L2), Level 3 (L3), Level 4 (L4), or other levels of cache, Last Level Cache (LLC), and / or combinations thereof. While in one embodiment, ring-based interconnect units 1812 interconnect integrated graphics logic 1808, the set 1806 of shared cache units, and system proxy units 1810 / (multiple) of integrated memory controller units 1814, alternative embodiments may use any number of known techniques to interconnect such units. In one embodiment, consistency is maintained between one or more cache units 1806 and cores 1802A-N.

[0156] In some embodiments, one or more cores 1802A-N can implement multithreading, including simultaneous multithreading. System agent 1810 includes those components that coordinate and operate core 1802A-N. System agent unit 1810 may include, for example, a power control unit (PCU) and a display unit. The PCU may be, or may include, the logic and components required to regulate the power state of core 1802A-N and integrated graphics logic 1808. The display unit is used to drive one or more externally connected displays.

[0157] In embodiments that provide logical processor performance bias or core performance bias, other hardware and / or software can acquire and utilize thread preference indicators to achieve desired (or required) performance tuning of threads on a core and / or desired (or required) performance tuning of the processor's cores. For example, if computing systems 100, 800, or 1400 are implemented with a PCU (e.g., the PCU of system agent unit 1810), the PCU can acquire thread preference indicators (e.g., 150, 850, 1450). The PCU can evaluate the thread preference indicator and provide the information derived from evaluating the thread preference indicator to one or more cores to achieve an optimal power and performance balance between threads and / or between cores for each core.

[0158] The 1802A-N cores can be homogeneous or heterogeneous in terms of their instruction set architecture; that is, two or more cores in the 1802A-N cores may be able to execute the same instruction set, while other cores may be able to execute only a subset of that instruction set or a different instruction set.

[0159] Figures 19-22This is a block diagram of an exemplary computer architecture that can be used to implement the performance bias teachings herein. 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, cellular phones, portable media players, handheld devices, and various other electronic devices are also suitable. Generally, a wide variety of systems or electronic devices capable of incorporating processors and / or other execution logic as disclosed herein are generally suitable for implementing the performance bias characteristics disclosed herein. Specifically, in this document (e.g., referring to…),… Figures 1-14 The disclosed logic processor performance bias characteristics, core performance bias characteristics, processor performance bias characteristics, and / or thread scheduling characteristics can be used as follows: Figures 19-22 Any one or more of the computer architectures can be implemented.

[0160] Now for reference Figure 19 The diagram illustrates a system 1900 according to at least one embodiment of the present disclosure. System 1900 may include one or more processors 1910, 1915 coupled to a controller hub 1920. In one embodiment, controller hub 1920 includes a graphics memory controller hub (GMCH) 1990 and an input / output hub (IOH) 1950 (which may be on separate chips); GMCH 1990 includes memory and a graphics controller, to which memory 1940 and a coprocessor 1945 are coupled; IOH 1950 couples an input / output (I / O) device 1960 to GMCH 1990. Alternatively, one or both of the memory and graphics controller may be integrated within a processor (as described herein), with memory 1940 and coprocessor 1945 directly coupled to processor 1910, and controller hub 1920 and IOH 1950 residing on a single chip.

[0161] The optionality of the additional processor 1915 Figure 19 The numbers are indicated by dashed lines. Each processor 1910, 1915 may include one or more of the processing cores described herein, and may be a version of processor 1800.

[0162] The memory 1940 may be, for example, dynamic random access memory (DRAM), phase-change memory (PCM), or a combination of both. In at least one embodiment, the controller hub 1920 communicates with the processors(s) 1910, 1915 via a multi-branch bus such as a front-side bus (FSB), a point-to-point interface such as a fast path interconnect (QPI), or a similar connection 1995.

[0163] In one embodiment, the coprocessor 1945 is a dedicated processor, such as, for example, a high-throughput MIC processor, a network or communications processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, and so on. In one embodiment, the controller hub 1920 may include an integrated graphics accelerator.

[0164] There can be various differences between physical resources 1910 and 1915 in terms of a range of quality metrics, including architecture, microarchitecture, thermal and power consumption characteristics.

[0165] In one embodiment, processor 1910 executes instructions that control general-type data processing operations. Embedded within these instructions may be coprocessor instructions. Processor 1910 identifies these coprocessor instructions as having a type that should be executed by an attached coprocessor 1945. Therefore, processor 1910 issues these coprocessor instructions (or control signals representing coprocessor instructions) to coprocessor 1945 on a coprocessor bus or other interconnect. Coprocessors 1945(a) receive and execute the received coprocessor instructions.

[0166] See now Figure 20 The diagram shown is a block diagram of a first, more specific, exemplary system 2000 according to one or more embodiments of the present disclosure. Figure 20 As shown, the multiprocessor system 2000 is a point-to-point interconnect system and includes a first processor 2070 and a second processor 2080 coupled via a point-to-point interconnect 2050. Each of processors 2070 and 2080 may be a version of processor 1800. In at least one embodiment of this disclosure, processors 2070 and 2080 are processors 1910 and 1915, respectively, and coprocessor 2038 is coprocessor 1945. In another embodiment, processors 2070 and 2080 are processor 1910 and coprocessor 1945, respectively. Furthermore, processors 2070 and 2080 and their components (e.g., cores 2074a-b and 2084a-b, shared caches 2071 and 2081, memories 2032 and 2034, etc.) represent examples of processors that can be used to implement processors 170, 870, and 1470 and at least some of their respective components.

[0167] Processors 2070 and 2080 may each include one or more cores 2074a-b and 2084a-b. Processors 2070 and 2080 may also include integrated memory controller (IMC) units 2072 and 2082, respectively. Processor 2070 also includes point-to-point (PP) interfaces 2076 and 2078 as part of its bus controller unit; similarly, the second processor 2080 includes PP interfaces 2086 and 2088. Processors 2070 and 2080 may exchange information via a PP interface 2050 using point-to-point (PP) interface circuitry 2078 and 2088. Figure 20 As shown, IMCs 2072 and 2082 couple the processor to corresponding memories, namely memories 2032 and 2034, which may be portions of the main memory locally attached to the respective processor. Memory 2032 and / or 2034 may store various data used by processors 2070 and 2080 to implement certain operations outlined herein.

[0168] Processors 2070 and 2080 can each exchange information with chipset 2090 via respective PP interfaces 2052 and 2054 using point-to-point interface circuits 2076, 2094, 2086, and 2098. As shown herein, chipset 2090 is separate from processing elements 2070 and 2080. However, in embodiments, chipset 2090 is integrated with processing elements 2070 and 2080. Furthermore, chipset 2090 can be partitioned in different ways to have fewer or more integrated circuits. Chipset 2090 can optionally exchange information with coprocessor 2038 via high-performance interface 2039. In one embodiment, coprocessor 2038 is a dedicated 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, and so on.

[0169] Shared caches (e.g., 2071 and / or 2081) may be included in either processor or external to both processors but connected to them via a PP interconnect, such that if the processors are placed in a low-power mode, local cache information (e.g., data requested by the processor) of either or both processors may be stored in the shared cache. Shared caches 2071 and 2081 represent examples of shared caches 182, 882, and 1482.

[0170] Chipset 2090 can be coupled to first bus 2010 via interface 2096. In one embodiment, first bus 2010 may be a peripheral component interconnect (PCI) bus or a bus such as PCI Fast bus or another third-generation I / O interconnect bus, but the scope of this disclosure is not limited thereto.

[0171] like Figure 20 As shown, various I / O devices 2014 may be coupled to a first bus 2010 together with a bus bridge 2018, which couples the first bus 2010 to a second bus 2020. In one embodiment, one or more additional processors 2015, such as a coprocessor, a high-throughput MIC processor, a GPGPU, an accelerator (such as, for example, a graphics accelerator or digital signal processing (DSP) unit), a field-programmable gate array, or any other processor, are coupled to the first bus 2010. In one embodiment, the second bus 2020 may be a low pin count (LPC) bus. In one embodiment, various devices may be coupled to the second bus 2020, including, for example, a keyboard and / or mouse 2022 or other input devices (e.g., a touchscreen, trackball, joystick, etc.), communication devices 2026 (e.g., a modem, network interface card, or other types of communication devices that can communicate via a computer network), and a storage unit 2028, such as a disk drive that may include instruction / code and data 2030 or other mass storage devices. Furthermore, the audio I / O 2024 can be coupled to the second bus 2020. Note that other architectures are possible. For example, instead of... Figure 20 The point-to-point architecture allows the system to implement multi-branch buses or other similar architectures.

[0172] Now for reference Figure 21 The diagram shown is a block diagram of a second, more specific, exemplary system 2100 according to at least one embodiment of the present disclosure. Figure 20 and 21 Similar elements in the figure use similar reference numerals, and from Figure 21 The middle part is omitted Figure 20 certain aspects to avoid confusion Figure 21 Other aspects.

[0173] Figure 21 The illustrated processors 2070 and 2080 may include integrated memory and I / O control logic (“CL”) 2072 and 2082, respectively. Therefore, CL 2072 and 2082 include an integrated memory controller unit and I / O control logic. Figure 21 The diagram shows that not only are the memories 2032 and 2034 coupled to CLs 2072 and 2082, but the I / O device 2114 is also coupled to the control logic 2072 and 2082. The conventional I / O device 2115 is coupled to the chipset 2090.

[0174] Now for reference Figure 22 The diagram shown is a block diagram of a SoC 2200 according to at least one embodiment of the present disclosure. Figure 18Similar elements in the figure use similar reference numerals. Additionally, dashed boxes are optional features on more advanced SoCs. Figure 22 In this configuration, multiple interconnect units 2202 are coupled to: an application processor 2210, which includes a set of one or more cores 1802A-N and multiple shared cache units 1806; a system proxy unit 1810; multiple bus controller units 1816; multiple integrated memory controller units 1814; a set of one or more coprocessors 2220, which may include integrated graphics logic, an image processor, an audio processor, and a video processor; a static random access memory (SRAM) unit 2230; a direct memory access (DMA) unit 2232; and a display unit 2240 for coupling to one or more external displays. In one embodiment, the multiple coprocessors 2220 include dedicated processors, such as, for example, network or communication processors, compression engines, GPGPUs, high-throughput MIC processors, or embedded processors, etc.

[0175] The various embodiments of the mechanisms disclosed herein can be implemented in hardware, software, firmware, or a combination of such implementations. Embodiments of this disclosure can be implemented at least in part as computer programs or program code executable on a programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0176] Program code (such as, Figure 20 The code 2030 shown in the figure is applied to input instructions to perform at least some of the functions described herein and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, the processing system includes any system having a processor, such as, for example, a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0177] The program code can be implemented using a high-level procedural or object-oriented programming language to communicate with the processing system. Assembly or machine language can also be used if needed. In fact, the mechanisms described herein are not limited to any particular programming language. In any case, the language can be a compiled or interpreted language.

[0178] One or more aspects of at least one embodiment can be implemented by representational instructions stored on a machine-readable medium, which represent various logics in a processor, and which, when read by a machine, cause the machine to manufacture logic for performing the techniques described herein. Such representations, referred to as “IP cores,” can be stored on tangible machine-readable media and can be supplied to various customers or production facilities for loading into manufacturing machines that actually manufacture the logic or processor.

[0179] Such machine-readable storage media can include, but are not limited to, non-transitory, tangible arrangements of articles made or formed by a machine or device, including storage media such as hard disks; any other type of disk, including floppy disks, optical disks, compact disc read-only memory (CD-ROM), rewritable compact discs (CD-RW), and magneto-optical disks; semiconductor devices such as read-only memory (ROM), random access memory (RAM) such as dynamic random access memory (DRAM) and static random access memory (SRAM), erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM); phase-change memory (PCM); magnetic cards or optical cards; or any other type of medium suitable for storing electronic instructions.

[0180] Therefore, embodiments of this disclosure also include non-transitory tangible machine-readable media containing instructions or design data, such as a hardware description language (HDL), that defines the architectures, circuits, devices, processors, and / or system characteristics described herein. These embodiments are also referred to as program products.

[0181] In some cases, instruction translators can be used to translate instructions from a source instruction set to a target instruction set. For example, an instruction translator can transform instructions (e.g., using static binary transformation, including dynamically compiled binary transformation), modify, emulate, or otherwise convert them into one or more other instructions to be processed by the kernel. Instruction translators can be implemented in software, hardware, firmware, or a combination thereof. Instruction translators can be on the processor, off the processor, or partially on and partially off the processor.

[0182] Figure 23 This is a block diagram illustrating the use of a software instruction converter to convert binary instructions in a source instruction set into binary instructions in a target instruction set, according to embodiments of the present disclosure. In the illustrated embodiment, the instruction converter is a software instruction converter; however, alternatively, the instruction converter may be implemented using software, firmware, hardware, or various combinations thereof. Figure 23This illustrates how an x86 compiler 2304 can be used to compile a program of the form of a high-level language 2302 to generate x86 binary code 2306 that can be natively executed by a processor 2316 having at least one x86 instruction set core. A processor 2316 having at least one x86 instruction set core refers to any processor that performs substantially the same function as an Intel processor having at least one x86 instruction set core by compatibly executing or otherwise performing: 1) an essential part of the instruction set of an Intel x86 instruction set core, or 2) a version of object code for an application or other software aimed at running on an Intel processor having at least one x86 instruction set core to achieve substantially the same results as an Intel processor having at least one x86 instruction set core. The x86 compiler 2304 refers to a compiler operable to generate x86 binary code 2306 (e.g., object code) that can be executed on a processor 2316 having at least one x86 instruction set core, with or without additional linking processing. Similarly, Figure 23 A program in the form of a high-level language 2302 can be compiled using an alternative instruction set compiler 2308 to generate alternative instruction set binary code 2310 that can be natively executed by a processor 2314 that does not have at least one x86 instruction set core (e.g., a processor with a core that executes the MIPS instruction set of MIPS Technologies, Inc., Sunnyvale, California, and / or the ARM instruction set of ARM Holdings, Inc., Sunnyvale, California). An instruction converter 2312 is used to translate the x86 binary code 2306 into code that can be natively executed by the processor 2314 that does not have an x86 instruction set core. This translated code is unlikely to be identical to the alternative instruction set binary code 2310 because an instruction converter capable of doing so would be difficult to manufacture; however, the translated code will perform general operations and consists of instructions from the alternative instruction set. Therefore, the instruction converter 2312 represents, through emulation, simulation, or any other process, software, firmware, hardware, or a combination thereof that allows a processor or other electronic device without an x86 instruction set processor or core to execute the x86 binary code 2306.

[0183] As outlined in this article Figure 1 , Figure 8 as well as Figures 14-23The computing system may include software for implementing (or facilitating) at least some of the dynamic relative performance biasing functions for cores and / or logic processors. For example, system applications (e.g., 120, 820, 1420), user applications (e.g., 130, 830, 1430), operating systems (e.g., 140, 840, 1428, 1438), hypervisors (e.g., 1440), thread preference selectors (e.g., 122, 132, 142, 822, 832, 842, 1422, 1432, 1442), and thread schedulers (e.g., 124, 134, 144, 824, 834, 844, 1424, 1434, 1444) may facilitate some of the operations described herein. Note that in one example, each of these elements may be coupled to an internal structure (e.g., processors 170, 870, 1470, memory 180, 880, 1480, etc.) to achieve the intended function. In other embodiments, these dynamic relative performance biasing functions may be performed externally to these elements or included in some other components or computing system to achieve the intended function. The computing system may include such software (or reciprocating software) that can coordinate with other elements (e.g., hardware, firmware) to achieve the operation as outlined herein. For example, at least some of the dynamic relative performance biasing activities may be performed by hardware (e.g., LP computing circuits 162A-B, 1462A-B, core computing circuits 872, 1472), implemented externally to the core or processor, or included in some other components coupled to the processing device (e.g., 170, 870, 1470) to achieve the intended function. Generally, one or more devices, host, or computing systems may include any suitable algorithms, hardware, software, firmware, components, modules, interfaces, or objects that enable their operation.

[0184] Note that the interactions can be described based on two, three, four, or more processors, logic processors, user applications, system applications, operating systems, thread selectors, thread preference selectors, LP computing circuits, core computing circuits, and / or other components, using the numerous examples provided in this document. However, this is done only for clarity and illustrative purposes. It should be understood that the system can be combined or divided (e.g., segmented, partitioned, separated, etc.) in any suitable manner. Along with similar design alternatives, the circuits, logic, applications, modules, components, processors, devices, systems, registers, software, hardware, and... Figure 1 , Figure 8 and Figures 14-23Any of the other components can be combined in a variety of possible configurations, all of which are clearly within the broad scope of this specification. For example, the LP computing circuitry and the core computing circuitry can be combined with or coordinated with other hardware (such as scheduling and / or allocation hardware units) to efficiently bias the hardware resources, execution cycles, and / or component speeds allocated to the logic processor based on LP-RPB values ​​and / or to efficiently bias the hardware resources, execution cycles, and / or component speeds allocated to the core based on C-RPB values. It should be understood that Figure 1 , Figure 8 and Figures 14-23 The system (and its teachings) is easily scalable and can accommodate a large number of components as well as more complex / refined layouts and configurations. Accordingly, the examples provided should not limit the scope of systems that can potentially be applied to countless other architectures, nor should they inhibit the broad teachings of this system.

[0185] It is equally important to note that the operations in the foregoing flowcharts and the diagrams illustrating the interactions only illustrate some of the possible dynamic relative performance bias operations that may be performed by or within computing systems 100, 800, and 1400. Some of these operations may be removed or deleted where appropriate, or these operations may be significantly modified or altered without departing from the scope of this disclosure. Additionally, the timing of these operations may be significantly altered. For example, the timing and / or sequence of certain operations may be varied relative to other operations to be performed before, after, or in parallel with other operations, or based on any suitable combination thereof. The foregoing operational flow has been provided for purposes of example and discussion. The embodiments described herein offer considerable flexibility, as any suitable arrangement, timing, configuration, and timing mechanism may be provided without departing from the teachings of this disclosure.

[0186] As used herein, unless explicitly stated otherwise, the phrase “at least one” refers to any combination of the items, elements, conditions, or activities mentioned. For example, “at least one of X, Y, and Z” is intended to mean any of the following: 1) at least one X, but not Y, and not Z; 2) at least one Y, but not X, and not Z; 3) at least one Z, but not X, and not Y; 4) at least one X and at least one Y, but not Z; 5) at least one X and at least one Z, but not Y; 6) at least one Y and at least one Z, but not X; or 7) at least one X, at least one Y, and at least one Z. Furthermore, unless explicitly stated otherwise, the numbered adjectives “first,” “second,” “third,” etc., are intended to distinguish the specific terms that follow them (e.g., element, condition, module, activity, operation, declarative element, etc.), but are not intended to indicate any type of order, rank, importance, chronological order, or hierarchy of the terms they modify. For example, “first X” and “second X” are intended to specify two separate X elements that are not necessarily limited by any order, rank, importance, chronological order, or hierarchy of these two elements. Furthermore, references to "one embodiment," "embodiment," "some embodiments," etc., in the specification indicate that the described embodiments(s) may include a particular feature, structure, or characteristic; however, each embodiment may or may not include that particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment.

[0187] While this specification contains numerous details of specific implementations, these should not be construed as limiting any embodiment or the scope of the claim, but rather as describing features specific to embodiments of the subject matter disclosed herein. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. For example, an LP relative performance bias for a logic processor, a relative performance bias for a core, a relative performance bias for a processor, or any combination thereof may be implemented as previously described herein and in other ways that may not be specifically outlined herein. Conversely, the various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments. Furthermore, although features may be described above as being used in certain combinations and even initially claimed in this way, one or more features from a claimed combination may be removed from that combination in some cases, and the claimed combination may be for sub-combinations or variations thereof.

[0188] Numerous other changes, substitutions, variations, alterations and modifications may be apparent to those skilled in the art, and this disclosure is intended to cover all such changes, substitutions, variations, alterations and modifications as falling within the scope of the appended claims.

[0189] Other notes and examples

[0190] The following examples relate to embodiments according to this specification. Example L1 provides an apparatus (e.g., including a first core including first computing circuitry) for biasing performance in a processor, a system (e.g., including a memory and a processor coupled to the memory, the processor including the first core), one or more machine-readable media, a method, and / or hardware-based, firmware-based, and / or software-based logic, wherein Example L1 includes a first core configured to: identify a first logical processor associated with a first thread of an application and a second logical processor associated with a second thread; obtain a first thread preference indicator and a second thread preference indicator respectively associated with the first thread and the second thread; calculate a first relative performance bias value for the first logical processor based at least in part on the relative relationship between the first thread preference indicator and the second thread preference indicator; and adjust the performance bias of the first logical processor based on the first relative performance bias value.

[0191] In Example L2, the subject of Example L1 may optionally include: wherein the relative relationship between the first thread preference indicator and the second thread preference indicator is used to calculate the scale value of the first thread preference indicator and the scale value of the second thread preference indicator, and wherein the first relative performance bias value corresponds to the scale value of the first thread preference indicator.

[0192] In Example L3, the subject matter of any of Examples L1-L2 may optionally include: wherein the core is further used to reduce the performance bias of the second logic processor based at least in part on a second performance preference that is lower than the first performance preference indicated by the first relative performance bias value calculated for the second logic processor.

[0193] In Example L4, the subject matter of any one of Examples L1-L3 may optionally include: wherein the core is further configured to increase the performance bias of the first logical processor based at least in part on a first performance preference that indicates a second performance preference that is higher than that indicated by a second relative performance bias calculated for the second logical processor.

[0194] In Example L5, the subject of Example L4 may optionally include: wherein increasing the performance bias of the first logical processor includes: allocating a first share of hardware resources to the first logical processor based on a first relative performance bias value, wherein the first share is greater than a second share of hardware resources allocated to the second logical processor.

[0195] In Example L6, the subject of Example L5 may optionally include: wherein the hardware resource is either a core-specific hardware resource or a shared hardware resource, the core-specific hardware resource can only be used by the first core, and the shared hardware resource can be used by the first core and one or more other cores of the processor.

[0196] In Example L7, the subject matter of any one of Examples L4-L6 may optionally include: wherein increasing the performance bias of the first logical processor includes: assigning a first number of execution cycles to the first logical processor and assigning a second number of execution cycles to the second logical processor, wherein the first number of execution cycles is more than the second number of execution cycles.

[0197] In Example L8, the subject matter of any of Examples L4-L7 may optionally include: wherein increasing the performance bias of the first logic processor includes: increasing the utilization of the pipeline components by the first logic processor for executing instructions of the first thread.

[0198] In Example L9, the subject of Example L8 may optionally include: wherein the pipeline component is selected from the group of pipeline components including: decoding unit, renaming unit, allocator unit, scheduler unit, execution unit, and memory access unit.

[0199] In Example L10, the subject matter of any one of Examples L1-L9 may optionally include: wherein the first core is further configured to: detect a change in a first thread preference indicator; calculate an updated first relative performance bias value for the first logical processor based at least in part on the relative relationship between the changed first thread preference indicator and a second thread preference indicator; and adjust the performance bias of the first logical processor based on the updated first relative performance bias value.

[0200] In Example L11, the subject of any one of Examples L1-L10 may optionally include: wherein the first thread preference indicator and the second thread preference indicator are obtained from a register filled with one of the following: operating system, user application, system application, hypervisor, virtual system application, virtual user application, or user.

[0201] In Example L12, the subject matter of any one of Examples L1-L11 may optionally include: a second core, including a third logical processor associated with a third thread, wherein a third thread preference indicator is associated with the third thread; and one or more instructions stored in memory, wherein, when executed by the processor, the processor: detects a new thread associated with a fourth thread preference indicator; and dispatches the new thread to an idle logical processor in the second core based at least in part on determining that the difference between the fourth thread preference indicator and the third thread preference indicator associated with the second core is greater than the difference between the fourth thread preference indicator and the first and second thread preference indicators associated with the first core.

[0202] In Example L13, the subject matter of any one of Examples L1-L12 may optionally include: wherein the processor including the first core is configured to: calculate a third relative performance bias value for the first core based at least in part on the relative relationship between a first thread preference indicator and a second thread preference indicator associated with the first core and a third thread preference indicator and a fourth thread preference indicator associated with the second core; and adjust the core performance bias of the first core based on the third relative performance bias value.

[0203] In Example L14, the subject of Example L13 may optionally include: wherein adjusting the core performance bias of the first core includes: allocating a third share of shared hardware resources to the first core based on a third relative performance bias value.

[0204] In Example L15, the subject of Example L14 may optionally include: wherein the first core is used to: allocate a subset of a third share of shared hardware resources to the first logical processor based on a first relative performance bias value.

[0205] In Example L16, the subject of any one of Examples L1-L15 may optionally include: wherein obtaining the first thread preference indicator and the second thread preference indicator is reading the first thread preference indicator and the second thread preference indicator.

[0206] The following examples relate to embodiments according to this specification. Example C1 provides an apparatus (e.g., a processor including a first core and a second core) for unlocking at least a portion of a device, a system (e.g., including a memory and a processor coupled to the memory, the processor including a first core and a second core), one or more machine-readable media, a method, and / or hardware-based, firmware-based, and / or software-based logic, wherein Example C1 includes: identifying a first logical processor in the first core associated with a first thread of an application; identifying a second logical processor in the second core associated with a second thread; obtaining a first thread preference indicator and a second thread preference indicator respectively associated with the first thread and the second thread; calculating a first relative performance bias value for the first core based at least in part on the relative relationship between the first thread preference indicator and the second thread preference indicator; and adjusting the performance bias of the first core based on the first relative performance bias value.

[0207] In Example C2, the subject of Example C1 may optionally include: wherein the relative relationship between the first thread preference indicator and the second thread preference indicator is used to calculate the scale value of the first thread preference indicator and the scale value of the second thread preference indicator, and wherein the first relative performance bias value corresponds to the scale value of the first thread preference indicator.

[0208] In Example C3, the subject matter of any of Examples C1-C2 may optionally include: reducing the performance bias of the second core based at least in part on a second performance bias of the second core, which is lower than the first performance bias of the first core indicated by the first relative performance bias value.

[0209] In Example C4, the subject matter of any of Examples C1-C3 may optionally include: increasing the performance bias of the first core based at least in part on the first performance preference of the first core, which indicates a second performance preference of the second core that is higher than that of the second core indicated by the second relative performance bias calculated for the second core.

[0210] In Example C5, the subject matter of Example C4 may optionally include: wherein increasing the performance bias of the first logic processor includes: allocating a first share of hardware resources to the first core based on a first relative performance bias value, wherein the first share is greater than a second share of hardware resources allocated to the second core.

[0211] In Example C6, the subject of Example C5 may optionally include: wherein the hardware resource is one of a shared hardware resource that can be used by at least the first core and the second core.

[0212] In Example C7, the subject of any one of Examples C1-C6 may optionally include: detecting a change in a first thread preference indicator; calculating an updated first relative performance bias value for a first core based at least in part on the relative relationship between the changed first thread preference indicator and a second thread preference indicator; and adjusting the performance bias of the first core based on the updated first relative performance bias value.

[0213] In example C8, the subject of any one of examples C1-C7 may optionally include: wherein the first thread preference indicator and the second thread preference indicator are obtained from a register filled with one of the following: operating system, user application, system application, hypervisor, virtual system application, virtual user application, or user.

[0214] In Example C9, the subject matter of any one of Examples C1-C8 may optionally include: a second processor, including a third core having a third logical processor running a third thread, wherein a third thread preference indicator is associated with the third thread; and one or more instructions stored in memory, wherein, when executed by at least one of the processors, the at least one of the processors causes the at least one of the processors to: detect a new thread associated with a fourth thread preference indicator; and dispatch the new thread to an idle logical processor in another core of the second processor based at least in part on determining that the difference between the fourth thread preference indicator and the third thread preference indicator is greater than the difference between the fourth thread preference indicator and the first thread preference indicator and the second thread preference indicator.

[0215] Example Y1 provides a device for dynamically biasing performance in a processor, wherein the device includes means for performing the method of any of the preceding examples.

[0216] In Example Y2, the subject matter of Example Y1 may optionally include: the means for performing the method includes at least one processor and at least one memory element.

[0217] In Example Y3, the subject matter of Example Y2 may optionally include: at least one memory element comprising machine-readable instructions that, when executed, cause the device to perform any of the methods in the preceding examples.

[0218] In Example Y4, the subject of any of Examples Y1-Y3 may optionally include: the device is a computing system, a processing element, or a system-on-a-chip.

[0219] Example Y5 provides at least one machine-readable storage medium including instructions for dynamically biasing performance in a processor, wherein, when executed, the instructions cause at least one processor to implement an apparatus as in any of the preceding examples, a system as in any of the preceding examples, or a method as in any of the preceding examples.

Claims

1. A system comprising: a memory; and a processor coupled to the memory, the processor including a first core to: identify a first logical processor associated with a first thread of an application and a second logical processor associated with a second thread; obtain a first thread preference indicator and a second thread preference indicator associated with the first thread and the second thread, respectively; calculate a first relative performance bias value for the first logical processor based at least in part on a relative relationship of the first thread preference indicator to the second thread preference indicator; and adjust a performance bias of the first logical processor based on the first relative performance bias value, wherein the first core is further to: increase the performance bias of the first logical processor based at least in part on the first relative performance bias value indicating a first performance preference that is higher than a second performance preference indicated by a second relative performance bias value calculated for the second logical processor. The relative relationship of the first thread preference indicator to the second thread preference indicator is to calculate a scaled value of the first thread preference indicator and a scaled value of the second thread preference indicator, wherein the first relative performance bias value corresponds to the scaled value of the first thread preference indicator. The first core is further to:

2. The system of claim 1, wherein, decrease a performance bias of the second logical processor based at least in part on the second relative performance bias value calculated for the second logical processor indicating a second performance preference that is lower than the first performance preference indicated by the first relative performance bias value.

3. The system of claim 1, wherein, Increasing the performance bias of the first logical processor includes: allocating a first share of a hardware resource to the first logical processor based on the first relative performance bias value, wherein the first share is greater than a second share of the hardware resource allocated to the second logical processor.

4. The system of claim 1, wherein, The hardware resource is one of a core-specific hardware resource that is usable only by the first core and a shared hardware resource that is usable by the first core and one or more other cores in the processor. Increasing the performance bias of the first logical processor includes:

5. The system of claim 4, wherein, allocating a first number of execution cycles to the first logical processor and a second number of execution cycles to the second logical processor, wherein the first number of execution cycles is greater than the second number of execution cycles.

6. The system of any one of claims 1-5, wherein, Increasing the performance bias of the first logical processor includes: increasing utilization of a pipeline component by the first logical processor for executing instructions of the first thread.

7. The system of any one of claims 1-5, wherein, The pipeline component is selected from a group of pipeline components including: a decode unit, a rename unit, an allocator unit, a scheduler unit, an execution unit, and a memory access unit. The first core is further to:

8. The system of claim 7, wherein, detect a change in the first thread preference indicator; 9. The system of any one of claims 1-5, wherein, calculate an updated first relative performance bias value for the first logical processor based at least in part on a relative relationship of the changed first thread preference indicator to the second thread preference indicator; and ​ ​ ​ adjusting a performance bias of the first logical processor based on the first relative performance bias value.

10. The system of any one of claims 1-5, wherein, The first thread preference indicator and the second thread preference indicator are obtained from a register populated by one of: an operating system, a user application, a system application, a hypervisor, a virtual system application, a virtual user application, or a user.

11. The system of any one of claims 1-5, wherein, The processor further includes: a second core including a third logical processor associated with a third thread, wherein a third thread preference indicator is associated with the third thread; and one or more instructions stored in the memory, wherein the one or more instructions, when executed by the processor, cause the processor to: detect a new thread associated with a fourth thread preference indicator; and dispatch the new thread to an idle logical processor in the second core based at least in part on determining that an amount of difference between the fourth thread preference indicator and the third thread preference indicator associated with the second core is greater than an amount of difference between the fourth thread preference indicator and the first thread preference indicator and the second thread preference indicator associated with the first core.

12. The system of any one of claims 1-5, wherein, The processor to: calculate a third relative performance bias value for the first core based at least in part on a relative relationship between the first thread preference indicator and the second thread preference indicator associated with the first core and a third thread preference indicator and a fourth thread preference indicator associated with a second core; and adjust a core performance bias of the first core based on the third relative performance bias value. Adjusting a core performance bias of the first core includes:

13. The system of claim 12, wherein, allocating a third share of a shared hardware resource to the first core based on the third relative performance bias value. The first core to:

14. The system of claim 13, wherein, allocate a subset of the third share of the shared hardware resource to the first logical processor based on the first relative performance bias value. Obtaining the first thread preference indicator and the second thread preference indicator is reading the first thread preference indicator and the second thread preference indicator.

15. The system of any one of claims 1-5, wherein, 16. An apparatus comprising: a first core including a first compute circuit to: identify a first logical processor associated with a first thread of an application and a second logical processor associated with a second thread; obtain a first thread preference indicator and a second thread preference indicator associated with the first thread and the second thread, respectively; calculate a first relative performance bias value for the first logical processor based at least in part on a relative relationship of the first thread preference indicator to the second thread preference indicator; and adjust a performance bias of the first logical processor based on the first relative performance bias value, wherein the first compute circuit is further to: increase the performance bias of the first logical processor based at least in part on the first relative performance bias value indicating a first performance preference higher than a second performance preference indicated by a second relative performance bias value calculated for the second logical processor. ​ 17. The apparatus of claim 16, wherein, A relative relationship of the first thread preference indicator to the second thread preference indicator is used to calculate a scaled value of the first thread preference indicator and a scaled value of the second thread preference indicator, wherein the first relative performance bias value corresponds to the scaled value of the first thread preference indicator.

18. The apparatus of claim 16, wherein, The first computing circuit is further to: decrease a performance bias of the second logical processor based at least in part on the second relative performance bias value calculated for the second logical processor indicating a second performance preference that is lower than the first performance preference indicated by the first relative performance bias value.

19. The apparatus of claim 16, wherein, Increasing the performance bias of the first logical processor includes: allocating a first share of hardware resources to the first logical processor based on the first relative performance bias value, wherein the first share is greater than a second share of the hardware resources allocated to the second logical processor.

20. The apparatus of claim 16, wherein, Increasing the performance bias of the first logical processor includes: allocating a first number of execution cycles to the first logical processor and a second number of execution cycles to the second logical processor, wherein the first number of execution cycles is greater than the second number of execution cycles.

21. The apparatus of claim 16, wherein, The first computing circuit is further to: detect a change in the first thread preference indicator; calculate an updated first relative performance bias value for the first logical processor based at least in part on a relative relationship of the changed first thread preference indicator to the second thread preference indicator; and adjust the performance bias of the first logical processor based on the updated first relative performance bias value.

22. A method comprising: identifying a first logical processor in a first core that is associated with a first thread of an application and a second logical processor that is associated with a second thread; obtaining a first thread preference indicator and a second thread preference indicator associated with the first thread and the second thread, respectively; calculating a first relative performance bias value for the first logical processor based at least in part on a relative relationship of the first thread preference indicator to the second thread preference indicator; and adjusting a performance bias of the first logical processor based on the first relative performance bias value, wherein the performance bias of the first logical processor is increased based at least in part on the first relative performance bias value indicating a first performance preference that is higher than a second performance preference indicated by a second relative performance bias value calculated for the second logical processor.

23. The method of claim 22, further comprising: detecting a change in the first thread preference indicator; calculating an updated first relative performance bias value for the first logical processor based at least in part on a relative relationship of the changed first thread preference indicator to the second thread preference indicator; and adjusting the performance bias of the first logical processor based on the updated first relative performance bias value.

24. The method of claim 22, further comprising: calculating a third relative performance bias value for the first core based at least in part on a relative relationship between the first thread preference indicator and the second thread preference indicator associated with the first core and a third thread preference indicator and a fourth thread preference indicator associated with a second core; and adjusting a core performance bias of the first core based on the third relative performance bias value.

25. The method of claim 22, further comprising: reducing a performance bias of the second logical processor based at least in part on the second relative performance bias value calculated for the second logical processor indicating a second performance preference that is less than the first performance preference indicated by the first relative performance bias value.

Images