Dynamic performance biasing in processors

Abstract

Dynamic performance biasing in a processor is disclosed. In embodiments, techniques for dynamically biasing the performance of logical processors within a processor core are provided. 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 respectively associated with the first thread and the second thread; calculating 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 adjusting the performance bias of the first logical processor based on the first relative performance bias value. The embodiment may further include: increasing the performance bias of the first logical processor based at least in part on a first performance preference indicating a higher second performance preference.

Description

[0001] This application is a divisional application of the application filed on August 30, 2018, with application number 201811003358.4, entitled "Dynamic Performance Bias in a Processor". Technical Field

[0002] This disclosure generally pertains to the field of computing architecture, and more specifically to dynamic performance biasing in processors. Background Technology

[0003] Simultaneous multithreading (SMT) is a processing technique employed by superscalar computer processing units (CPUs) with hardware multithreading. SMT allows multiple threads to run concurrently on the same physical core of the CPU's logical processors. Instructions are fetched from multiple threads in each execution cycle. This is achieved by sharing different pipeline resources of the core. Instructions fetched from multiple threads can be executed or disposed of by any pipeline stage during the same cycle. Generally, the sharing of hardware resources is unbiased, and therefore, such resources are shared equally among concurrently executing threads. Similarly, execution cycles are typically divided equally among all logical processors on the SMT core. As computer architectures evolve, continuous efforts are made to further improve the efficiency and optimize the performance of processing elements. Brief description of the attached diagram

[0004] To provide a more complete understanding of this disclosure and its features and advantages, reference is made to the description herein in conjunction with the accompanying drawings, in which like reference numerals denote like parts, wherein: Figure 1 This is a simplified block diagram of a computing system for dynamic performance biasing of a logic processor according to certain embodiments; Figure 2 This is a simplified flowchart of potential operations associated with the dynamic performance bias of a logic processor according to certain embodiments; Figure 3 This is a simplified flowchart of further potential operations associated with the dynamic performance bias of a logic processor according to certain embodiments; Figure 4 It is a block diagram depicting an example of dynamic performance bias of a logic processor according to certain embodiments; Figure 5 This is a simplified flowchart of further potential operations associated with the dynamic performance bias of a logic processor according to certain embodiments; Figure 6 This is a simplified flowchart of further potential operations associated with scheduling threads using the dynamic performance bias of the logic processor; Figures 7A-7B It is a block diagram depicting an example of scheduling threads using the dynamic performance bias of a logic processor; Figure 8 This is a simplified block diagram of another example computing system for dynamic performance biasing of the core, according to certain embodiments; Figure 9 It is a simplified flowchart of potential operations associated with dynamic performance biases of core and logic processors according to certain embodiments; Figure 10 This is a simplified flowchart of further potential operations associated with the dynamic performance bias of the core and logic processor according to certain embodiments; Figure 11 This is a simplified flowchart of further potential operations associated with the dynamic performance bias of the core and logic processor according to certain embodiments; Figure 12 This is a simplified flowchart of further potential operations associated with scheduling threads using the dynamic performance bias of the kernel; Figures 13A-13B It is a block diagram depicting an example of scheduling threads using the dynamic performance bias of the kernel; Figure 14 This is a simplified block diagram of an embodiment of a virtualized computing system for dynamic performance biasing of cores and / or logic processors, according to certain embodiments. Figure 15 This is a block diagram of a register architecture according to certain embodiments; Figure 16A This is a block diagram illustrating an exemplary ordered pipeline and an exemplary register renaming, out-of-order release / execution pipeline according to certain embodiments; Figure 16B This is a block diagram illustrating both an exemplary embodiment of an ordered architecture core to be included in a processor according to certain embodiments and an exemplary register renaming, out-of-order release / execution architecture core; Figures 17A-17B The diagram illustrates a block diagram of a more specific exemplary ordered core architecture according to certain embodiments, wherein the core will be one of several logical blocks in a chip (including other cores of the same type and / or different types); Figure 18 It is a block diagram of a processor that may have more than one core, may have an integrated memory controller, and may have an integrated graphics device, according to certain embodiments; Figures 19-22 These are block diagrams of exemplary computer architectures according to certain embodiments; and 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 certain embodiments. Detailed Implementation

[0005] The following disclosure provides various possible embodiments or examples for implementing the features disclosed in this specification. These features relate to a computing system for dynamic performance biasing based on thread characteristics. Dynamic performance biasing can be implemented using both hardware and software. Hints can be provided to the computing system hardware by actors, indicating performance preferences for specific threads or logical processors associated with those threads. Such actors may include, but are not limited to, operating systems, system applications, user applications, and / or settings changed by the user. Hints can be provided in the form of specific settings programmed for threads or thread preference indicators. Thread preference indicators can be used to calculate a relative performance bias value for each logical processor, each logical processor being 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 calculated performance bias values.

[0006] In other embodiments, other types of performance bias values ​​may be computed during processing, and these other types of performance bias values ​​may be used to dynamically bias other types of components during processing. For example, in a multi-core processor architecture, a core-relative performance bias may be computed based on a thread preference indicator, and this core-relative performance bias may be used to dynamically allocate resources shared between cores. In at least some embodiments, a multi-core processor may be configured for dynamic core performance biases for resources shared between cores and dynamic logical processor performance biases for resources shared between the logical processors of a core simultaneously. In a further embodiment, in a multi-socket architecture, a processor performance bias value may be computed based on a thread preference indicator and potentially based on a core performance bias value. The processor performance bias value may be used to dynamically allocate resources shared between processors. In at least some embodiments, a multi-core processor may be configured to simultaneously execute dynamic processor performance biases for resources shared between processors and dynamic core performance biases for resources shared between processor cores and / or dynamic logical processor performance biases for resources shared between the logical processors of a core.

