Core selection based on usage policy and core constraints

Abstract

A processing unit of the processing system compiles a priority queue list of a plurality of processor cores and executes workloads based on a cost of executing the workload on each of the processor cores, the cost being based on at least one of a system usage policy, characteristics of the workload, and one or more physical constraints of each processor core. The processing unit selects a processor core based on the cost of executing the workload and communicates an identifier of the selected processor core to an operating system of the processing system.

Description

[Background technology]

[0001] Modern processors include multiple processor cores for executing instructions in parallel. As the number of processor cores in a processor or system-on-chip (SoC) increases, the processor cores tend to have a wide range of frequency responses relative to infrastructure constraints such as voltage and temperature. For example, each processor core has a different minimum voltage at which it reaches its maximum frequency at a given temperature. In addition, variations in frequency response among processor cores can arise due to differences in the microarchitecture or structural size of the processor cores. The heterogeneity of processor cores present on an SoC means that each processor core has different energy efficiency and maximum operating frequency characteristics, sometimes on the order of hundreds of megahertz.

[0002] The present disclosure may be better understood, and its numerous features and advantages made apparent to those skilled in the art by referencing the accompanying drawings, in which: The use of the same reference numbers in different drawings indicates similar or identical items. [Brief explanation of the drawings]

[0003] [Figure 1] FIG. 1 is a block diagram of a processing system including a processing unit configured to provide a selected core identifier to an operating system, according to some embodiments. [Figure 2] 2 is a block diagram of a core selection engine of the processing unit of FIG. 1 according to some embodiments. [Figure 3] FIG. 1 is a flow diagram of a method for compiling a priority queue list for a processor core for executing a workload, according to some embodiments. [Figure 4] FIG. 1 is a block diagram of a core selection engine that provides selected core identification information to an operating system, according to some embodiments. [Figure 5]FIG. 1 is a flow diagram illustrating a method for providing selected core identification information from a processing unit to an operating system, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0004] 1-5 illustrate systems and techniques for selecting one processor core (or a set of processor cores) from multiple processor cores of a processing device to execute a workload based on a system usage policy, e.g., voltage versus frequency response, and a range of constraints of the processor cores, and communicating the selected processor core(s) to an operating system (OS). In response to a processor core receiving a request from the OS to execute a first workload, a processing unit of the processor, such as a central processing unit (CPU) or accelerated processing unit (APU), compiles a priority queue list of processor cores to execute the first workload based on the cost of executing the first workload on each of the processor cores, the cost being based on, e.g., the system usage policy, characteristics of the first workload, and one or more physical constraints of each processor core. The processing unit selects a processor core based on the cost of executing the first workload and communicates an identifier of the selected processor core to the OS. In some embodiments, the processing unit writes the identifier of the selected processor core to a register that the OS reads.

[0005] When the processing unit communicates the identifier of the selected processor core to the OS, the processing unit removes or pops the selected processor core from the head of the priority queue, while the OS executes the first workload using the selected processor core. After the OS completes execution of the first workload on the selected processor core, the OS returns the selected processor core to the processing unit. The processing unit then calculates an updated cost for the selected processor core and re-inserts the selected processor core into the priority queue at a position based on the updated cost.

[0006] The processing unit has access to low-level physical constraint parameter values of the processor cores and reduces the computational burden on the OS that determines which processor core to select to execute a workload by maintaining a dynamically updated priority queue of processor cores and communicating an identifier of the selected core to execute each workload to the OS. The processing unit periodically updates the priority queue in response to interrupt events, such as a change in the power mode of the processing system from alternating current (AC) to direct current (DC) or vice versa. By selecting a processor core to execute a workload based on current cost and providing the selected processor identifier to the OS, as opposed to providing a static ordering of processor cores to the OS, the processing unit improves the performance and energy efficiency of the processing system and reduces the computational burden on the OS.

[0007] In some embodiments, if the OS requests another processor core to execute a second workload while the selected processor is executing a first workload, the processing unit updates the priority queue list of processor cores (not currently including the processor core selected to execute the first workload) for executing the second workload based on the cost of executing the second workload on each of the processor cores, the cost being based on the current system usage policy, the characteristics of the second workload, and one or more physical constraints of each processor core.

