Patent Description:
A data processing system may include a central processing unit (CPU) with multiple cores, and each core may include multiple logical processors (LPs) to provide for simultaneous multithreading (SMT). The data processing system may execute software as threads on the CPU, and each LP may execute a thread concurrently with other threads running on other LPs. In particular, an operating system (OS) may assign each thread to a particular LP. Also, the group of LPs which share a core may be referred to as siblings.

The CPU may also be capable of executing at different frequencies at different times, with more power being needed as the frequency increases. In particular, each acceptable frequency may be paired with a corresponding voltage requirement. Each different voltage-frequency pairing that a CPU supports may be referred to as a "performance state" or "P-state. " However, a conventional CPU may be designed to utilize a monolithic P-state model. Under the monolithic P-state model, the CPU always uses the same P-state for all of the cores. In other words, the current P-state sets the speed and voltage for all of the cores in the CPU. Thus, for such a CPU, the P-state is per CPU. By contrast, some current development efforts are directed towards a type of CPU that allows different cores in the CPU to use different P-states at the same. For instance, a power management unit in the CPU may be capable of setting each core to a different P-state. Thus, this type of CPU supports per-core P-state (PCPS).

Sonic conventional CPUs include additional technologies to enhance efficiency, such as those technologies provided by Intel Corporation under names or trademarks such as "Hardware-Controlled Performance States" (HWP), "Hardware Duty Cycling" (HDC), etc. Also, the CPU may allow the OS to specify a perfonnance/efficiency preference for each thread. In other words, the CPU may support software-specified per-thread efficiency/performance preferences.

Nevertheless, at least in some circumstances, it may be desirable to achieve levels of performance and efficiency that exceed those provided by conventional data processing system. For instance, it may be desirable to increase the number of hours of battery life that can be provided by battery-powered data processing systems.

As described in greater detail below, the present disclosure introduces technology to enable a CPU to achieve desirable levels of both performance and efficiency.

<CIT> provides embodiments having technology to dynamically bias performance of logical processors in a core of a processor. One embodiment includes identifying a first logical processor associated with a first thread of an application and a second logical processor associated with a second thread, obtaining first and second thread preference indicators associated with the first and second threads, respectively, computing a first relative performance bias value for the first logical processor based, at least in part, on a relativeness 0f the first and second thread preference indicators, and adjusting a performance bias of the first logical processor based on the first relative performance bias value. Embodiments can further include increasing the performance bias of the first logical processor based, at least in part, on the first relative performance bias value indicating a first performance preference that is higher than a second performance preference.

<CIT> describes a multi-core processor that supports simultaneous multithreading, the power state for each logical processor is tracked. Upon indication that a logical processor is ready to transition into a deep low power state, software remapping (e.g., thread-hopping) may be performed. Accordingly, if multiple logical processors, on different cores, are in a low-power state, they are re-mapped to same core and the core is then placed into a low power state.

The invention is set forth in the independent claims. Embodiments of the invention are described in the dependent claims.

According to an embodiment the data processing system further comprises an EPP register for each LP of each core, wherein the OS, when executed, enables the data processing system to perform further operations comprising: after automatically assigning the new low-priority thread to the idle LP in the second core, (a) assigning a new high-priority thread to an idle LP in the first core, (b) setting the EPP register for the idle LP in the first core with a value to indicate a preference for performance, and (c) running the first core at a high power state.

According to an embodiment, when the select core comprises the first core, the OS, when executed, enables the data processing system to perform further operations comprising: after automatically assigning the new low-priority thread to the idle LP in the first core, (a) assigning a new high-priority thread to an idle LP in the second core, (b) setting the EPP register for the idle LP in the second core with a value to indicate a preference for performance, and (c) running the second core at a high-power state.

According to an embodiment, when the select core comprises the first core, the OS, when executed, enables the data processing system to perform further operations comprising: after automatically assigning the new low-priority thread to one of the LPs in the select core, running the select core at a low-power state.

According to an embodiment, the data processing system, further comprises an EPP register for each LP of each core, wherein the OS, when executed, enables the data processing system to perform further operations comprising: when multiple high-priority threads are executing on the first core, in response to the second core entering idle, (a) transferring one of the high-priority threads from the first core to the LP in the second core that entered idle and (b) setting the EPP register for that LP with a value to indicate a preference for performance.

According to an example not forming part of the literal wording of the claims granted, an apparatus with technology for dynamically grouping threads is provided. The apparatus comprises a non-transitory machine-readable medium, and instructions in the machine-readable medium which, when executed by a data processing system with a processor comprising multiple cores and multiple LPs per core, enable the data processing system to perform operations comprising (a) selecting one of the LPs in the processor to receive a new low-priority thread: and (b) assigning the new low-priority thread to the selected LP. Also, the operation of selecting one of the LPs in the processor to receive the new low-priority thread comprises (<NUM>) when a first core in the processor has multiple idle LPs, automatically determining whether a second core in the processor has (a) an idle LP and (b) a busy LP that is executing a current low-priority thread; and (<NUM>) in response to determining that the second core has (a) an idle LP and (b) a busy LP that is executing a current low-priority thread, automatically selecting the idle LP in the second core to receive the new low-priority thread. According to an example, the instructions, when executed, enable the data processing system to perform further operations comprising: after automatically assigning the new low-priority thread to the idle LP in the second core, (a) assigning a new high-priority thread to an idle LP in the first core, (b) setting an EPP register for the idle LP in the first core with a value to indicate a preference for performance, and (c) running the first core at a high power state. According to an example, the instructions, when executed, enable the data processing system to perform further operations comprising (a) after automatically selecting the idle LP in the second core to receive the new low-priority thread, automatically setting an EPP register for the idle LP in the second core with a value to indicate a preference for energy efficiency; and (b) after setting the EPP register for the idle LP in the second core with a value to indicate a preference for energy efficiency, running the second core at a low power state.

According to an example, the operation of selecting one of the LPs in the processor to receive the new low-priority thread further comprises: (<NUM>) when none of the cores in the processor has all of its LPs idle, automatically determining whether any of the cores has (a) an idle LP and (b) a busy LP that is executing a current low-priority thread; (<NUM>) in response to determining that a select core has (a) an idle LP and (b) a busy LP that is executing a current low-priority thread, automatically (i) assigning the new low-priority thread to the idle LP in the select core and (ii) setting an EPP register for the idle LP in the select core with a value to indicate a preference for energy efficiency; and (<NUM>) after automatically assigning the new low-priority thread to the idle LP in the select core, running the select core at a low-power state.

According to an example, when the select core comprises the first core, the instructions, when executed, enable the data processing system to perform further operations comprising: after automatically assigning the new low-priority thread to the idle LP in the first core, (a) assigning a new high-priority thread to an idle LP in the second core, (b) setting the EPP register for the idle LP in the second core with a value to indicate a preference for performance, and (c) running the second core at a high-power state.