[0007] To illustrate certain example techniques for computing systems using dynamic logic processor performance bias 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 bias" is also referred to herein as "performance bias," as it is understood that any such bias is performed dynamically.

[0008] 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.

[0009] However, at least one new technology, namely Intel provided by Intel Corporation, ® 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.

[0010] Currently, resources within the SMT core are shared unbiasedly among all logical processors. Generally, each logical processor receives an equal share of core resources and an equal share of the portion of shared resources allocated to the core. Without software assistance, the hardware allocates resources to each logical processor based on hardware control flow, resulting in equitable resource allocation. For example, the hardware does not impose any preferences on logical processors in different pipeline stages. Furthermore, 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 the different logical processors running on the same core. Execution cycles are also equally divided among all logical processors on the core. Moreover, pipeline components operate at the same speed, which is dynamically increased or decreased as needed, but not adjusted based on the performance preferences of specific threads. Such components include, but are not limited to, decoder units, renaming units, allocator units, scheduler units, execution units, and / or memory access units. Additionally, in some microarchitectures, thread scheduling in the core pipeline is divided among the threads of the core. Hardware scheduling attempts to allocate the same amount of computing resources to all threads of the hardware core.

[0011] Turn Figure 1An embodiment of computing system 100 configured for logic processor (LP) performance bias can address the aforementioned (and more) problems associated with computing systems having one or more concurrently multithreaded cores. Example computing system 100 may include one or more system applications (e.g., 120), one or more user applications (e.g., 130), and operating system 140, any one or all of which may be stored in memory 188. The system and user applications may include thread preference selectors (e.g., 122, 132, 142) and thread schedulers (e.g., 124, 134, 144). Thread preference indicators 150 may be stored in any suitable storage or memory, such as hardware registers, and may be retrieved by processor 170. Processor 170 cores such as core A 160A and core B 160B may each include logical processor (LP) computing circuitry (e.g., 162A, 162B) and multiple logical processors (e.g., 164A(1), 164A(2), 164B(1), 164B(2)) with corresponding threads (e.g., 165A(1), 165A(2), 165B(1), 165B(2)). Core-specific hardware resources such as core A resource 190A and core B resource 190B may include, for example, core-specific caches (e.g., 192A, 192B). Shared hardware resources 180 may be shared between cores and may include a shared cache 182, a bus interface 184, and memory 186. In at least one embodiment, memory 188 is a portion of memory 186, and memory 188 may be the main memory of computing system 100 (e.g., random access memory (RAM)). Storage (e.g., hard disks, solid-state drives, etc.) available in computing system 100 for storing data and code is not included. Figure 1 As shown in the diagram, other shared hardware resources that can bias application performance may include, but are not limited to, internal registers, access ports, out-of-order microarchitectural features, etc.

[0012] Embodiments of computing system 100 can leverage differences in thread preference information across different logical processors within the same SMT core (e.g., 160A, 160B) and enhance resource sharing across logical processors within the core based on thread performance preferences (also referred to herein as "thread preferences"). In one example, the thread preference information of logical processors within the SMT core may be based on Intel... ® Speed-Moving Energy Performance Preference (EPP) settings. However, it should be understood that any suitable technology, whether currently available or subsequently developed, capable of providing thread preference information for each logical processor (e.g., in the form of thread preference indicators) can be utilized by the hardware to efficiently manage resources among logical processors within the SMT core and to deliver performance to the relevant applications that require the most performance.

[0013] In one embodiment, the core reads a corresponding 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, operating system, system application, or 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 appropriately stored, for example, in a hardware register. The thread preference indicator can be based on the thread characteristics (e.g., priority, importance, utilization, etc.) of the threads running on the logical processor and the importance of the logical processor to the associated application. Additionally, the application's own priority or importance can be considered when programming the thread preference indicator. The core merges the thread preference indicators assigned to its logical processors and calculates a relative performance bias value for each logical processor based on the relative relationships of the thread preference indicators. These relative performance bias values ​​represent the proportion of performance bias required by each logical processor. The hardware adjusts the performance bias for each logical processor based on its relative performance bias value. More specifically, the hardware can dynamically adjust the use of core hardware resources, shared hardware resources, execution cycles, and the speed (i.e., utilization) of different components in the pipeline stage for each logic processor.

[0014] Computing systems such as Computing System 100, which perform performance biasing across logical processors within a single core, can offer several advantages. Hardware can leverage differences in thread preference information to efficiently manage resources among logical processors within an SMT core and enhance the performance of associated applications that require the most performance. By using thread preference information for each logical processor, hardware can speculatively bias the performance of logical processors within an SMT core. For example, a logical processor running a thread with a higher performance preference (e.g., a download or upload in a file transfer application) can be given a larger share of hardware resources, execution cycles, and / or component speed compared to another logical processor running a thread with a lower performance preference (e.g., a low-priority thread such as a download or upload in the background of a user interaction application) as indicated by a thread preference indicator. Conversely, a logical processor running a thread with a lower performance preference (e.g., a low-priority or less important thread) as indicated by a thread preference indicator can be given a smaller share of hardware resources, execution cycles, and / or component speed compared to another logical processor that runs a thread with a higher performance preference (e.g., a high-priority or more important thread) as indicated by a thread preference indicator.

[0015] In at least one embodiment, the 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 thread preference indicators associated with other logical processors within the same core. This approach can result in better responsiveness and application experience.

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

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

[0018] In at least some embodiments, the thread preferences of an application may be selected and set by a single software component, such as system application 120, user application 130, operating system 140, or by a user of the application. However, in other embodiments, thread preferences may be selected and set by multiple software components, such as user application 130 and operating system 140. In these embodiments, some coordination may 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., the corresponding LP computing circuitry 162A or 162B of cores 160A and 160B) or software (e.g., thread preference selector 142 of operating system 140) may be invoked to determine which thread preference indicator will be applied to the associated logical processor.