[0008] In some embodiments, the processing unit updates the priority queue periodically or based on interrupt events, such as an updated system usage policy. The system usage policy dynamically changes based on, for example, whether the processor is in AC mode (i.e., operating off the power grid), DC mode (operating off battery power), or whether the current application involves high graphics intensity. The physical constraints of each processor core include factors such as temperature, power, voltage required to reach a given frequency, reliability, required performance level, microarchitecture features, instructions per second, memory bandwidth, memory traffic within the memory controller, and age.

[0009] Periodically, or in response to an interrupt, such as an updated system usage policy or a new workload ready to be scheduled, the processing unit calculates the cost of executing a workload on each processor core based on the system usage policy and the physical constraints of each processor core. The processing unit sorts the processor cores in descending order of the calculated costs to compile a priority queue. Based on the priority queue updated based on the current costs, the processing unit selects a core that complies with the current usage policy for each workload.

[0010] FIG. 1 is a block diagram of a processing system 100 according to some embodiments. The processing system 100 includes a processing unit 102 and a processing unit 108. In various embodiments, the processing unit 108 includes one or more single-core or multi-core processor cores 110. The processing unit 102 includes a core selection engine 104 that generates a priority queue 106 for the processor cores 110 of the processing unit 108. The processing system 100 is generally configured to execute a set of instructions (e.g., a computer program), such as an application 116, to perform designated tasks of the electronic device. Examples of such tasks include controlling aspects of the operation of the electronic device, displaying information to a user to provide a particular user experience, communicating with other electronic devices, etc. Accordingly, in different embodiments, the processing system 100 is employed in any of numerous types of electronic devices, such as a desktop computer, a laptop computer, a server, a game console, a tablet, a smartphone, etc. It should be understood that the processing system 100 may include more or fewer components than those shown in FIG. 1 . For example, processing system 100 may further include one or more input interfaces, non-volatile storage, one or more output interfaces, a network interface, and one or more displays or display interfaces.

[0011] As shown in FIG. 1 , processing system 100 includes system memory 120, operating system 118, communications infrastructure 114, and one or more applications 116. Access to system memory 120 is managed by a memory controller (not shown) coupled to memory 120. For example, requests from processing unit 102 or other devices to read from or write to system memory 120 are managed by the memory controller. In some embodiments, one or more applications 116 include various programs or commands for performing computations executed in processing unit 102. Operating system 118 and communications infrastructure 114 are described in more detail below. Processing system 100 further includes a memory management unit, such as an input / output memory management unit (IOMMU) (not shown). Components of processing system 100 may be implemented as hardware, firmware, software, or any combination thereof. In some embodiments, processing system 100 includes one or more software, hardware, and firmware components in addition to or different from those shown in FIG. 1 .

[0012] Within processing system 100, system memory 120 includes non-persistent memory such as DRAM (not shown). In various embodiments, system memory 120 stores processing logic instructions, constant values, variable values during the execution of an application or other portion of processing logic, or other desired information. For example, in various embodiments, a portion of the control logic for performing one or more operations on processing unit 102 or processing unit 108 resides in system memory 120 during execution of the respective portion of the operation by processing unit 102 or processing unit 108. During execution, the respective applications, operating system functions, processing logic commands, and system software reside in system memory 120. Control logic commands fundamental to operating system 118 generally reside in system memory 120 during execution. In some embodiments, other software commands also reside in system memory 120 during execution of processing system 100.

[0013] In various embodiments, communications infrastructure 114 interconnects the components of processing system 100. Communications infrastructure 114 includes one or more of a Peripheral Component Interconnect (PCI) bus, a PCI-Extensible (PCI-E) bus, an Advanced Microcontroller Bus Architecture (AMBA) bus, an Advanced Graphics Port (AGP), or other such communications infrastructures and interconnections (not shown). In some embodiments, communications infrastructure 114 includes an Ethernet network or any other suitable physical communications infrastructure that meets the data transfer rate requirements of the application. Communications infrastructure 114 also includes functionality for interconnecting components, including the components of processing system 100.