According to an example, the operation of selecting one of the LPs in the processor to receive the new low-priority thread further comprises: (<NUM>) when none of the LPs is idle, automatically determining whether any of the cores has all of its LPs executing low-priority threads; and (<NUM>) in response to determining that a select core has all of its LPs executing low-priority threads, automatically assigning the new low-priority thread to one of the LPs in the select core. According to an example, the instructions, when executed, enable the data processing system to perform further operations comprising: after automatically assigning the new low-priority thread to one of the LPs in the select core, running the select core at a low-power state. According to an example, the instructions, when executed, enable the data processing system to perform further operations comprising: when multiple high-priority threads are executing on the first core, in response to the second core entering idle, (a) transferring one of the high-priority threads from the first core to the LP in the second core that entered idle and (b) setting an EPP register for that LP with a value to indicate a preference for performance.

Features and advantages of the present invention will become apparent from the appended claims, the following detailed description of one or more example embodiments, and the corresponding figures, in which:.

When the OS in a data processing system specifies a high-performance hint for one LP in a core and a high-efficiency hint for anther LP in that core, the CPU may give preference to the high-performance hint and, in effect, disregard the high-efficiency hint, by setting the core to a relatively high P-state, in response to the high-perfomance hint. In other words, a high-performance software request/hint on an LP overrides a high-efficiency request/hint on its SMT sibling. Consequently, the data processing system may lose the opportunity to run background work efficiently, which may significantly impact battery life Thus, a CPU may be unable to achieve optimum efficiency when software specifies different efficiency/performance preferences for different LPs on the same core.

As indicated above, the present disclosure introduces technology to enable a CPU to achieve desirable levels of both performance and efficiency. In particular, the present disclosure introduces technology for dynamically grouping threads for energy efficiency. For instance, as described in greater detail below, an OS in a data processing system may assign threads to LPs in a way that reduces or eliminates the likelihood that a core will have a high-performance thread on one LP and a high-efficiency thread on another LP. Consequently, the data processing system may operate with more energy efficiency than a conventional data processing system. For purposes of this disclosure, "assigning" a thread to an LP means to start the thread running on that LP. Typically, threads are assigned to LPs by a scheduler in the OS. Accordingly, "assigning" a thread to an LP may also be referred to as "scheduling" a thread on an LP or "dispatching" a thread to an LP.

As described in greater detail below, the present disclosure describes technology for grouping threads in ways that improve the energy efficiency and/or the performance of a data processing system, relative to conventional data processing systems.

<FIG> is a block diagram depicting an example embodiment of a data processing system <NUM> with technology for dynamically grouping threads for energy efficiency. Data processing system <NUM> is a hypothetical system, with various hypothetical components and features to illustrate the technology introduced herein.

In the embodiment of <FIG>, data processing system <NUM> includes a CPU or processor <NUM>, along with other components such as random access memory (RAM) <NUM>, nonvolatile storage (NVS) <NUM>, a network interface controller (NIC) <NUM>, etc. A processor may be implemented as an integrated circuit or "chip" that is mounted to a substrate to form a package. Alternatively, a processor may be implemented as a package that contains more than one chip.

In the embodiment of <FIG>, processor <NUM> includes two cores <NUM> and <NUM>, as well as other modules, such as a power management unit (PMU) <NUM>. PMU <NUM> may also be referred to as a power control unit. In addition, each core provides for two logical processors (LPs). Specifically, core <NUM> includes LP <NUM> and LP <NUM>, and core <NUM> includes LP <NUM> and LP <NUM>. However, in other embodiments, a processor may include more cores, and more LPs per core. For instance, a processor may include tens or hundreds of cores, and each of those cores may include one or more LPs. Accordingly, even though each core in <FIG> includes only two LPs, the present teachings apply as well to cores with three or more LPs. Consequently, instead of referring to "both" of the LPs in a core, this disclosure may refer more generally to "all" of the LPs in a core, or vice versa. Also, as indicated above, when a core includes multiple LPs, those LPs may be referred to as siblings.

NVS <NUM> includes software such as an OS <NUM>, one or more user applications <NUM>, etc. Data processing system <NUM> may copy the software into RAM <NUM> for execution on one or more of the LPs. In particular, data processing system <NUM> may execute the software as threads on processor <NUM>, and each LP may execute a thread concurrently with other threads running on other LPs.

In processor <NUM>, PMU <NUM> is capable of setting each core to a different P-state. In other words, processor <NUM> supports per-core P-state,.

As described in greater detail below, in the embodiment of <FIG>, PMU <NUM> includes various data storage structures to contain power management settings pertaining to the various cores, LPs, and such within processor <NUM>. For purposes of this disclosure, such data storage structures may be referred to as registers. In one embodiment, such registers are implemented as "special-purpose registers" (SPRs). An SPR may also be referred to as a "model-specific register" (MSR).

As described in greater detail below, one type of power management setting may be referred to as an "efficiency/perfomance preference (EPP) setting. " In the embodiment of <FIG>, PMU <NUM> provide one EPP register for each LP. OS <NUM> may use EPP registers <NUM>, <NUM>, <NUM>, and <NUM> to provide a different EPP setting for each different thread being executed. In particular, OS <NUM> may use the EPP setting for an LP to provide an indication to the processor as to whether the thread for that LP should be executed in a manner to prefer energy efficiency or in a manner to prefer performance. For instance, OS <NUM> may provide an EPP setting to indicate a workload category (e.g., real time, foreground, high priority, high performance, background, low priority, high efficiency, etc.).

In one embodiment, such EPP settings may follow the guidelines set forth for "energy/performance preference control" in documents such as the "Intel® <NUM> and IA-<NUM>.

<NPL> (the "SDM"). For instance, as indicated on pages <NUM>-<NUM> and <NUM>-<NUM> of the SEM, an OS may write an EPP setting or value to bites <NUM>:<NUM> of an SPR referred to as the "IA32_HWP_REQUEST Register," with the value <NUM> indicating that maximum performance is preferred, and 0FFFxH indicating that maximum energy efficiency is preferred. However, for purposes of illustration, the present disclosure describes a hypothetical scenario in which processor <NUM> supports EPP settings of <NUM>-<NUM>, with <NUM> indicating that maximum performance is preferred, and <NUM> indicating that maximum energy efficiency is preferred. EPP settings may also be referred to as "software hints. " PMU <NUM> may automatically select the P-state for the cores based at least in part on those hints. For instance, for each core, PMU <NUM> may select the P-state based on the EPP settings and the current workload for that core, and then PMU control flows will apply that P-state to the core.