[0019] The software components of computing system 100 may also include a thread scheduler (e.g., 124, 134, 144) that maximizes the utilization of thread preferences by intelligently assigning threads to logical processors of a core, such that the assignment creates a difference in thread preferences associated with that core. For example, a thread may be assigned to a core in which it will have the highest performance preference relative to other threads running on that core. This ensures that logical processors associated with higher performance preferences receive a larger share of the resources, execution cycles, and component utilization of the SMT cores compared to using the same number of SMT cores across logical processors without any difference in performance.

[0020] In at least some embodiments, application threads can be intelligently dispatched to 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 threads to logical processors.

[0021] In one example implementation for creating differences in thread preference indicators associated with logical processors within a core, bits (e.g., via CPU ID bits) can be set to allow applications to discover this exploit capability. Applications with a thread scheduler can maintain a track of thread preference indicators for all logical processors in the system's cores. When a new thread or job is scheduled to be placed on a logical processor, the thread scheduler can determine which cores contain logical processors with thread preference indicators that differ from the new thread or job. If multiple cores have logical processors associated with different thread preference indicators, the new thread can be scheduled on the core that produces the largest difference in thread preference indicators and / or gives the new thread the highest performance preference relative to other threads running on that core.

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

[0023] In at least one embodiment, the cores (e.g., cores A and B) may include hardware such as LP computing circuitry (e.g., 162A or 162B) that performs one or more operations to calculate a relative performance bias value for each logical processor in the core, and adjusts the resources, execution cycles, and / or component speeds allocated to each logical processor based on the corresponding calculated performance bias value, as needed. Thus, the hardware in the core can bias the performance of the logical processors within the core based on a thread preference indicator. To implement this performance bias, the LP computing circuitry (e.g., 162A or 162B) in the core may be configured to acquire a thread preference indicator 150 associated with a thread assigned to a logical processor in the core. The LP 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 logical processor relative performance bias (LP-RPB) value for each logical processor.

[0024] For a logical processor within the core, the LP-RPB value can be calculated based on the thread preference indicator of that logical processor relative to other thread preference indicators of other logical processors within the core. For a specific logical processor, an example calculation might include: LP-RPB value = maximum (thread preference indicator in the core) / (sum of minimum allocation value for (thread preference indicator in the core)). Based on the calculated LP-RPB value, the LP calculation circuitry or other hardware within the core can then dynamically adjust the hardware resource usage, number of execution cycles, and / or the speed of different components in the pipeline stage for each logical processor within the core, based on its corresponding LP-RPB value. The LP calculation circuitry can be further configured to monitor changes in thread preference indicators and logical processor changes (e.g., becoming idle, becoming active) and dynamically update resource allocation, number of execution cycles, and component speeds in the pipeline stage.

[0025] In the embodiments described herein, hardware resource usage can be dynamically adjusted by hardware (e.g., 162A, 162B). For example, hardware resources can be allocated or distributed based on the performance preferences of logical processors within the same core. In one example, hardware resources can be distributed proportionally among logical processors based on a calculated LP-RPB value. Hardware resources can include core-specific resources and shared hardware resources 180, such as core A resource 190A and core B resource 190B. Specific 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 a single core of logical processors. For example, the share of cache 192A can be dynamically adjusted and allocated to logical processors 164A(1) and 164A(2), and the share of cache 192B can be dynamically adjusted and allocated to logical processors 164B(1) and 164B(2). Shared hardware resources 180 can be allocated across multiple cores to logical processors. For example, a corresponding share 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 logic processors 164A(1) and 164A(2) based on the corresponding LP performance bias values ​​of logic processors 164A(1) and 164A(2). The share of memory allocated to core B can be used to dynamically allocate a subset of that share to logic processors 164B(1) and 164B(2) based on the corresponding LP performance bias values ​​of logic processors 164B(1) and 164B(2).

[0026] In the embodiments described herein, the number of execution cycles of the logic processors can be dynamically adjusted by hardware (e.g., 162A, 162B) based on thread preferences. An execution cycle is a period of time during which an instruction in a thread is fetched from memory and executed. In one example, execution cycles can be proportionally allocated among the logic processors based on a calculated LP-RPB value. For example, the hardware can dynamically allocate more execution cycles to logic processors on a core with higher performance preferences compared to logic processors with lower performance preferences. Conversely, the hardware can dynamically allocate fewer execution cycles to logic processors on a core with lower performance preferences compared to logic processors with higher performance preferences.

[0027] In the embodiments described herein, hardware (e.g., 162A, 162B) can provide more preference to a logic processor with a higher performance preference in different pipeline stages compared to 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, for their purposes, certain components that can be adjusted based on thread preference. Increasing the utilization of a component can improve its speed, and conversely, reducing its utilization can decrease its speed. Specifically, the hardware can provide additional boost (e.g., utilization) to components of a pipeline stage that is executing or processing a logic processor with a higher performance preference compared to other logic processors on the same core. (See reference...) Figures 16A-16B The pipeline stages and components are shown and discussed in more detail in this article.