[0014] Processing unit 102 includes one or more of a control processor, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or a digital signal processor (DSP) (not shown). Processing unit 102 executes at least a portion of the control logic that controls the operation of processing system 100. For example, in various embodiments, processing unit 102 executes an operating system 118 and one or more applications 116. In some embodiments, processing unit 102 initiates and controls the execution of one or more applications 116 by distributing processing associated with one or more applications 116 among processing units 102.

[0015] Processing unit 108 executes commands and programs for selected functions, such as graphics operations and other operations particularly suited to parallel processing. Generally, processing unit 108 is frequently used to perform graphics pipeline operations, such as pixel operations, geometric calculations, and rendering images to a display. In some embodiments, processing unit 108 performs computational processing operations (e.g., operations unrelated to graphics, such as video operations, physics simulations, computational fluid dynamics, etc.) based on commands or instructions received from processing unit 102. For example, such commands include special instructions not typically defined in the instruction set architecture (ISA) of processing unit 108. In some embodiments, processing unit 108 receives image geometry representing a graphics image along with one or more commands or instructions for rendering and displaying the image. In various embodiments, the image geometry corresponds to a two-dimensional (2D) or three-dimensional (3D) computerized representation of the graphics image.

[0016] In various embodiments, processing unit 108 includes one or more computational units, such as one or more processor cores 110 including one or more SIMD units (not shown) configured to execute threads concurrently with the execution of other threads within a wavefront, for example, according to a single instruction, multiple data (SIMD) execution model. A SIMD execution model is one in which multiple processing elements share a single program control flow unit and program counter, and thus can execute the same program but with different data. Some embodiments of processing unit 108 are used to implement a GPU, in which case processor cores 110 are referred to as shader cores or streaming multiprocessors (SMX). The number of processor cores 110 implemented in processing unit 108 is a matter of design choice. Each processor core 110 includes one or more processing elements, such as a scalar and / or vector floating-point unit, an arithmetic and logic unit (ALU), etc. In various embodiments, processor cores 110 also include dedicated processing units (not shown), such as an inverse square root unit and a sine / cosine unit.

[0017] Each of the processor cores 110 executes a respective instantiation of a particular work item to process input data, and the basic unit of execution in one or more processor cores 110 is a work item (e.g., a thread). Each work item represents a single instantiation of a collection of parallel executions of kernels launched on a device by commands that execute in parallel, for example. Work items execute on one or more processing elements as part of a workgroup that executes on the processor core 110.

[0018] The processing units 108 include GPUs that issue and execute work items, which include groups of threads that execute simultaneously as a "wavefront" or "workload" on a single SIMD unit. A wavefront may also be referred to interchangeably as a warp, vector, or thread. In some embodiments, a wavefront includes parallel execution instances of a shader program, and each wavefront includes multiple work items that execute simultaneously inline on a single SIMD unit using the SIMD paradigm (e.g., one instruction control unit executing multiple streams of data and the same instructions). A scheduler (not shown) is configured to perform operations related to scheduling various wavefronts on different processor cores 110, as well as other operations for orchestrating various tasks on the processing units 108.

[0019] Processor core 110 has a range of physical constraints, such as frequency response, relative to infrastructure constraints such as voltage and temperature. The physical constraints of a processor core can vary based on system use and workload. For example, if the temperature of processor core 110 exceeds a threshold, it may reduce the maximum frequency of processor core 110, adversely affecting the reliability of processor core 110. Conversely, greater deep C-state residency tends to increase the reliability of processor core 110.

[0020] The processing unit 102 includes a core selection engine 104 that dynamically selects a core or set of cores to execute each workload based on cost to improve performance, and communicates the selected cores to the OS 118. The core selection engine 104 has access to low-level physical constraint parameter values of the processor cores 110, such as power, temperature, voltage required to reach a given frequency, and reliability, reduces the computational burden on the OS 118 that determines which processor cores 110 to select to execute a workload by maintaining a dynamically updated priority queue 106 of the processor cores 110, and communicates an identifier 112 of the selected core 110 to execute each workload to the OS 118.