Also, for purposes of this disclosure, the term "high priority" may be used in general to refer to an EPP setting that is on the high-performance half of the spectrum (<NUM>-<NUM>), and the term "low priority" may be used in general to refer to an EPP setting that is on the high-efficiency half of the spectrum (<NUM>-<NUM>). Similarly, the term "high power state" may be used to refer to a P-state that is on the high-performance half of the spectrum or supported P-states, and the term "low power state" may be used to refer to a P-state that is on the low-performance (or high-efficiency) half of the spectrum or supported Pestates,.

<FIG> uses dashed lines to indicate which power management settings pertain to which components. For instance, the dashed lines surrounding EPP register <NUM> indicate that the EPP setting in that register pertains to LP <NUM>.

In addition, PMU <NUM> includes a low-priority-core-set (LPCS) register <NUM> for power management settings which pertain to multiple cores. LPCS register <NUM> may also be referred to as a "hardware efficiency coreset MSR. " In the embodiment of <FIG>, LPCS register <NUM> includes an entry <NUM> for each core in processor <NUM>, to indicate which cores are not running any high-priority threads. How data processing system <NUM> uses LPCS register <NUM> is described in greater detail below.

Thus, EPP registers <NUM>, <NUM>, <NUM>, and <NUM> contain per-LP power management settings, and LPCS register <NUM> contains globally-applicable power management settings. However, in other embodiments, a processor may use any suitable number of registers to store power management settings (e.g., all settings may be stored in a single register). Accordingly, for purposes of this disclosure, the term "register" may be used to refer to a portion of a register, related portions of multiple registers, etc. Also, in other embodiments, a data processing system may include multiple sockets to accommodate multiple processors Each of those processors may include features like those described above with regard to processor <NUM>.

Since processor <NUM> supports per-core P-state, PMU <NUM> may be able to save power (relative to a processor that must use the same P-state for all cores) by running one or more cores at a relatively low P-state, while running one or more other cores at a relatively high P-state. In addition, it may be possible to increase the frequency of a subset of the cores by using the power headroom saved on another subset of the cores.

As indicated above, the present disclosure describes technology for grouping threads in ways that improve energy efficiency by reducing or eliminating the likelihood that a core will have a high-priority thread on one LP and a low-priority thread on another LP. For instance, OS <NUM> may maintain lists which indicate which LPs and which cores are not ranning high-priority threads, and OS <NUM> may consult those lists before assigning a new thread to an LP. In particular, if an LP is idle or if it is running a low-priority thread, that LP may be referred to as a "low-priority LP" or a "background LP. " Similarly, if all of the LPs in a core are either idle or running low-priority threads, that core may be referred to as a "low-priority core" or a "background core.

OS <NUM> includes a low-priority-LP list <NUM> to identify the low-priority LPs, and a low-priority-core list <NUM> to identify the low-priority cores. The list of low-priority LPs may also be referred to as the "low-priority LP set," the "background LP set," or the "Low-Priority-LP-List. " Similarly, the list of low-priority cores may also be referred to as the "low-priority core set," the "background core set," or the "Low-Priority-Core-List. " In the embodiment of <FIG>, low-priority-LP list <NUM> includes an LP entry <NUM> for each LP in processor <NUM>, and OS <NUM> sets or clears each of those entries to indicate whether or not the corresponding LP is a low-priority LP. Similarly, low-priority-core list <NUM> includes a core entry <NUM> for each core in processor <NUM>, and OS <NUM> sets or clears each of those entries to indicate whether or not the corresponding core is a low-priority core.

Moreover, as described in greater detail below, OS <NUM> may use those lists to assign threads to LPs in ways that enable processor <NUM> to operate efficiently. For instance, OS <NUM> may use those lists to determine which threads and LPs are low priority and which are high priority, as well as which cores are low priority and which are high priority.

<FIG> presents a flowchart of an example embodiment of a process for managing energy efficiency settings for cores and LPs. The process of <FIG> may start with data processing system <NUM> booting to OS <NUM>. Upon boot up, OS <NUM> may clear all entries <NUM> and <NUM> in low-priority-LP list <NUM> and low-priority-core list <NUM>, respectively, as shown at block <NUM>. OS <NUM> may then start assigning threads to LPs for execution and removing threads from LPs when those threads are idle, preempting threads, etc. For purposes of this disclosure, actions such as assigning a thread to an LP for execution and removing a thread from an LP when the thread is idle or finished may be referred to as "context switches.

In particular, as shown at block <NUM>, OS <NUM> may determine whether a context switch should be performed. If that determination is negative, processor <NUM> may simply continue to execute any active threads, as shown at block <NUM>. However, if that determination is positive, OS <NUM> may also determine whether the context switch is for a new thread entering execution, as shown at block <NUM>. If the context switch is for a new thread entering execution, OS <NUM> may assign that thread to an LP, as shown at block <NUM>. The LP selected to receive the new thread may be referred to as the "target LP. " Also, the core that contains the target LP may be referred to as the "target core. " Furthermore, some of the control logic for determining which target LP is to receive that thread is described in greater detail below with regard to <FIG>.

Also, OS <NUM> may determine whether the new thread is to run with low-priority, as shown at block <NUM>. For instance, if OS <NUM> is scheduling a thread to perform background processing, OS <NUM> may determine that the new thread should run with low priority, and accordingly, OS <NUM> may set the EPP register for the target LP with a low-priority setting. In response to a determination that the new thread is to run with low-priority, OS <NUM> may set the entry for the target LP in low-priority-LP list <NUM>, as shown at block <NUM> with the expression "Low-Priority-LP-List(LP) = <NUM>".

Also, as shown at block <NUM>, OS <NUM> may determine whether all of the sibling LPs in the target core are also low-priority LPs. If the sibling LPs are also low-priority LPs, OS <NUM> may also set the entry in low-priority-core list <NUM> for the target core, as shown at block <NUM> with the expression "Low-Priority-Core-List(LP-Core) = <NUM>".

However, referring again to block <NUM>, if the new thread does not have low priority (i.e., if the thread has high priority), OS <NUM> may clear the entry for the target LP in low-priority-LP list <NUM>, as shown at block <NUM>. OS <NUM> may also clear the entry for the target core in low-priority-core list <NUM>, as shown at block <NUM>. The process may then return to block <NUM>, with processor <NUM> continuing to run the current threads until the next context switch.

Also, referring again to block <NUM>, if a new thread is not entering, the context switch is for an old thread that is exiting. Accordingly, as shown at block <NUM>, OS <NUM> may terminate that old thread, thereby making the LP for that thread idle. For purposes of this disclosure, the LP for a thread that is being terminated may be referred to as the "target LP," and the core that contains the target LP may be referred to as the "target core.