[0028] The embodiments described herein can be implemented using any suitable method to achieve the desired performance bias among logical processors in a core. In one example, the shares of hardware resources and execution cycles can be distributed proportionally among the logical processors of a core based on a calculated LP-RPB value. The LP-RPB value can be calculated in various ways based on the relative relationships of thread preference indicators across logical processors in a core. As used herein, the term "relative relationship" for thread preference indicators is intended to refer to the relationship, connection, or dependency between thread preference indicators. Accordingly, when calculating the LP-RPB value for a logical processor, the calculation is based on the thread preference indicator of the thread being considered, estimated, sorted, compared, etc., relative to other thread preference indicators of other threads in the core. For example, for an LP-RPB value calculated based on thread preference indicators with significantly different performance preference levels (e.g., 10 and 255), the shares of hardware resources and execution cycles can be allocated among the logical processors 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, for three logical processors with different thread preference indicators in a core, hardware resources and execution cycles can be allocated among these logical processors according to a predetermined percentage (e.g., 60%-30%-10%), which corresponds to the logical processors sorted according to the thread preference indicator (e.g., from highest to lowest performance preference). In another example, for three logical processors with different performance preferences, hardware resources and execution cycles can be allocated among these logical processors according to a predetermined percentage (e.g., 60%-20%-20% or 40%-40%-20%), which provides a larger increase bias only to the logical processor associated with the thread preference indicator indicating the highest performance preference (e.g., thread preference indicator 0), and / or provides a larger decrease bias only to the logical processor associated with the thread preference indicator indicating the lowest performance preference (e.g., thread preference indicator 255).

[0029] Figure 2 This is a simplified flowchart of possible operations that can be associated with an embodiment of logical processor performance bias in computing system 100. For ease of illustration, logical processor performance bias is described in three stages, and Figure 2 Represents stage A1. In at least one embodiment, a set of operations corresponds to Figure 2The activities. An SMT core (e.g., core A 160A, core B 160B) or a portion thereof may utilize this set of operations. An SMT core may include means such as hardware for performing these operations. In one example, depending on the core to which the logical processor to which the thread is assigned, at least some of the operations shown in process 200 may be performed by LP computing circuitry 162A or 162B. For ease of reference, this document will assume, to further describe, that the threads of the application are to be assigned to logical processors 164A(1) and 164A(2) of core A160A. Figure 2 .

[0030] Phase A1 identifies whether the application uses thread preference indicators and whether the application, operating system, or user has programmed different thread preference indicators for threads to run on the logical processor in the SMT core (e.g., core A160A). At 202, the threads of the application to run on the core (e.g., core A160A) are detected. At 204, a determination can be made as to whether simultaneous multithreading is enabled on the core. If SMT is not enabled, the process ends. If SMT is enabled on the core, at 206, a determination is made as to whether thread preference indicators are enabled 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 can set the thread preference indicator bit.

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

[0032] At 212, compare the thread preference indicators of the identified logical processors. At 214, determine whether all thread preference indicators belonging to the same core have the same value. If all thread preference indicators belonging to the same core have the same value, then at 216, allocate and divide resources among the identified logical processors according to the system's normal policy. The process is then passed to... Figure 5Phase A3, as described in [the document], monitors changes to the thread preference indicator and the logical processor of the core. If a determination is made at 214 that there are at least one different value between the thread preference indicators of threads belonging to the same core, the flow is passed to [the next step]. Figure 3 Stage A2 as described in the text.

[0033] Figure 3 This is a simplified flowchart of possible operations that can be associated with an embodiment of the performance bias of the logic processor in computing system 100. Figure 3 Phase A2 represents the performance bias of the logic processor. In at least one embodiment, a set of operations corresponds to... Figure 3 The activities. An SMT core (e.g., core A 160A, core B 160B) or a portion thereof may utilize this set of operations. An SMT core may include means such as hardware for performing these operations. In one example, depending on the core to which the logical processor to which the thread is assigned, at least some of the operations shown in process 300 may be performed by LP computing circuitry 162A or 162B. For ease of reference, this document will assume that the threads of the application are assigned to logical processors 164A(1) and 164A(2) of core A 160A for further description. Figure 3 .

[0034] In stage A2, at point 302, a relative performance bias value for a logical processor (LP) is calculated based on the relative relationships of thread preference indicators for logical processors across SMT cores (e.g., core A 160A). Specifically, the LP relative performance bias (LP-RPB) value for a logical processor within a core can be calculated based on the relative relationships between the thread preference indicators of threads assigned to a logical processor and the thread preference indicators of threads assigned to other logical processors within the same core. The relativity can be calculated based on the values ​​of the thread preference indicators. In one example, the relative relationships of the thread preference indicators are used to calculate a scale value for the thread preference indicators based on their performance preference levels. For example, as previously described herein, if a thread preference indicator has a value in the range of 0-255, the scale value can vary based on a specific level of performance preference. Therefore, for example, thread preference indicators 10, 200, and 250 can have scales different from those of thread preference indicators 10, 50, and 225. In at least one implementation, the LP-RPB value can be calculated based on this scale (e.g., as a percentage).

[0035] In another implementation, the relative relationships of thread preference indicators can be used to determine the order of logical processors in a core based on performance preferences (e.g., highest to lowest), indicated by the thread preference indicators of the threads assigned to those logical processors. In this implementation, the LP-RPB value can be based on a predetermined proportion of the ordered logical processors. For example, the three logical processors in core A can be ordered based on thread preference indicators 0, 100, and 200 of the threads assigned to the three logical processors in core A. The three logical processors in core B can be ordered based on thread preference indicators 25, 50, and 255 of the threads assigned to the three logical processors in core B. In each of these scenarios, the LP-RPB value 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 value of the thread preference indicator associated with each core.

[0036] In yet another example, the relative relationships of thread preference indicators can be used to distinguish thread preference indicators representing the highest performance preference of a logical processor in the core. For example, LP-RPB values ​​calculated for logical processors in the core can be equal, except for the LP-RPB value of the logical processor associated with the highest performance preference indicated by the thread preference indicator. 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 with 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 with 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 understood that the relative relationships of thread preference indicators can also (or alternatively) be used to distinguish thread preference indicators representing the lowest performance preference of a logical processor in the core.