[0021] To illustrate, during operation, processing unit 102 receives a request from OS 118 for a processor core to execute a workload. Core selection engine 104 determines the cost of executing the workload on each of processor cores 110 based on a cost function that considers one or more of a current system usage policy, physical constraints of each of processor cores 110, and characteristics of the workload. Core selection engine 104 compiles a priority queue 106 that lists processor cores 110 in an order based on the calculated cost of executing the workload on each of processor cores 110. Core selection engine 104 selects a processor core from priority queue 106 to execute the workload and further communicates an identifier 112 of the selected core to OS 118. For example, in some embodiments, the cost function correlates high cost with high suitability for executing the workload given the current system usage policy, and core selection engine 104 selects the processor core with the highest cost.

[0022] In some embodiments, a request from OS 118 for a processor core to execute a workload includes an indication that the workload is of low priority, such as when OS 118 is executing a low priority background task. Because priority queue 106 already sorts processor cores from highest to lowest performance, core selection engine 104 selects the processor core with the lowest cost in response to receiving the indication that the workload is of low priority.

[0023] 2 is a block diagram of the core selection engine 104 of the processing unit 102 of FIG. 1 , according to some embodiments. The core selection engine 104 includes a power monitor 204, a system usage policy 206, a processor core physical constraint factor 210, and a core cost calculator 212. The core selection engine 104 determines the cost of executing the workload 202 on each processor core 110 (not shown) and compiles a priority queue 106 that lists the processor cores 110 in order of decreasing cost. The core selection engine 104 is implemented in hardware or in a microcontroller executing power management firmware code. In some embodiments, the core selection engine 104 is implemented as hard-coded or programmable logic, one or more processors executing software / firmware instructions, or any combination thereof.

[0024] The power supply monitor 204 monitors whether the processing system 100 is in an AC power mode or a DC power mode. In some embodiments, the power supply monitor 204 also monitors the battery charge level when the processing system 100 is in a DC power mode. The power supply monitor 204 may be implemented as hard-coded or programmable logic, one or more processors executing software / firmware instructions, or any combination thereof.

[0025] In some embodiments, the system usage policy 206 is implemented as a trade-off parameter Z208 having a fixed range [Zmin, Zmax], with lower values associated with higher battery mode / energy efficiency and higher values associated with higher performance. Thus, for example, in some embodiments, Z208 ranges from 0 for battery mode / energy efficiency to 1 for higher performance. The value of Z208 is continuous in some embodiments and discretized in other embodiments. In some embodiments, the trade-off parameter Z208 is adjustable by an end user or by the OS 118. The system usage policy 206 receives an indication from the power supply monitor 204 when the power mode of the processing system 100 changes from AC to DC or vice versa, or when the battery charge level falls below a threshold.

[0026] In some embodiments, trade-off value Z208 may be set according to a particular operating mode associated with a particular type of program or application executing on processing system 100. For example, in some embodiments, trade-off value Z208 may be set to a value indicative of "gaming mode." Once the gaming mode value is selected by an end user or OS 118, core selection engine 104 selects a group of two or more cores (a core complex) that share an L3 cache and other resources that has the best cost for workload 202.

[0027] Physical constraints 210 are a repository of per-workload and per-processor core 110 parameters such as power, temperature, required performance level, voltage required to reach a particular frequency, reliability, age, etc., as well as system-wide microarchitectural events such as instructions per second, memory bandwidth, and memory traffic at the memory controller, etc. In some embodiments, physical constraints 210 include a detected minimum voltage to reach a maximum frequency per core at a given temperature. In embodiments that may set trade-off value Z208 to a gaming mode value, physical constraints 210 include performance parameters of core complexes that share L3 cache and other resources.

[0028] The core cost calculator 212 determines the cost of executing the workload 202 on each processor core 110 for a given trade-off value Z 208. For example, in some embodiments, the core cost calculator 212 determines the following costs for each core: Cost(Core0)=f Core0 (X1,X2,...,X M ,Z) where X1 and X2 are parameters such as temperature, power, etc., and M is the total number of parameters used. More specifically, in some embodiments, core cost calculator 212 determines the cost per core using the following formula:

[0029]

number