Also, as shown at block <NUM>, OS <NUM> may determine whether the terminated thread had high priority. And if it did, OS <NUM> may set the entry for that LP in low-priority-LP list <NUM>, as shown at block <NUM>. Accordingly, an entry that is set in low-priority-LP list <NUM> indicates that the corresponding LP is a low-priority LP.

Also, as shown at block <NUM>, OS <NUM> may determine whether the sibling LPs are also low-priority LPs. If they are, OS <NUM> may set the entry for the target core in low-priority-core list <NUM>, as shown at block <NUM>. Thus, whenever the last high-priority thread on a core terminates, OS <NUM> marks that core as a low-priority core The process may then return to block <NUM>, with processor <NUM> continuing to run the current threads until the next context switch. Thus, OS <NUM> keeps track of which LPs and which cores are low-priority.

<FIG> present a flowchart of an example embodiment of a process for dynamically grouping threads for energy efficiency. In particular, <FIG> provide more details for the operation at block <NUM> of <FIG> for selecting a target LP to receive a new thread. As shown at block <NUM>, the process of <FIG> may start with OS <NUM> determining whether any of the LPs in processor <NUM> are idle. If no LPs are idle, the process may pass through page connector B to <FIG>.

If an LP is idle, OS <NUM> may take different branches depending on whether the new thread is a low-priority thread or a high-priority thread, as shown at block <NUM>. If the new thread is a high-priority thread, OS <NUM> may determine whether any core has all of its LPs idle, as shown at block <NUM>. If any core is fully idle, the process may pass through connector A, and OS <NUM><NUM> may select an idle LP on a fully idle core, as shown at block <NUM>. If no idle core is available, OS <NUM> may determine whether any of the cores with an idle LP is also running a high-priority thread on another LP, as shown at block <NUM>. If any core has an idle LP and a high priority LP, OS <NUM> may select that core (which may be referred to as a "high-priority core"), as shown at block <NUM>. Also, OS <NUM> may assign the new thread to the idle LP on that selected core, as shown at block <NUM>. Thus, OS <NUM> may group high-priority threads together on a core, thereby enable processor <NUM> to manage efficiency and performance more effectively than if the core were to include mixed LPs (i.e., one or more high-priority LPs along with one or more low-priority LPs). The process may then end.

However, referring again to block <NUM>, if all of the cores with idle LPs have only low-priority LPs, OS <NUM> may select one of those cores (which may be referred to as a "low-priority core"), as shown at block <NUM>. Also, OS <NUM> may assign the new thread to the idle LP on that selected core, as shown at block <NUM>, and the process may then end. Also, as indicated above with regard to blocks <NUM> and <NUM> of <FIG>, OS <NUM> may clear the entries for the target LP and the target core in low-priority-LP list <NUM> and low-priority-core list <NUM>.

However, referring again to block <NUM> if <FIG>, if the new thread is a low-priority thread, OS <NUM> may determine whether any of the low-priority cores with an idle LP is running a low-priority thread, as shown at block <NUM> If there is a low-priority core with an idle LP and another LP running a low-priority thread, OS <NUM> may select that core, as shown at block <NUM>.

If there is no low-priority core with (a) an idle LP and (b) another LP running a low-priority thread, OS <NUM> may determine whether any core has all of its LPs idle, as shown at block <NUM>. If any core has all of its LPs idle, OS <NUM> may select the fully idle core, as shown at block <NUM>. However, if no core is fully idle, OS <NUM> may select a high-priority core, as shown at block <NUM>. As shown at block <NUM>, OS <NUM> may assign the new thread to the idle LP on the selected core.

Alternatively, if (a) there is no low-priority core with (i) an idle LP and (ii) another LP running a low-priority thread, and (b) there is no fully idle core, then OS <NUM> may (a) look for a low-priority LP on a low-priority core to preempt, in case the new low-priority thread has higher priority than the existing low-priority thread, or (b) wait until a low-priority LP becomes available to schedule the new low-priority thread.

<FIG> is a block diagram depicting three different stages of a process for assigning threads to LPs when more than one core has an idle LP. Those stages correspond to parts of the process depicted in <FIG>. In particular, as shown in <FIG> at a first stage <NUM>, core <NUM> is running a low-priority thread A on LP <NUM>, while LPs <NUM>, <NUM>, and <NUM> are idle. Also, at stage <NUM>, OS <NUM> has a new low-priority thread B to assign to an LP, with the new thread depicted as an oval.

Using the process of <FIG>, at blocks <NUM> and <NUM>, OS <NUM> selects LP <NUM> as the target LP, since core <NUM> has an idle LP and its sibling LP is a running a low-priority thread. The low priority of LP <NUM> is reflected in the EPP setting of <NUM> in EPP register <NUM>. It will also be reflected in the corresponding entry in low-priority-LP list <NUM>.

Consequently, as shown at stage <NUM>, OS <NUM> has assigned low-priority thread B to LP <NUM>. Also, OS <NUM> is preparing to assign new high-priority thread C to an LP. For purposes of this disclosure, dotted fill may be used to denote high priority. If processor <NUM> would have a core with an idle LP and a high-priority LP, OS <NUM> would assign high-priority thread C to that idle LP, as per block <NUM> of <FIG>. However, in the scenario of <FIG>, at stage <NUM>, processor <NUM> has no such core. Consequently, at blocks <NUM> and <NUM> of <FIG>, OS <NUM> selects low-priority core <NUM> as the target core, and OS <NUM> assigns high-priority thread C to LP <NUM> in core <NUM>, as shown at stage <NUM> of <FIG> The high priority of LP <NUM> is reflected in the EPP setting of <NUM> in EPP register <NUM> (and the dotted fill for LP <NUM> in stage <NUM>). Consequently, processor <NUM> may now optimize efficiency for core <NUM>, while optimizing performance for core <NUM>.

By contrast, in a conventional data processing system, when assigning a thread like low-priority thread B, the OS would select an LP on a fully idle core, rather than selecting an LP on a core that is not fully idle Consequently, when subsequently assigning a high-priority thread in a scenario like that of <FIG>, the only available idle threads would be on cores that are already running low-priority threads. And once the OS assigns the high-priority thread to one of those LPs, it would be difficult, impossible, or counterproductive for the processor to optimize one core for efficiency and the other for performance. For instance, if a core has one low-priority LP and one high-priority LP, the effectiveness of the EPP request for low-priority thread will likely be reduced (due to the processor giving preference to the numerically lower of the two sibling EPP settings). Furthermore, the foreground thread performance of the high priority LP may be reduced, due to a reduced energy budget (relative to the energy budget in a scenario like stage <NUM> of <FIG>).