[0037] While some examples have been described above, generally, 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. Furthermore, in some embodiments, a single LP-RPB value can be calculated to achieve performance biases for resources, execution cycles, and component speeds within the logical processor. However, in other embodiments, a unique LP-RPB value can be calculated to apply to each (or any combination thereof) of hardware resources, execution cycles, and component speeds within the logical processor. Moreover, it should be understood that LP-RPB values ​​do not necessarily have to 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.

[0038] While the associated threads are running, operations 304-312 can be performed on demand for each logical processor in the 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 the core has a higher relative performance bias, it is given a larger share of the core pipeline, including higher utilization of the pipeline components handling 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 that core.

[0039] At 304, a logic processor (e.g., logic processor 1 164A(1)) and its computed LP-RPB are identified. A logic processor can be identified as needed and as required to dynamically adjust its performance bias based on the hardware resources to be allocated (e.g., requested hardware resources), the execution cycles to be partitioned among the logic processors (e.g., scheduled new threads), and / or the startup of pipeline components used to dispose of that logic processor. If necessary, the performance bias of the identified logic processor can be adjusted (e.g., increased or decreased) based on the LP-RPB value computed for the logic processor.

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

[0041] At 308, the number of execution cycles for the identified logical processor is determined based on the 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 compared to all other logical processors in the same core (e.g., logical processor 2 164A(2)), a larger number of execution cycles are 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 (e.g., logical processor 2 164A(2)), a smaller number of execution cycles are 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 logical processors in the same core. In this scenario, the number of execution cycles allocated to the identified logical processor can be higher than the number of execution cycles allocated to a logical processor with a lower performance preference in the same core, but lower than the number of execution cycles allocated to a logical processor with a higher performance preference in the same core.

[0042] At 310, the speed of one or more components executing or otherwise disposing of the identified logical processor may be dynamically changed 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 compared to all other logical processors in the same core (e.g., logical processor 2 164A(2)), the utilization of the pipeline components disposing of that logical processor may be dynamically increased, and thus the speed of that component may be increased. 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 (e.g., logical processor 2 164A(2)), the utilization of the pipeline components disposing of that logical processor may be dynamically decreased, and thus the speed of that component may be decreased. Finally, the identified logical processor may have an LP-RPB value indicating a preference higher than that of one or more logical processors in the same core but lower than that of one or more other processors in the same core. In this scenario, the utilization of the pipeline components that handle the logic processor can be dynamically changed so that it is higher than the utilization of logic processors with lower performance preferences in the same core, and lower than the utilization of logic processors with higher performance preferences in the same core.

[0043] When hardware resources, execution cycles, and / or component speeds have been dynamically adjusted for logical processors within the same core, the process can proceed as follows: Figure 5 The stage A3 described in the text.

[0044] Figure 4 This is a block diagram depicting an example scenario of performance bias of a logic processor according to embodiments of the present disclosure. Figure 4 The diagram illustrates how pipeline sharing can be biased to ensure performance is biased toward logic processors that request more performance in the SMT core. Figure 4 The example in the example involves logic processor 1 (LP 1) and logic processor 2 (LP 2). Input condition 402 is based on thread preference indicators for LP 1 and LP 2, which indicate a higher performance preference for LP 1 compared to LP 2. In this example, the higher performance preference for LP 1 is indicated by the fact that the value of the thread preference indicator for LP 1 is less than the value of the thread preference indicator for LP 2.

[0045] At 404, a relative performance bias value is calculated for the logical processor based on the associated thread preference indicator. In this example, the relative performance bias value of LP1 is determined to be greater than that of LP2. These relative performance bias values ​​indicate that LP1 will receive a higher share of hardware resources, execution cycles, and pipeline component utilization compared to LP2. Accordingly, when instruction 1 of LP1 at 410, instruction 2 of LP1 at 408, and instruction 1 of LP2 at 406 are fetched at 412, the performance biases of LP1 and LP2 are adjusted based on their relative performance bias values. The performance bias of LP1 can be increased by providing LP1 with more hardware resources, execution cycles, and / or component utilization than LP2. The performance bias of LP2 can be decreased by providing LP2 with fewer hardware resources, execution cycles, and / or component utilization than LP1. This performance bias of the logic processor is based on the input from stage A2 shown at 404.

[0046] Figure 5 This is a simplified flowchart of possible operations that can be associated with an embodiment of the performance bias of the logic processor in computing system 100. Figure 5 Phase A3 represents the relative performance bias of LP. In at least one embodiment, a set of operations corresponds to Figure 5 The activities. An SMT core (e.g., core A 160A, core B 160B) or a portion thereof may utilize this set of operations. An SMT core may include means such as hardware for performing these operations. In one example, depending on the core to which the logical processor to which the thread is assigned, at least some of the operations shown in process 500 may be performed by LP computing circuitry 162A or 162B. For ease of reference, it will be assumed herein that the application's thread will be assigned to logical processors 164A(1) and 164A(2) of core A 160A for further description. Figure 5 .

[0047] In phase A3, the logical processors and thread preference indicators in the core are monitored to dynamically update hardware resource allocation, execution cycle allocation, and pipeline component utilization based on changes in the thread preference indicators associated with the logical processors on the core and / or changes in the logical processors on the core (e.g., becoming idle / active). At 502, changes in the thread preference indicators and the logical processors in the core are monitored.

[0048] At position 504, a change in the thread preference indicator or a logical processor within the core is detected. In one scenario, a change in the thread preference indicator can be detected when any (or more) of the thread preference indicators of the threads currently running in the logical processor of the core has increased or decreased since the LP relative performance bias value was last calculated (e.g., at position 302). In another scenario, if there was initially no difference in the thread preference indicator, a change in the thread preference indicator can be detected at position 504 when any (or more) of the thread preference indicators of the threads currently running in the logical processor of the core has increased or decreased since the thread level indicator was read (e.g., at position 210).