[0030] In some embodiments, when the power supply monitor 204 indicates that the processing system 100 is operating in battery mode, the core cost calculator 212 employs a cost function that prioritizes low leakage over idling. In some embodiments, because high temperatures reduce the maximum frequency of the processor cores 110 and affect their reliability, the core cost calculator 212 employs a cost function that considers processor core temperature and determines hot spots on the chip. Similarly, high operating voltages reduce the reliability of the processor cores 110, while large deep C-state residency increases reliability. By employing a cost function that considers factors such as temperature, voltage, and deep C-state residency, the core cost calculator 212 calculates a cost for each processor core 110 that reflects such conditions. In some embodiments, the core cost calculator 212 employs a cost function that considers the minimum voltage to reach the maximum frequency for each processor core 110 at a given temperature, or the age of the processor core based on aging counters. The core cost calculator 212 calculates the per-core costs in a similar manner and compiles the priority queues 106 for the processor cores 110 based on the cost of executing the workload 202 on each processor core 110 .

[0031] 3 is a flow diagram of a method 300 for compiling a priority queue 106 of processor cores 110 for executing a workload, according to some embodiments. At block 302, the core selection engine 104 determines parameters for each processor core for executing the workload. At block 304, the core cost calculator 212 calculates a cost for each processor core 110 for executing the workload based on the parameters stored in the physical constraints 210, the currently effective system usage policy 206, and the characteristics of the workload. At block 306, the core selection engine 104 compiles a priority queue 106 that lists processor cores 110 based on their calculated costs. In some embodiments, a high cost correlates to a processor core that is suitable for executing the workload, and the core selection engine 104 lists the processor cores 110 in descending order of cost.

[0032] The core selection engine 104 recalculates the cost for each processor core 110 and periodically recompiles the list of processor cores 110 in the priority queue 106. In some embodiments, in response to an interrupt event, such as receiving a request from the OS 118 for a processor core 110 to run a new workload, a change in the system usage policy 206, or an indication from the power monitor 204 of a change in power mode, the core selection engine 104 recalculates the cost for each processor core 110 and recompiles the list of processor cores 110 in the priority queue 106.

[0033] 4 is a block diagram of the core selection engine 104 that provides selected core identification information to the operating system 118, according to some embodiments. Based on indicators from the power monitor 204 for power modes, the currently effective system usage policy 206 based on the trade-off parameter Z 208 setting, the physical constraint factors 210 for each processor core 110, and the characteristics of the workload, the core selection engine 104 compiles a priority queue 106 that lists four processor cores in descending order of cost for executing the workload. In the illustrated example, the core selection engine 104 lists processor core C3 406 as the highest cost processor core for executing the workload, processor core C1 402 as the second highest cost processor core for executing the workload, processor core C4 408 as the third highest cost processor core for executing the workload, and processor core C2 404 as the fourth highest cost processor core for executing the workload.

[0034] In response to receiving a request from the OS 118 for a processor core to execute a workload, the core selection engine 104 communicates an identifier for the processor core C3 406 to the OS 118 and pops (i.e., removes) the processor core C3 406 from the priority queue 106. In some embodiments, the core selection engine 104 communicates the identifier by writing the identifier to a register that is read by the OS 118. While the OS utilizes the processor core C3 406 to execute the workload, the priority queue 106 includes only the processor core C1 402 as the highest-cost processor core, the processor core C4 408 as the second-highest-cost processor core, and the processor core C2 404 as the third-highest-cost processor core. When the OS 118 requests a second processor core, the core selection engine 104 communicates an identifier for the processor core C1 402 to the OS 118 and pops the processor core C1 402 from the priority queue 106. At this time, the priority queue 106 includes only the processor core C4 408 and the processor core C2 404.

[0035] When OS 118 completes execution of the workload on processor core C3 406, OS 118 indicates to core selection engine 104 that the workload has completed execution on processor core C3 406. In response to receiving the indication, core selection engine 104 calculates a new cost of executing the next workload on processor core C3 406 and re-inserts processor core C3 406 into priority queue 106. In some embodiments, core selection engine 104 determines the cost for each processor core in response to an interrupt event, such as an updated system usage policy 206, or periodically.