<FIG> is a block diagram depicting two different stages of a process for assigning threads to LPs when different cores with idle LPs also have threads with different EPP settings. Those stages also correspond to parts of the process depicted in <FIG>. In particular, as shown in <FIG> at a first stage <NUM>, core <NUM> is running a high-priority thread A on LP <NUM>, and core <NUM> is running a low-priority thread B on LP <NUM>, while LPs <NUM> and <NUM> are idle. Also, at stage <NUM>, OS <NUM> has a new low-priority thread C to assign to an LP.

Using the process of <FIG>, at blocks <NUM> and <NUM>, OS <NUM> selects LP <NUM> as the target LP, since core <NUM> has an idle LP and its sibling LP is a running a low-priority thread. Accordingly, as show at stage <NUM> of <FIG>, core <NUM> has only low-priority LPs, and core <NUM> has a high-priority LP and an idle LP. Consequently, processor <NUM> may configure core <NUM> with settings (e.g., P-state) suitable for high performance, and processor <NUM> may configure core <NUM> with settings suitable for high efficiency.

By contrast, in a conventional data processing system, the OS might assign the new low-priority thread to a core that is also running a high-priority thread. As indicated above, that arrangement may make it difficult or impossible for the processor to provide each thread with a desirable level of performance and efficiency.

Referring again to block <NUM> of <FIG>, as indicated above, when OS <NUM> is selecting a target LP to receive a new thread, if no LPs are currently idle, the process may pass through page connector B to <FIG>. Then, as shown at block <NUM>, OS <NUM> may determine whether the new thread is a low-priority thread or a high-priority thread. If it is a low-priority thread, OS <NUM> may assign it to a core with another low-priority thread, if possible. In particular, OS <NUM> may determine if any core is running only low-priority threads, as shown at block <NUM>. And in response to a positive determination, OS <NUM> may preempt a low-priority thread on such a core with the new thread, as shown at block <NUM>. Such a scenario is depicted in <FIG>.

<FIG> is a block diagram depicting three different stages of a process for assigning threads to LPs when no core has an idle LP. In the first stage <NUM> of <FIG>, LPs <NUM>, <NUM>, and <NUM> are running low-priority threads A, B, and C, respectively, while LP <NUM> is running high-priority thread D. Also, low-priority thread E is the new thread to be assigned to an LP by OS <NUM> (as indicated by the plus sign before "[LP Thread E]" at stage <NUM>). Consequently, at blocks <NUM> and <NUM> of <FIG>, OS <NUM> will preempt one of the threads on core <NUM> (e.g., low-priority thread B) with low-priority thread E, as shown at stage <NUM> of <FIG>.

Also, in the scenario of <FIG>, after stage <NUM>, one of the older LP threads terminates. Specifically, low-priority thread C on LP <NUM> terminates (as indicated by the minus sign before "[LP Thread C]" at stage <NUM>). Consequently, at stage <NUM>, LP <NUM> is idle. Consequently, processor <NUM> may then configure core <NUM> for high performance, while configuring core <NUM> for high efficiency.

By contrast, in a conventional data processing system, the OS might preempt an old low-priority thread on a core that is also running a high-priority thread. And a new low-priority thread may be unlikely to terminate before any of the older threads. Consequently, when the next LP becomes idle, that LP is more likely to be one of the LPs on the core with only low-priority threads.

By contrast, in the scenario of <FIG>, the core with mixed LPs (i.e., the core with one low-priority LP and one high-priority LP) is likely to become unifom sooner because the new thread does not get assigned to that core.

Referring again to <FIG>, block <NUM> of <FIG>, if the new thread is not a low-priority thread, it is a high-priority thread to be assigned to an LP, when no LPs are idle. In such a case, the process passes to block <NUM>, with OS <NUM> determining whether any core is running a low-priority thread. If any core has a low priority LP, OS <NUM> selects such as an LP for the new high priority thread and procinpts the low-priority thread on that LP with the new high-priority thread, as shown at block <NUM>. Also, as shown at blocks <NUM> and <NUM>, OS <NUM> clears the entries for that LP and that core in low-priority-LP list <NUM> and low-priority-core list <NUM>, since that LP is no longer a low-priority LP, and that core is not a low-priority core (because that core now has at least one high-priority LP). Alternatively, the operations for cleanng the entries for the selected LP and the selected core could be depicted as part of <FIG>, on the "No" branch of block <NUM>.

However, referring again to block <NUM> of <FIG>, if OS <NUM> has a new high-priority thread to assign to an LP, but (a) no LPS are currently idle, and (b) no LPs are currently running low-priority thread, OS <NUM> may use any suitable approach for determine how to assign that new thread, as shown at block <NUM>. For instance, OS <NUM> may determine whether the new thread is more important or has higher priority than any of the active high priority threads, OS <NUM> may wail for an LP to become idle, etc. The process of <FIG> may then end.

<FIG> presents a flowchart of an example embodiment of a process for updating LPCS register <NUM> with settings pertaining to energy efficiency. The process of <FIG> may run concurrently with the processes of <FIG> and <FIG>. As shown at block <NUM>, OS <NUM> may update low-priority-core list <NUM> when appropriate, as described above with regard to <FIG> and <FIG>. OS <NUM> may then determine whether a predetermined amount of time (i.e., an "update interval") has elapsed since OS <NUM> has updated LPCS register <NUM>. If the update interval has elapsed, OS <NUM> may write the data from low-priority-core list <NUM> to LPCS register <NUM>, as shown at block <NUM>. In addition, <NUM><NUM> may save a timestamp for the update, to establish the beginning of the next update interval, as shown at block <NUM>. As shown at block <NUM>, processor <NUM> may then manage the efficiency and performance of cores <NUM> and <NUM>, based on the new settings in LPCS register <NUM>. However, referring again to block <NUM>, if the update interval has not yet elapsed, OS <NUM> may continue to manage the efficiency and performance of cores <NUM> and <NUM>, based on the existing settings in LPCS register <NUM>.

Furthermore, PMU <NUM> may use LPCS register <NUM> to more effectively manage the performance and efficiency of processor <NUM>. For instance, PMU <NUM> may use LPCS register <NUM> to determine which cores are not running any high-priority threads (i.e., which cores are low-priority cores), and PMU <NUM> may then apply more aggressive efficiency techniques to those cores. By contrast, if a processor were to rely solely on EPP settings, the processor might not apply such aggressive efficiency techniques. For instance, a conventional processor with a core with two LPs and with EPP settings of about <NUM>% towards efficiency, might run that core at a higher P-state than is actually needed for the specified efficiency percentage, in order to avoid providing inadequate performance. For instance, an OS might specify EPP settings of about <NUM>% towards efficiency for foreground work such as media playback, and the processor might run the core at a higher P-state than the P-state that corresponds to <NUM>% efficiency in order to avoid an adverse impact on the user experience.