[0049] If a thread running in a logical processor finishes execution and that logical processor becomes idle, the change can also be detected in that logical processor within the core. In another example, a change in a logical processor can be detected if a new thread of the application is assigned to a previously idle logical processor within the core. If it is determined that there has been a change in at least one thread preference indicator or at least one logical processor, all logical processors in the core are identified at 506. At 508, the thread preference indicator of the thread associated with each logical processor in the core is retrieved. The process then proceeds back to stage A2 to recalculate the LP relative performance bias value and to adjust resource allocation, number of execution cycles, and / or pipeline component speed for the logical processor based on the new LP-RPB value.

[0050] Turn Figure 6 , Figure 6 This is a simplified flowchart of possible operations that can be associated with embodiments of performance bias in the logic processor of computing system 100. In at least one embodiment, a set of operations corresponds to Figure 6 The activities. In at least one embodiment, a software component (e.g., operating system 140, system application 120, user application 130, etc.) or portions thereof may utilize the set of operations. The software component may include means for performing these operations, such as processor 170. In one example, depending on the specific software component configured to utilize the set of operations, at least some of the operations shown in process 600 may be executed by a thread scheduler (e.g., 124, 134, or 144).

[0051] At 602, thread preference indicators of threads running in logical processors (e.g., logical processors 164A(1), 164A(2), 164B(1), and 164B(2)) across all cores of the processor are tracked. At 604, a new thread of the application to be scheduled on a logical processor is detected. At 606, the thread preference indicator of the new thread is compared with the thread preference indicators of existing threads already scheduled in multiple cores of the processor. At 608, a determination is made based on this comparison to determine whether a difference exists on at least one core. If the thread preference indicator of the new thread differs from at least one thread preference indicator of another thread already scheduled in a logical processor of a core, a difference exists in the core. If no difference exists on any core, at 610 the new thread can be assigned to any core according to the existing scheduling policy, and the process then ends.

[0052] If a difference exists on at least one core, determining the largest difference at 612 can be used to identify the optimal core for the new thread. A core with a larger difference than all other cores to which the new thread will have a difference exists. In another embodiment, the optimal core is the core in which the highest logical processor performance bias value for the new thread can be calculated based on the currently active logical processor in the core. In yet another embodiment, the optimal core is the core in which the new thread will have the highest performance preference (e.g., lowest thread preference indicator) relative to other cores. At 614, the new thread is scheduled on the identified optimal core.

[0053] Figures 7A-7B This is a block diagram depicting an example scenario of maximizing the utilization of logical processor 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 most performance bias (e.g., the highest proportion of resources), and 255 represents the lowest thread performance preference and thus seeks the least performance bias (e.g., the lowest proportion of resources).

[0054] Figure 7AExample cores A and B are shown, each with two logical processors: LP1 and LP2 on core A and LP3 and LP4 on core B. Thread 1 is running on LP1 and has a thread preference indicator of 10, while LP2 is idle. Thread 2 is running on LP3 and has a thread preference indicator of 255, while LP4 is idle. At 702, a new thread 3 has a thread preference indicator of 10 and will be assigned to either the idle logical processor LP2 on core A or the idle logical processor LP4 on core B. If the new thread 3 is assigned to LP2, there will be no difference in core A. 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 LP4 on core B, there will be a difference in core B because thread 2 has a thread preference indicator of 255 and the new thread 3 has a thread preference indicator of 10.

[0055] Figure 7B This shows a new thread 3 assigned to LP 4 on core B. Based on the relative relationship between the thread preference indicator values ​​10 and 255, a relative performance bias value for LPs 3 and 4 can be calculated. Accordingly, LP 4 receives a higher proportion of core B's resources and also gains performance improvements (e.g., higher utilization of pipeline components) compared to LP 3. A larger number of execution cycles can also be assigned to LP 4 compared to LP 3.

[0056] Turn Figure 8The block diagram illustrates an embodiment of a computing system 800 configured to dynamically relative perform performance bias for cores in a multi-core system. At least one embodiment can be implemented using cores that support simultaneous multithreading (also referred to herein as "SMT-enabled"). At least one other embodiment can be implemented using cores that do not support simultaneous multithreading (also referred to herein as "SMT-disabled"). In computing system 800, dynamic LP performance bias is extended to control core-level optimization based on thread preference indicators. As previously described herein, thread preference indicators can be used to compute core relative performance bias values ​​in a similar manner. However, core relative performance bias values ​​can be used in a multi-core processor to bias shared hardware resources, including non-core resources, across the cores of that multi-core processor. Shared hardware resources can 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 pipelines or other components are shared across cores, core relative performance bias values ​​can be used to bias execution cycles and / or component speeds across cores. Core performance biasing based on thread preference indicators enables dynamic control over the amount of resources used by a core, providing applications with more power savings or performance as needed and when required.

[0057] In this example embodiment, computing system 800 may 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 one or all of which may be stored in memory 888. The system and user applications may include thread preference selectors (e.g., 822, 832, 842) and thread schedulers (e.g., 824, 834, 844). Thread preference indicators 850 may be stored in any suitable storage or memory, such as hardware registers, and may be retrieved by processor 870. Processor 870 may include core computing circuitry 872 and multiple cores such as core A860A, core B860B, core C860C, and core D860D. In a multi-core system that does not support SMT, each core may include a single logical processor with associated threads at any given time. Figure 8For 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 and D may each have core-specific resources (e.g., core A resource 890A, core B resource 890B, core C resource 890C, and core D resource 890D). Shared hardware resources are allocated across cores and may include, for example, a shared cache 882, a bus interface 884, and memory 886. In at least one embodiment, memory 888 is part of memory 886, and memory 888 may be the main memory of computing system 800 (e.g., random access memory (RAM)). Storage (e.g., hard disks, solid-state drives, etc.) available for storing data and code in computing system 800 is not included. Figure 8 As shown in the diagram. Other shared hardware resources (to which performance bias may apply) may include, but are not limited to, internal registers, access ports, out-of-order microarchitectural features, etc.