[0036] In some embodiments, the request from OS 118 for a processor core to execute a workload includes an indication that the workload is low priority, such as when OS 118 is executing a low priority background task. In response to a processor core receiving a request to execute a low priority workload, core selection engine 104 communicates an identifier of lowest-cost processor core C2 404 to execute the workload and removes processor core C2 404 from priority queue 106.

[0037] 5 is a flow diagram illustrating a method 500 for providing a selected core identification from a processing unit to an operating system, according to some embodiments. Method 500 is performed by some embodiments of processing unit 102 shown in FIG. 1 and core selection engine 104 shown in FIG. 2.

[0038] At block 502, the processing unit 102 receives a workload request for a processor core from the OS 118. At block 504, the core selection engine 104 determines a system usage policy 206 based on the current value of the trade-off parameter Z 208. At block 506, the core cost calculator 212 applies a cost function to calculate a cost for each processor core 110 to execute the workload based on the indicators from the power supply monitor 204 of the power mode, the currently effective system usage policy 206 based on the trade-off parameter Z 208 setting, the physical constraints 210 for each processor core 110, and the characteristics of the workload.

[0039] At block 508, the core selection engine 104 compiles a priority queue 106 for the processor cores 110 and sorts them based on the calculated cost of executing the workload on each processor core 110. In some embodiments, a high cost correlates to a processor core that is suitable for the workload, and the core selection engine 104 sorts the processor cores in descending order according to cost, such that the processor core with the highest cost is the first processor core in the priority queue 106. In some embodiments, if the power supply monitor 204 indicates that the processing system 100 is operating in DC mode (battery), the core selection engine 104 selects the processor core 110 with the lowest leakage for idling as the selected processor core.

[0040] At block 510, core selection engine 104 communicates the identifier of the selected processor core for executing the workload to OS 118. In some embodiments, core selection engine 104 writes the identifier of the selected processor core to a register that is read by OS 118. Depending on the cost function applied by core cost calculator 212, changing a parameter or condition, such as switching from an AC power mode to a DC power mode, triggers a recalculation of the cost of executing the workload on each processor core, resulting in a change to the selected processor core identifier that is communicated to OS 118. In some embodiments, communicating the updated selected processor core identifier to OS 118 results in OS 118 scheduling new processing or migrating current tasks to other cores.

[0041] At block 512, in response to communicating the identifier of the selected processor core to the OS 118, the core selection engine 104 removes the identified selected processor core from the priority queue 106 while the OS 118 executes the workload on the selected processor core. When the workload completes execution on the selected processor core, the OS 118 indicates to the core selection engine 104 that the workload is complete. At block 514, the core selection engine 104 receives an indication from the OS 118 that the workload has completed execution. At block 516, the core cost calculator 212 calculates a new cost for the selected processor core, and the core selection engine 104 returns the selected processor core to the priority queue 106 at a position based on the new cost. Method flow then continues back to block 502 for the next workload.

[0042] A computer-readable storage medium includes any non-transitory storage medium or combination of non-transitory storage media that can be accessed by a computer system during use to provide instructions and / or data to the computer system. Such storage media may include, but are not limited to, optical media (e.g., compact discs (CDs), digital versatile discs (DVDs), Blu-ray discs), magnetic media (e.g., floppy disks, magnetic tape, magnetic hard drives), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or flash memory), or micro-electromechanical systems (MEMS)-based storage media. The computer-readable storage medium (e.g., system RAM or ROM) may be internal to the computing system, the computer-readable storage medium (e.g., a magnetic hard drive) may be permanently attached to the computing system, the computer-readable storage medium (e.g., an optical disk or Universal Serial Bus (USB)-based flash memory) may be removably attached to the computing system, or the computer-readable storage medium (e.g., network-accessible storage (NAS)) may be coupled to the computer system via a wired or wireless network.

[0043] In some embodiments, some aspects of the above techniques may be implemented by one or more processors of a processing system executing software. The software includes one or more sets of executable instructions stored in or tangibly embodied on a non-transitory computer-readable storage medium. The software may include instructions and specific data that, when executed by one or more processors, operate the one or more processors to perform one or more aspects of the above techniques. The non-transitory computer-readable storage medium may include, for example, a magnetic or optical disk storage device, a solid-state storage device such as flash memory, a cache, a random access memory (RAM), or one or more other non-volatile memory devices. The executable instructions stored on the non-transitory computer-readable storage medium may be source code, assembly language code, object code, or other instruction formats that can be interpreted or executed by one or more processors.