By contrast, processor <NUM> considers EPP registers <NUM>, <NUM>, <NUM>, and <NUM>, as well as LPCS register <NUM>. ?, and processor <NUM> switches to more aggressive power-saving algorithms when those settings agree, with regard to the desired or suitable level of efficiency. Processor may also switch to more aggressive performance algorithms when those settings agree, with regard to the desired or suitable level of performance.

For instance, when the EPP settings and the settings in LPCS register <NUM> are considered together, and those settings agree that one core has more high-priority threads than other cores, processor <NUM> may redirect hardware resources to the core with more high-priority threads from one or more cores with lower priority threads. Those hardware resources may include, for instance, cache, memory bandwidth, ring bandwidth, etc. For example, processor <NUM> may prioritize ring bandwidth requests from the core with more high-priority threads, and/or processor <NUM> may allocate more cache (e.g., <NUM>% of the cache) to the core with more high-priority threads. Similarly, data processing system <NUM> may prioritize memory bandwidth requests from the core with more high-priority thread, etc.

In addition or alternatively, processor <NUM> may use aggressive efficiency techniques in response to determining that the settings in LPCS register <NUM> and the EPP settings agree in indicating that all cores in a package are low priority cores (i.e., that no LPs are running high-priority threads). For instance, processor <NUM> may duty cycles all of the cores. In addition or alternatively, processor <NUM> may switch to lower P-states to implement a more restrictive energy budget, based on core "C-state" utilization (e.g., C0 percentage utilization), etc. In addition or alternatively, processor <NUM> may switch to aggressive package idle entries.

In addition, when a high-priority core has multiple high-priority LPs, OS <NUM> may automatically transfer a thread from one of those LPs to an idle LP on another core, in response to that idle LP entering idle. In particular, OS <NUM> may perform such a transfer when a core is running two low-priority threads, and then one of those threads terminates. Consequently, after OS <NUM> transfers one of the threads away from the high-priority core, that high-priority core may be able to execute more quickly and/or effectively, due to its reduced workload.

A data processing system may use the present teachings to realize desired levels of performance and efficiency. For instance, by grouping background work (e.g., work for which a high quality of service (QoS) is not needed) on background cores, and thereby making full physical cores available for foreground work (e.g., work for which a high quality of service (QoS) is desired), a processor may avoid or reduce thread migration and thread signaling across cores, and may thereby realize increased responsiveness. The processor may also run background cores more efficiently, thereby improving battery life, and also improving performance and responsiveness on cores running foreground work, due to additional energy budget available from running background cores efficiently.

<FIG> are block diagrams of exemplary computer architectures. The same or similar elements in <FIG> bear like reference numerals. Other system designs and configurations known in the arts 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, micro controllers, cell phones, portable media players, hand held devices, and various other electronic devices, are also suitable. In general, a huge variety of systems or electronic devices capable of incorporating a processor and/or other execution logic as disclosed herein are generally suitable.

<FIG> is a block diagram of a processor <NUM> that may have more than two cores, may have an integrated memory controller, and may have integrated graphics according to embodiments of the invention. The solid lined boxes in <FIG> illustrate a processor <NUM> with a single core 1102A, a system agent <NUM>, a set of one or more bus controller units <NUM>, while the optional addition of the dashed lined boxes illustrates an alternative processor <NUM> with multiple cores 1102A-N, a set of one or more integrated memory controller unit(s) in the system agent unit <NUM>, and special purpose logic <NUM>.

Thus, different implementations of the processor <NUM> may include: <NUM>) a CPU with the special purpose logic <NUM> being integrated graphics and/or scientific (throughput) logic (which may include one or more cores), and the cores 1102A-N being one or more general purpose cores (e.g., general purpose in-order cores, general purpose out-of-order cores, a combination of the two), <NUM>) a coprocessor with the cores 1102i\. -N being a large number of special purpose cores intended primarily for graphics and/or scientific (throughput): and <NUM>) a coprocessor with the cores 1102A-N being a large number of general purpose in-order cores. Thus, the processor <NUM> may be a general-purpose processor, coprocessor or special-purpose processor, such as, for example, a network or communication processor, compression engine, graphics processor, GPGPU, a high-throughput many integrated core (MIC) coprocessor (including <NUM> or more cores), embedded processor, or the like. The processor may be implemented on one or more chips. The processor <NUM> may be a part of and/or may be implemented on one or more substrates using any of a number of process technologies, such as, for example, BiCMOS, CMOS, or NMOS.

The memory hierarchy includes one or more levels of cache units 1104A-N within the cores, a set or one or more shared cache units <NUM>, and external memory (not shown) coupled to the set of integrated memory controller units <NUM>. The set of shared cache units <NUM> may include one or more mid-level caches, such as <NUM>, level <NUM> (L3), level <NUM> (L4), or other levels of cache, a last level cache (LLC), and/or combinations thereof. While in one embodiment a ring based interconnect unit <NUM> interconnects the special purpose logic <NUM>, the set of shared cache units <NUM>, and the system agent unit <NUM>/integrated memory controller unit(s) <NUM>, alternative embodiments may use any number of well-known techniques for interconnecting such units. In one embodiment, coherency is maintained between one or more cache units <NUM> and cores <NUM> A-N.

The system agent unit <NUM> includes those components coordinating and operating cores 1102A-N, The system agent unit <NUM> may include for example a power control unit (PCU) and a display unit. The PCU may be or include logic and components needed for regulating the power state of the cores 1102A-N and the integrated graphics logic <NUM>. The display unit is for driving one or more externally connected displays.

The cores 1102A-N may be homogenous or heterogeneous in terms of architecture instruction set; that is, two or more of the cores 1102A-N may be capable of execution the same instruction set, while others may be capable of executing only a subset of that instruction set or a different instruction set. Such cores 1102A-N may convert certain memory access instructions into subline memory access instructions as described herein.

<FIG> is a block diagram of a system <NUM> according to embodiments of the invention. The system <NUM> may include one or more processors <NUM>, <NUM>, which are coupled to a controller hub <NUM>. In one embodiment, the controller hub <NUM> includes a graphics memory controller hub (GMCH) <NUM> and an Input/Output Hub (IOH) <NUM> (which may be on separate chips); the GMCH <NUM> includes a memory controller to control operations within a coupled memory and a graphics controller to which are coupled memory <NUM> and a coprocessor <NUM>; the IOH <NUM> couples input/output (I/O) devices <NUM> to the GMCH <NUM>. Alternatively, one or both of the memory and graphics controllers are integrated within the processor, the memory <NUM> and the coprocessor <NUM> are coupled directly to the processor <NUM>, and the controller hub <NUM> is in a single chip with the IOH <NUM>.

The optional nature of additional processors <NUM> is denoted in <FIG> with broken lines. Each processor <NUM>, <NUM> may include one or more of the processing cores described herein and may be some version of the processor <NUM>.