[0058] For SMT-enabled systems, in at least some embodiments, each core may include features such as those described in reference 1. Figures 1-5 The described LP computing circuit utilizes thread preference information between different logical processors in the same SMT-enabled core (in Figure 1 (as shown in the figure). However, in embodiments that include core relative performance bias, the allocation of shared hardware resources among logical processors in the same SMT-enabled core is calculated based on the LP relative performance bias value of the logical processor and the amount of shared hardware resources allocated to the core.

[0059] Implementations of computing systems 800 (both SMT-enabled and SMT-disabled) can leverage thread preference information across different cores in the same processor (e.g., 870) based on thread performance preferences and enhance resource sharing by biasing resources among cores. In SMT-enabled implementations, after biasing resources to one core more than one or more other cores, as referenced herein... Figures 1-5As described, LP performance biasing can be performed in each core where differences in thread preference indicators associated with logical processors within the core occur. In this scenario, LP performance biasing is performed within the core based on a new amount of resources allocated to that core as a result of core performance biasing. For each logical processor, any suitable technique, whether currently available or subsequently developed, capable of providing thread preference information (e.g., in the form of thread preference indicator 850) can be utilized by hardware to efficiently manage resources between processor cores (e.g., non-SMT-enabled and SMT-enabled). This technique can also be utilized by hardware to efficiently manage resources between logical processors within SMT-enabled cores and to deliver performance to the associated applications that require the most performance.

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

[0061] Computing systems such as the Computing System 800, designed for cross-core performance biasing, can offer several advantages. In systems containing cores with non-SMT enabled, the hardware can leverage differences in thread preference information across cores to efficiently manage resources. By using the thread preference information of each logical processor, the hardware can speculatively bias the performance of cores in a non-SMT-enabled system. For example, a core with a logical processor running threads with higher performance preferences (e.g., high-priority or more important threads) as indicated by the thread preference indicator can be given a larger share of shared hardware resources compared to another core with a logical processor running threads with lower performance preferences (e.g., low-priority or less important threads) as indicated by the thread preference indicator. Conversely, a non-SMT-enabled core can be given a smaller share of shared hardware resources compared to another core with a logical processor running a thread with a lower performance preference (e.g., a low-priority or less important thread) as indicated by the thread preference indicator of that thread.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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, each core AD may have two (or more) logical processors, and each logical processor may run a thread with a thread preference indicator.

[0066] 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 the logical processor assigned to the core. The core computing circuitry can acquire the thread preference indicator by reading, receiving, being provided with the thread preference indicator, or otherwise obtaining 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.

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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, suppose 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 provides a larger decreasing bias only to the core associated with the thread preference indicator indicating the lowest performance preference.

[0072] 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.

[0073] 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.

[0074] 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.

[0075] If the thread preference indicator is decisively enabled at 906 (e.g., the thread preference indicator bit is set), then all logical processors (e.g., 864A(1)-864A(4)) across all cores are identified at 908. 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.

[0076] 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.

[0077] 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.

[0078] 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 value of the thread preference indicator. 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 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 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.

[0079] 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.

[0080] 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 the 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.

[0081] 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.

[0082] 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.

[0083] 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.

[0084] 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.

[0085] In a system with SMT enabled, the logical processor of the core identified at 1016 (e.g., 860A-860D) can execute as described in the reference. 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, the 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.

[0086] 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.

[0087] 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 partitioned 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.

[0088] In steps 306-310, the performance bias of the identified logical processor is adjusted. At step 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.

[0089] 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.

[0090] 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.

[0091] 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.

[0092] 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 in thread preference indicators associated with logical processors within the core and / or changes in 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.

[0093] 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.

[0094] 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 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 adjust hardware resource (e.g., core-specific and / or shared hardware resources) allocation, execution cycle allocation, and pipeline component utilization.

[0095] 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).

[0096] 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 is no difference on any processor (e.g., all thread preference indicators on all processors are the same as the thread preference indicator of 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.

[0097] 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.

[0098] 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).

[0099] 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.

[0100] 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.

[0101] 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 SMT (Surface Mount Technology) enabled. 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.

[0102] 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.

[0103] 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.

[0104] 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.

[0105] 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.

[0106] 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).

[0107] 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.

[0108] 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 herein. Figures 15-23The configuration shown in the figure.

[0109] The embodiments of the instructions(s) described in detail above can be implemented using 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. Additionally, 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.

[0110] 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 specific content to be present in the operand field for selecting specific operands. 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, the Intel® 64 and IA-32 Architecture Software Developer's Manual, September 2014; and the Intel® Advanced Vector Extensions Programming Reference, October 2014).

[0111] 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.

[0112] 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.

[0113] 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.

[0114] 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.

[0115] 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.

[0116] 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.

[0117] 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.

[0118] 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.

[0119] 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.

[0120] 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.

[0121] 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.

[0122] Execution engine unit 1650 includes a rename / 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 reordering 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.

[0123] The scheduler unit 1656, physical register file unit 1658, and execution cluster 1660 are shown as potentially 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, physical register file unit, and / or execution cluster—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.

[0124] 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.

[0125] 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.

[0126] 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.

[0127] It should be understood that the core can support multithreading (SMT) (execution of two or more parallel operations or a set of threads), and can accomplish this multithreading in various ways, including time-division multithreading, simultaneous multithreading (where a single physical core provides a logical core for each thread in the threads that the physical core is simultaneously multithreading), or combinations thereof (e.g., time-division fetching and decoding and subsequent simultaneous multithreading such as Intel® Hyper-Threading Technology).