[0044] In addition to the above, it should be noted that not all activities or elements described in the summary description are required, that some of the particular activities or devices may not be required, that one or more additional activities may be performed, and that one or more additional elements may be included. Furthermore, the order in which the activities are listed is not necessarily the order in which they are performed. Also, the concepts have been described with reference to specific embodiments. However, those skilled in the art will recognize that various modifications and variations can be made without departing from the scope of the invention as set forth in the claims. Accordingly, the specification and drawings should be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present invention.

[0045] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and features from which any benefit, advantage, or solution may arise or be manifested are not construed as critical, essential, or essential features of any or all claims. Moreover, the specific embodiments described above are illustrative only, since the disclosed invention may be modified and practiced in different, but similar manners apparent to those skilled in the art having the benefit of the teachings herein. No limitations are intended to the details of construction or design herein shown, other than as described in the appended claims. It is therefore apparent that the specific embodiments described above may be altered or modified, and that all such variations are considered within the scope of the disclosed invention. Accordingly, the protection sought herein is set forth in the appended claims.

Claims

1. determining a first cost for executing a first workload on each processor core of a plurality of processor cores of the processing system; selecting a first processor core in a processing unit of the processing system to execute the first workload based on the first cost; communicating an identifier of the first processor core to an operating system of the processing system; method.

2. the first cost is based on at least one of a system usage policy, characteristics of the first workload, and one or more physical constraints of each processor core; 10. The method of claim 1.

3. The system usage policy is based on a trade-off between energy efficiency and performance. The method of claim 2.

4. and updating the first cost in response to detecting a change in the system usage policy. The method of claim 2.

5. compiling a first priority queue for the plurality of processor cores based on the first cost for executing the first workload on each processor core; the selecting step includes selecting a processor core having a highest first cost; 10. The method of claim 1.

6. receiving an indication from the operating system that the first workload has a low priority; and compiling a first priority queue for the plurality of processor cores based on the first cost for executing the first workload on each processor core; the selecting step includes selecting a processor core having a lowest first cost; 10. The method of claim 1.

7. receiving a request from the operating system for a first processor core to execute the first workload; and removing the selected processor core from the first priority queue in response to communicating an identifier of the selected processor core to the operating system. The method of claim 5.

8. receiving, at the processing unit, an indication from the operating system that execution of a first workload on the selected processor core has been completed; returning the selected processor core to the first priority queue; determining, in the processing unit, a second cost for executing a second workload on each processor core of the plurality of processor cores; and compiling, in the processing unit, a second priority queue for the plurality of processor cores based on the second cost for executing the second workload on each processor core. The method of claim 7.

9. Multiple processor cores; a processing unit, The processing unit determining a first priority queue for the plurality of processor cores based on a first cost for executing a first workload on each processor core; communicating to an operating system an identifier of a first processor core selected to execute the first workload based on the first priority queue; configured to: device.

10. the processing unit is further configured to write an identifier of the selected first processor core to a register configured to be read by the operating system. The device of claim 9.

11. the first cost is based on a system usage policy, characteristics of the first workload, and one or more physical constraints of each processor core; The device of claim 9.

12. the processing unit is further configured to update the first cost in response to detecting a change in the system usage policy. The device of claim 11.

13. The processing unit receiving a request from the operating system for a first processor core to execute the first workload; removing the selected first processor core from the first priority queue in response to communicating an identifier of the selected first processor core to the operating system; and further configured to: The device of claim 9.

14. The processing unit receiving an indication from the operating system that execution of a first workload on the selected first processor core has been completed; returning the selected first processor core to the first priority queue; determining a second cost for executing a second workload on each processor core of the plurality of processor cores; determining a second priority queue for the plurality of processor cores based on the second cost for executing the second workload on each processor core; and further configured to:

14. The device of claim 13.

Images