The memory <NUM> may be, for example, dynamic random access memory (DRAM), phase change memory (PCM), or a combination of the two For at least one embodiment, the controller hub <NUM> communicates with the processor(s) <NUM>, <NUM> via a multi-drop bus, such as a frontside bus (FSB), point-to-point interface such as Quick Path Interconnect (QPI), or similar connection <NUM>.

In one embodiment, the coprocessor <NUM> is a special-purpose processor, such as, for example, a high-throughput MIC processor, a network or communication processor, compression engine, graphics processor, GPGPU, embedded processor, or the like. In one embodiment, controller hub <NUM> may include an integrated graphics accelerator.

In one embodiment, the processor <NUM> executes instructions that control data processing operations of a general type. Embedded within the instructions may be coprocessor instructions. The processor <NUM> recognizes these coprocessor instructions as being of a type that should be executed by the attached coprocessor <NUM>. Accordingly, the processor <NUM> issues these coprocessor instructions (or control signals representing coprocessor instructions) on a coprocessor bus or other interconnect, to coprocessor <NUM>. Coprocessor(s) <NUM> accept and execute the received coprocessor instructions.

<FIG> and <FIG> are block diagrams of more specific exemplary systems <NUM> and <NUM> according to embodiments of the invention. As shown in <FIG>, multiprocessor system <NUM> is a point-to-point interconnect system, and includes a first processor <NUM> and a second processor <NUM> coupled via a point-to-point interconnect <NUM>. Each of processors <NUM> and <NUM> may be some version of the processor <NUM>. In one embodiment of the invention, processors <NUM> and <NUM> are respectively processors <NUM> and <NUM>, while coprocessor <NUM> is coprocessor <NUM>. In another embodiment, processors <NUM> and <NUM> are respectively processor <NUM> and coprocessor <NUM>.

Processors <NUM> and <NUM> are shown including integrated memory controller (IMC) units <NUM> and <NUM>, respectively Processor <NUM> also includes as part of its bus controller units point-to-point (P-P) interfaces <NUM> and <NUM>; similarly, second processor <NUM> includes P-P interfaces <NUM> and <NUM>. Processors <NUM>, <NUM> may exchange information via a P-P interface <NUM> using P-P interface circuits <NUM>, <NUM>. As shown in <FIG>, IMCs <NUM> and <NUM> couple the processors to respective memories, namely a memory <NUM> and a memory <NUM>, which may be portions of main memory locally attached to the respective processors.

Processors <NUM>, <NUM> may each exchange information with a chipset <NUM> via individual P-P interfaces <NUM>, <NUM> using point to point interface circuits <NUM>, <NUM>, <NUM>, <NUM>. Chipset <NUM> may optionally exchange information with the coprocessor <NUM> via a high-performance interface <NUM>. In one embodiment, the coprocessor <NUM> is a special-purpose processor, such as, for example, a high-throughput MIC processor, a network of communication processor, compression engine, graphics processor, GPGPU, embedded processor, or the like.

As shown in <FIG>, various I/O devices <NUM> may be coupled to first bus <NUM>, along with a bus bridge <NUM> which couples first bus <NUM> to a second bus <NUM>. In one embodiment, one or more additional processors <NUM>, such as coprocessors, high-throughput MIC processors, GPGPUs, accelerators (such as, e.g., graphics accelerators or digital signal processing (DSP) units), field programmable gate arrays, or any other processor, are coupled to first bus <NUM>. In one embodiment, second bus <NUM> may be a low pin count (LPC) bus. Various devices may be coupled to a second bus <NUM> including, for example, a keyboard and/or mouse <NUM>, communication devices <NUM> and a storage unit <NUM> such as a disk drive or other mass storage device which may include instructions/code and data <NUM>, in one embodiment. Further, an audio I/O <NUM> may be coupled to the second bus <NUM>. Note that other architectures are possible. For example, instead of the point-to-point architecture of <FIG>, a system may implement a multi-drop bus or other such architecture.

<FIG> presents a block diagram of a second more specific exemplary system <NUM> in accordance with an embodiment of the present invention. Certain aspects of <FIG> have been omitted from <FIG> in order to avoid obscuring other aspects of <FIG>.

<FIG> is a block diagram of a system on a chip (SoC) <NUM> according to embodiments of the invention. Dashed lined boxes are optional features on more advanced SoCs. In <FIG>, an interconnect unit(s) <NUM> is coupled to: an application processor <NUM> which includes a set of two or more cores 1102A-N (including constituent cache units 1104A-N) and shared cache unit(s) <NUM>; a system agent unit <NUM>; a bus controller unit(s) <NUM>; an integrated memory controller unit(s) <NUM>; a set or one or more coprocessors <NUM> which may include integrated graphics logic, an image processor, an audio processor, and a video processor; an static random access memory (SRAM) unit <NUM>; a direct memory access (DMA) unit <NUM>; and a display unit <NUM> for coupling to one or more external displays. In one embodiment, the coprocessor(s) <NUM> include a special-purpose processor, such as, for example, a network or communication processor, compression engine, GPGPU, a high-throughput MIC processor, embedded processor, or the like.

In the present disclosure, expressions such as "an embodiment," "one embodiment," and "another embodiment" are meant to generally reference embodiment possibilities, Those expressions are not intended to limit the invention to particular embodiment configurations. As used herein, those expressions may reference the same embodiment or different embodiments, and those embodiments are combinable into other embodiments. In light of the principles and example embodiments described and illustrated herein, it will be recognized that the illustrated embodiments can be modified in arrangement and detail without departing from the principles described and/or illustrated herein.

Also, according to the present disclosure, a device may include instructions and other data which, when accessed by a processor, cause the device to perform particular operations. For purposes of this disclosure, instructions which cause a device to perform operations may be referred to in general as software. Software and the like may also be referred to as control logic. Software that is used during a boot process may be referred to as firmware. Software that is stored in nonvolatile memory may also be referred to as firmware. Software may be organized using any suitable structure or combination of structures. Accordingly, terms like program and module may be used in general to cover a broad range of software constructs, including without limitation application programs, subprograms, routines, functions, procedures, drivers, libraries, data structures, processes, microcode, and other types of software components. Also, it should be understood that a software module may include more than one component, and those components may cooperate to complete the operations of the module. Also, the operations which the software causes a device to perform may include creating an operating context, instantiating a particular data structure, etc. Embodiments may be implemented as software to execute on a programmable system comprising at least one processor, a storage system (e. g, volatile memory and/or one or more non-volatile storage elements), at least one input device, and at least one output device.

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