[0128] 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.

[0129] Figures 17A-17B The diagram illustrates a more specific example of an 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.

[0130] 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).

[0131] 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.

[0132] Figure 17B According to 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.

[0133] 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.

[0134] 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).

[0135] 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 levels of cache, 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.

[0136] 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.

[0137] In embodiments that provide logical processor performance bias or core performance bias, other hardware and / or software may 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 may acquire thread preference indicators (e.g., 150, 850, 1450). The PCU may 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.

[0138] 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.

[0139] Figure 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 including 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.

[0140] 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.

[0141] 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.

[0142] 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.

[0143] 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.

[0144] 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.

[0145] 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(s) receive and execute the received coprocessor instructions.

[0146] 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.

[0147] 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 can 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.

[0148] 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.

[0149] 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.

[0150] 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.

[0151] 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.

[0152] 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.

[0153] 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.

[0154] 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.

[0155] 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.

[0156] Program code (such as, Figure 20 The code 2030 shown in the diagram 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.

[0157] 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.

[0158] 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.

[0159] 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.

[0160] 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.

[0161] 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.

[0162] 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.

[0163] 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 features 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 component 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 component 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.

[0164] 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 potentially applicable to countless other architectures, nor should they inhibit the broad teachings of this system.

[0165] 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.

[0166] 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 (multiple embodiments) 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.

[0167] 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.

[0168] 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.

[0169] Other notes and examples

[0170] 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.

[0171] 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.

[0172] 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.

[0173] 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.

[0174] 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.

[0175] 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.

[0176] 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.

[0177] 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.

[0178] 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.

[0179] 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.

[0180] 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.

[0181] 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.

[0182] 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.

[0183] 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.

[0184] 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.

[0185] 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.

[0186] 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.

[0187] 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.

[0188] 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.

[0189] 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.

[0190] 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.

[0191] 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.

[0192] 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.

[0193] 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.

[0194] 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.

[0195] 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.

[0196] 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.

[0197] 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.

[0198] 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.

[0199] 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: Memory; as well as A processor, coupled to the memory, the processor including a first core, the first core being used for: Identify the first logical processor associated with the first thread of the application and the second logical processor associated with the second thread; Obtain the first thread preference indicator and the second thread preference indicator associated with the first thread and the second thread, respectively; The first relative performance bias value is calculated 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; as well as The performance bias of the first logic processor is adjusted based on the first relative performance bias value. The first core is further used for: The performance bias of the first logic processor is increased at least in part based on a first performance preference that indicates a second performance preference indicated by a second relative performance bias value calculated for the second logic processor.

2. The system as claimed in claim 1, wherein, The relative relationship between the first thread preference indicator and the second thread preference indicator is used to calculate the ratio value of the first thread preference indicator and the ratio value of the second thread preference indicator, wherein the first relative performance bias value corresponds to the ratio value of the first thread preference indicator.

3. The system as described in claim 1, wherein, The first core is further used for: The performance bias of the second logic processor is reduced, at least in part, based on a second relative performance bias value calculated for the second logic processor indicating a second performance preference that is lower than the first performance preference indicated by the first relative performance bias value.

4. The system as claimed in claim 1, wherein, Increasing the performance bias of the first logic processor includes: A first share of hardware resources is allocated to the first logic 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 logic processor.

5. An apparatus, the apparatus comprising: The first core includes a first computing circuit, the first computing circuit being used for: Identify the first logical processor associated with the first thread of the application and the second logical processor associated with the second thread; Obtain the first thread preference indicator and the second thread preference indicator associated with the first thread and the second thread, respectively; The first relative performance bias value is calculated 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; as well as The performance bias of the first logic processor is adjusted based on the first relative performance bias value. The first computing circuit is further used for: The performance bias of the first logic processor is increased at least in part based on a first performance preference that indicates a second performance preference indicated by a second relative performance bias value calculated for the second logic processor.

6. The apparatus of claim 5, wherein, Increasing the performance bias of the first logic processor includes: A first number of execution cycles are assigned to the first logical processor, and a second number of execution cycles are assigned to the second logical processor, wherein the first number of execution cycles is greater than the second number of execution cycles.

7. The apparatus of claim 5, wherein, The first computing circuit is further used for: Detect changes in the first thread preference indicator; The updated first relative performance bias value for the first logical processor is calculated at least in part based on the relative relationship between the changed first thread preference indicator and the second thread preference indicator; as well as The performance bias of the first logic processor is adjusted based on the updated first relative performance bias value.

8. A method, the method comprising: Identify the first logical processor in the first core that is associated with the first thread of the application and the second logical processor that is associated with the second thread; Obtain the first thread preference indicator and the second thread preference indicator associated with the first thread and the second thread, respectively; The first relative performance bias value is calculated 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; as well as The performance bias of the first logic processor is adjusted based on the first relative performance bias value, wherein the performance bias of the first logic processor is increased at least in part based on a first performance preference that indicates a second performance preference indicated by a second relative performance bias value calculated for the second logic processor.

9. The method of claim 8, further comprising: Detect changes in the first thread preference indicator; The updated first relative performance bias value for the first logical processor is calculated at least in part based on the relative relationship between the changed first thread preference indicator and the second thread preference indicator; as well as The performance bias of the first logic processor is adjusted based on the updated first relative performance bias value.

10. The method of claim 8, further comprising: The third relative performance bias value for the first core is calculated at least in part based on the relative relationship between the first thread preference indicator and the second thread preference indicator associated with the first core and the third thread preference indicator and the fourth thread preference indicator associated with the second core. as well as The core performance bias of the first core is adjusted based on the third relative performance bias value.

Images