A medium which contains data and which allows another component to obtain that data may be referred to as a machine-accessible medium or a machine-readable medium Accordingly, embodiments may include machine-readable media containing instructions for performing some or all of the operations described herein. Such media may be referred to in general as apparatus and in particular as program products. In one embodiment, software for multiple components is stored in one machine-readable medium. In other embodiments, two or more machine-readable media may be used to store the software for one or more components. For instance, instructions for one component may be stored in one medium, and instructions another component may be stored in another medium. Or a portion of the instructions for one component may be stored in one medium, and the rest of the instructions for that component (as well instructions for other components), may be stored in one or more other media. Similarly, software that is described above as residing on a particular device in one embodiment may, in other embodiments, reside on one or more other devices. For instance, in a distributed environment, some software may be stored locally, and some may be stored remotely. Similarly, operations that are described above as being performed on one particular device in one embodiment may, in other embodiments, be performed by one or more other devices.

Other embodiments may be implemented in data and may be stored on a non-transitory storage medium, which if used by at least one machine, causes the at least one machine to fabricate at least one integrated circuit to perform one or more operations according to the present disclosure. Still further embodiments may be implemented in a computer readable storage medium including information that, when manufactured into an SoC or other processor, is to configure the SoC or other processor to perform one or more operations according to the present disclosure. One or more aspects of at least one embodiment may be implemented by representative instructions, stored on a machine-readable medium, which represent various logic units within the processor, and which, when read by a machine, cause the machine to fabricate logic units to perform the techniques described herein, The instructions representing various logic units may be referred to as "IP cores," and they may be stored on a tangible, machine-readable medium and supplied to various customers or manufacturing facilities to load into the fabrication machines that actually make the logic units or the processor. One or more aspects of at least one embodiment may include machine-readable media containing instructions or design data which defines structures, circuits, apparatuses, processors and/or system features described herein. For instance, design data may be formatted in a hardware description language (HDL).

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

It should also be understood that the hardware and software components depicted herein represent functional elements that are reasonably self-contained so that each can be designed, constructed, or updated substantially independently of the others. In alternative embodiments, components may be implemented as hardware, software, or combinations of hardware and software for providing the functionality described and illustrated herein. In some embodiments, some or all of the control logic for implementing the described operations may be implemented in hardware logic (e.g., as microcode in an integrated circuit chip, as a programmable gate array (PGA), as an application-specific integrated circuit (ASIC), etc.) Also, terms such as "circuit" and "circuitry" may be used interchangeably herein. Those terms and terms like "logic" may be used to refer to analog circuitry, digital circuitry, hard-wired circuitry, programmable circuitry, processor circuitry, microcontroller circuitry, hardware logic circuitry, state machine circuitry, any other type of hardware component, or any suitable combination of hardware components.

Additionally, the present teachings may be used to advantage in many different kinds of data processing systems. Such data processing systems may include, without limitation, accelerators, systems on a chip (SoCs), wearable devices, handheld devices, smartphones, telephones, entertainment devices such as audio devices, video devices, audio/video devices (e.g., televisions and set-top boxes), vehicular processing systems, personal digital assistants (PDAs), tablet computers, laptop computers, portable computers, personal computers (PCs), workstations, servers, client-server systems, distributed computing systems, supercomputers, high-performance computing systems, computing clusters, mainframe computers, mini-computers, and other devices for processing of transmitting information. Accordingly, unless explicitly specified otherwise or required by the context, references to any particular type of data processing system (e.g., a PC) should be understood as encompassing other types of data processing systems, as well. A data processing system may also be referred to as an apparatus. The components of a data processing system may also be referred to as apparatus.

Also, unless expressly specified otherwise, components that are described as being coupled to each other, in communication with each other, responsive to each other, or the like need not be in continuous communication with each other and need not be directly coupled to each other. Likewise, when one component is described as receiving data from or sending data to another component, that data may be sent or received through one or more intermediate components, unless expressly specified otherwise. In addition, some components of the data processing system may be implemented as adapter cards with interfaces (e.g., a connector) for communicating with a bus. Alternatively, devices or components may be implemented as embedded controllers, using components such as programmable or non-programmable logic devices or arrays, ASICs, embedded computers, smart cards, and the like. For purposes of this disclosure, the term "bus" includes pathways that may be shared by more than two devices, as well as point-to-point pathways. Similarly, terms such as "line," "pin," etc, should be understood as referring to a wire, a set of wires, or any other suitable conductor or set of conductors. For instance, a bus may include one or more serial links, a serial link may include one or more lanes, a lane may be composed of one or more differential signaling pairs, and the changing characteristics of the electricity that those conductors are carrying may be referred to as signals on a line. Also, for purpose of this disclosure, the term "processor" denotes a hardware component that is capable of executing software. For instance, a processor may be implemented as a central processing unit (CPU), a processing core, or as any other suitable type of processing element. A CPU may include one or more processing cores, and a device may include one or more CPUs.

Claim 1:
A data processing system (<NUM>) with technology for dynamically grouping threads, the data processing system (<NUM>) with a processor (<NUM>; <NUM>; <NUM>, <NUM>; <NUM>, <NUM>, <NUM>; <NUM>) comprising:
a first core comprising multiple logical processors, LPs (<NUM>, <NUM>, <NUM>, <NUM>);
a second core comprising multiple LPs (<NUM>, <NUM>, <NUM>, <NUM>);
a machine-readable medium responsive to the first and second cores (<NUM>, <NUM>; <NUM>); and
an operating system, OS, (<NUM>) stored at least in part in the machine-readable medium, wherein the OS (<NUM>), when executed in the data processing system (<NUM>), enables the data processing system (<NUM>) to perform operations comprising:
selecting (<NUM>) one of the LPs (<NUM>, <NUM>, <NUM>, <NUM>) in the processor (<NUM>; <NUM>; <NUM>, <NUM>; <NUM>, <NUM>, <NUM>; <NUM>) to receive a new low-priority thread; and
assigning (<NUM>) the new low-priority thread to the selected LP; and
wherein the operation of selecting one of the LPs (<NUM>, <NUM>, <NUM>, <NUM>) in the processor (<NUM>; <NUM>; <NUM>, <NUM>; <NUM>, <NUM>, <NUM>; <NUM>) to receive the new low-priority thread comprises:
when the first core has multiple idle LPs (<NUM>, <NUM>, <NUM>, <NUM>), automatically determining whether the second core has (a) an idle LP (<NUM>, <NUM>, <NUM>, <NUM>) and (b) a busy LP (<NUM>, <NUM>, <NUM>, <NUM>) that is executing a current low-priority thread; and
in response to determining that the second core has (a) an idle LP (<NUM>, <NUM>, <NUM>, <NUM>) and (b) a busy LP (<NUM>, <NUM>, <NUM>, <NUM>) that is executing a current low-priority thread, automatically selecting the idle LP in the second core to receive the new low-priority thread.