Method of task transition between heterogeneous processors

Abstract

To provide a method for optimizing performance per power consumption of a computer system.SOLUTION: The method includes determining that one or more tasks need to be relocated from a first processor to a second processor by comparing performance metrics to associated thresholds or using other indicators, stalling the first processor to relocate the one or more tasks from the first processor to the second processor, copying state information from the first processor to the second processor, and processing, by the second processor, an incoming task on behalf of the first processor using the state information.SELECTED DRAWING: Figure 8

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Patent Application No. 16 / 709,404, filed December 10, 2019, the contents of which are incorporated herein by reference. [Background technology]

[0002] Traditional computer systems rely on operating system-level and other high-level software decisions to move tasks between different processors in the system. These traditional solutions involve significant overhead in terms of performance inefficiencies and additional power consumption. By using more fine-grained tracking and decision-making to move tasks between different processors, performance per watt is optimized.

[0003] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which: [Brief explanation of the drawings]

[0004] [Figure 1] 1 is a block diagram of an example device capable of implementing one or more features of the disclosure. [Figure 2] 2 is a block diagram of the device of FIG. 1 showing additional details. [Figure 3] 1 is a block diagram illustrating an example of a system for efficiently processing input tasks. [Figure 4] FIG. 2 is a block diagram illustrating another example of a system for efficiently processing input tasks. [Figure 5] FIG. 2 is a block diagram illustrating another example of a system for efficiently processing input tasks. [Figure 6] 1 is a flowchart illustrating an example method for relocating tasks from a first processor to a second processor. [Figure 7]10 is a flowchart illustrating another example of a method for relocating tasks from a first processor to a second processor. [Figure 8] 10 is a flowchart illustrating another example of a method for relocating one or more tasks from a first processor to a second processor. DETAILED DESCRIPTION OF THE INVENTION

[0005] As described in more detail below, fine-scale optimization of performance-per-watt during execution is achieved by timely moving tasks between different processors. In one example, the first processor is a relatively less powerful, more power-efficient processor, and the second processor is a relatively more powerful, less power-efficient processor. Additionally or alternatively, the relatively less powerful processor can be considered a less power-consuming processor, and the relatively more powerful processor can be considered a more power-consuming processor. In another example, the first and second processors are heterogeneous, i.e., a central processing unit (CPU) and a graphics processing unit (GPU). Identifying applicable conditions and relocating tasks from a suboptimal processor to a more optimal processor improves performance per watt used and increases overall processing performance.

[0006] In one example, a method for relocating computer-implemented tasks from a relatively lower performance processor to a relatively higher performance processor includes monitoring one or more metrics associated with execution of the tasks by the relatively lower performance processor. The method further includes comparing at least one of the one or more metrics to a threshold. The method further includes selectively relocating the tasks to the relatively higher performance processor and executing the tasks on the relatively higher performance processor based on the comparison.

[0007] In another example, the at least one metric includes a core utilization metric of the relatively less high performance processor. In another example, the core utilization metric includes an indication of a duration that the relatively less high performance processor is running at maximum speed, and the threshold is an indication of a duration threshold. The task is relocated to the relatively more high performance processor if the indication of the duration that the relatively less high performance processor is running at maximum speed is greater than the duration threshold.

[0008] In another example, the at least one metric includes a memory utilization metric associated with the relatively less powerful processor. In another example, the memory utilization metric includes an indication of a duration that the memory is operating at a maximum memory performance state, and the threshold is an indication of a duration threshold. The task is relocated to the relatively more powerful processor provided that the indication of the duration that the relatively less powerful processor is running at maximum speed is greater than the duration threshold.

[0009] In another example, at least one metric of the one or more metrics includes a direct memory access (DMA) data rate.

[0010] In another example, a method for relocating computer-implemented tasks from a relatively high performance processor to a relatively low performance processor includes monitoring one or more metrics associated with execution of the tasks by the relatively high performance processor, the method further includes comparing at least one of the one or more metrics to a threshold, selectively relocating the tasks to the relatively low performance processor, and executing the tasks on the relatively low performance processor based on the comparison.

[0011] In another example, the at least one metric includes an indicator of a duration for which a single core of the relatively high-performance processor is used, and the threshold is an indicator of a duration threshold, and the task is relocated to the relatively low-performance processor if the indicator of the duration for which a single core of the relatively high-performance processor is used is less than the duration threshold.

[0012] In another example, the at least one metric includes a core utilization metric of a relatively high-performance processor, the core utilization metric of the relatively high-performance processor including an average utilization over a time interval, and the threshold is an indication of a utilization threshold, and the task is relocated to a relatively low-performance processor if the average utilization over the time interval is less than the utilization threshold.

[0013] In another example, the core utilization metric of the relatively high performance processor includes a mean time spent in an idle state, the threshold is an indicator of an idle threshold, and the task is relocated to the relatively low performance processor provided that the mean time spent in an idle state exceeds the idle threshold.

[0014] In another example, the at least one metric includes a memory utilization metric associated with a relatively less powerful processor, and the threshold is a memory utilization threshold, and the task is relocated to the relatively less powerful processor on condition that the memory utilization metric is less than the memory utilization threshold.

[0015] In another example, a method for relocating tasks from a first processor to a second processor includes placing the first processor in an idle or stalled state. The method further includes saving an architectural state of the first processor to a first memory location and copying the architectural state to a second memory location. The method further includes redirecting interrupts to the second processor and restoring, by the second processor, the architectural state from the second memory location. The method further includes fetching, by the second processor, an interrupt service routine (ISR) address, processing, by the second processor, the ISR using the ISR address, and executing one or more subsequent tasks by the second processor while the first processor remains idle or stalled.

[0016] In another example, the first memory location is associated with the first processor and the second memory location is associated with the second processor. In another example, the architectural state includes one or more register settings and one or more flag settings. In another example, the method further includes adjusting the architectural state. In another example, an incoming interrupt of the first processor is stalled until after the architectural state is copied to the second memory location so that the interrupt can be redirected to the second processor.

[0017] In another example, the ISR address is fetched from a local advanced programming interrupt controller (LAPIC).

[0018] In another example, the first processor is a relatively high performance processor and the second processor is a relatively low performance processor. The method further includes determining that the relatively high performance processor is underutilized and relocating one or more tasks to the second processor based on the determination.

[0019] In another example, the first processor is a relatively low performance processor and the second processor is a relatively high performance processor. The method further includes determining that the relatively low performance processor is over-utilized and relocating one or more tasks to the second processor based on the determination.

[0020] 1 is a block diagram of an example device 100 capable of implementing one or more features of the present disclosure. Device 100 may include, for example, a computer, a gaming device, a handheld device, a set-top box, a television, a mobile phone, or a tablet computer. Device 100 includes a processor 102, memory 104, storage 106, one or more input devices 108, and one or more output devices 110. Device 100 may also optionally include an input driver 112 and an output driver 114. It should be understood that device 100 may include additional components not shown in FIG. 1 .

[0021] In various alternatives, processor 102 may include a central processing unit (CPU), a graphics processing unit (GPU), a CPU and a GPU located on the same die, or one or more processor cores, each of which may be a CPU or a GPU. In various alternatives, memory 104 may be located on the same die as processor 102 or may be located separately from processor 102. Memory 104 may include volatile or non-volatile memory (e.g., random access memory (RAM), dynamic RAM, cache).

[0022] Storage 106 includes fixed or removable storage (e.g., hard disk drive, solid state drive, optical disk, flash drive). Input devices 108 include, but are not limited to, a keyboard, keypad, touch screen, touchpad, detector, microphone, accelerometer, gyroscope, biometric scanner, or network connection (e.g., wireless local area network card for transmitting and / or receiving wireless IEEE 802 signals). Output devices 110 include, but are not limited to, a display, speaker, printer, haptic feedback device, one or more lights, antenna, or network connection (e.g., wireless local area network card for transmitting and / or receiving wireless IEEE 802 signals).

[0023] The input driver 112 communicates with the processor 102 and the input device 108, allowing the processor 102 to receive input from the input device 108. The output driver 114 communicates with the processor 102 and the output device 110, allowing the processor 102 to send output to the output device 110. Note that the input driver 112 and the output driver 114 are optional components, and the device 100 operates similarly without the input driver 112 and the output driver 114. The output driver 114 includes an accelerated processing device (APD) 116 that is coupled to a display device 118. The APD 116 accepts computational commands and graphics rendering commands from the processor 102, processes those computational commands and graphics rendering commands, and provides pixel output to the display device 118 for display. As described in more detail below, the APD 116 includes one or more parallel processing units that perform computations according to the single instruction, multiple data (SIMD) paradigm. Thus, although various functions are described herein as being performed by or in conjunction with APD 116, in various alternatives, the functions described as being performed by APD 116 are not driven by a host processor (e.g., processor 102), but are additionally or alternatively performed by other computing devices having similar functionality for providing graphical output to display device 118. For example, it is contemplated that any processing system that performs processing tasks according to the SIMD paradigm may perform the functions described herein. Instead, computing systems that do not perform processing tasks according to the SIMD paradigm are contemplated for performing the functions described herein.

[0024] FIG. 2 is a block diagram of device 100 illustrating further details related to the execution of processing tasks on APD 116. Processor 102 maintains one or more control logic modules in system memory 104 for execution by processor 102. The control logic modules include operating system 120, kernel-mode driver 122, and applications 126. These control logic modules control various aspects of the operation of processor 102 and APD 116. For example, operating system 120 communicates directly with hardware and provides an interface to the hardware for other software executing on processor 102. Kernel-mode driver 122 controls the operation of APD 116, for example, by providing an application programming interface (API) for software (e.g., applications 126) executing on processor 102 to access various features of APD 116. Kernel-mode driver 122 also includes a just-in-time compiler that compiles programs for execution by processing components of APD 116 (such as SIMD unit 138, described in more detail below).

[0025] APD 116 executes commands and programs for selected functions, such as graphics and non-graphics processing, which may be suitable for parallel processing. APD 116 can be used to perform graphics pipeline operations, such as pixel manipulation, geometric calculations, and to render images on display device 118 based on commands received from processor 102. APD 116 also performs computational operations not directly related to graphics operations, such as video-related operations, physics simulations, computational fluid dynamics, or other tasks, based on commands received from processor 102.

[0026] The APD 116 includes a compute unit 132 that includes one or more SIMD units 138 that perform operations at the request of the processor 102 in parallel according to the SIMD paradigm. The SIMD paradigm allows multiple processing elements to share a single program control flow unit and program counter, thus executing the same program but with different data. In one example, each SIMD unit 138 includes 16 lanes, each of which executes the same instruction simultaneously with other lanes in the SIMD unit 138, but can execute the instruction with different data. Prediction can be used to turn off lanes when not all lanes need to execute a given instruction. Prediction can also be used to execute programs with branching control flow. More specifically, for programs where control flow has conditional branches or other instructions based on calculations performed by individual lanes, prediction of lanes corresponding to currently unexecuted control flow paths and serial execution of different control flow paths allows for arbitrary control flow.

[0027] The basic unit of execution on the compute units 132 is the work-item. Each work-item represents a single instantiation of a program executing in parallel on a particular lane. Work-items may execute simultaneously on a single SIMD processing unit 138 as a "wavefront." One or more wavefronts are included in a "workgroup," which includes a collection of work-items designated to execute the same program. A workgroup can be executed by executing each of the wavefronts that make up the workgroup. Alternatively, wavefronts may execute serially on a single SIMD unit 138 or partially or fully in parallel on different SIMD units 138. A wavefront can be thought of as the largest collection of work-items that can execute simultaneously on a single SIMD unit 138. Thus, if commands received from processor 102 indicate that a particular program is to be parallelized to such an extent that the program cannot run simultaneously on a single SIMD unit 138, then the program is divided into wavefronts that are processed in parallel on two or more SIMD units 138, or that are processed serially (or both in parallel and serially, as appropriate) on the same SIMD unit 138. Scheduler 136 performs the operations associated with scheduling the various wavefronts on the different compute units 132 and SIMD units 138.

[0028] The parallelism allowed by the computation units 132 is suitable for graphics-related operations such as pixel value calculations, vertex transformations, and other graphics operations. Thus, in some examples, the graphics processing pipeline 134, which receives graphics processing commands from the processor 102, provides computational tasks to the computation units 132 for execution in parallel.

[0029] Computation unit 132 is also used to perform computational tasks that are not related to graphics or that are not performed as part of the "normal" operation of graphics processing pipeline 134 (e.g., custom operations performed to supplement the processing performed for the operation of graphics processing pipeline 134). Applications 126 or other software running on processor 102 send programs defining such computational tasks to APD 116 for execution.

[0030] FIG. 3 is a block diagram illustrating an example of a system 300 for efficiently processing input tasks. Input 310 represents one or more tasks (e.g., interrupts) that require processing. Processing a task efficiently involves using only the resources necessary to reduce power consumption. As shown in FIG. 3, input 310 is provided to a first filter stage 320. The first filter stage 320 is an early service stage (e.g., a general-purpose input / output (GPIO) stage). In this example, the GPIO stage may not support the x86 instruction set. Provided that input 310 can be processed by the GPIO stage, all remaining filter stages and the highest-capability complex 340 remain powered down or in a low-power state, as shown at 330. In one example, an interrupt does not require the use of x86 instructions. Therefore, only the GPIO needs to be powered up to process the interrupt, while the remaining components of system 300 remain idle. In this scenario, keeping subsequent filter stages and the highest-capability complex in a low-power or powered-off state improves performance efficiency by avoiding unnecessary power consumption.

[0031] If the input 310 cannot be processed by the first filter stage 320, the input 310 is passed to a subsequent filter stage, such as the second filter stage 330 as shown in FIG. 3 . In one example, the second filter stage is a small or ultra-small processor. In this example, the small or ultra-small processor uses an x86 instruction set. The small or ultra-small processor can handle interrupt service routine (ISR) tasks that require x86 instructions, perform recovery tasks such as restoring architectural state associated with device configuration registers, restoring microarchitectural state required for the device to resume its execution, or running an operating system, and perform general-purpose low instructions per cycle (IPC) tasks. In another example, the small or ultra-small processor can warm up a last-level cache. In this example, the small or ultra-small processor fetches code and / or data into a shared cache between the small or ultra-small processor and the large processor, thereby avoiding request misses when execution switches to the large processor. Provided the ISR is passed to the small or ultra processor, the GPIO stage is idle, stalled, or powered down. The small or ultra processor may be, for example, a more powerful processor (e.g., a less powerful processor than the large core) from the highest capacity complex 340. In one example, the operating system or kernel is unaware of the small or ultra processor. For example, similar to that described above with respect to the first filter stage 320, any subsequent filter stages and the highest capacity complex 340 remain in a low-power or powered-down state, thus reducing power consumption and improving performance per unit of power used.

[0032] As shown in the example of FIG. 3, system 300 includes second through Nth filter stages 330, where N is any integer equal to or greater than one. Thus, similar to the above, input 310 passes through the filter stages until an appropriate filter stage is available to process input 310. Again, this hierarchy of filter stages allows subsequent filter stages and the most capable complex 340 to be kept in a low-power or powered-off state. Furthermore, once a filter stage is determined to be appropriate for processing a task, previous and subsequent stages may be idle, stalled, powered-off, etc. Although FIG. 3 shows a first filter stage 320 and second through Nth filter stages 330, any number of filter stages, including no filter stages, may be implemented. Additionally or alternatively, each filter stage may be a different core of a multi-core complex.

[0033] 3, if none of the previous filter stages are suitable, then the most capable complex 340 processes input 340. In one example, most capable complex 340 is one or more large central processing unit (CPU) cores, e.g., relatively more powerful than smaller or microprocessors. In one example, most capable complex 340 is a complex of CPU cores used to process longer and higher IPC tasks. Thus, if input 310 is a longer or higher IPC task, input 310 is passed to most capable complex 340 for processing, and filter stage 320 and the second through Nth filter stages are placed in a powered-down, low-power, stalled, or other state.

[0034] FIG. 4 is a block diagram illustrating another example of a system 400 for efficiently processing input tasks. An input / output (IO) domain / sensor 430 provides one or more input signals to a GPIO / initial service stage 440. In one example, the IO domain / sensor 430 provides any type of signal or task, or provides a signal associated with a task to be processed by one or more components included in a system-on-chip (SOC) 410. In one example, the GPIO / initial service stage 440 as shown in FIG. 4 does not support the x86 instruction set. Provided that inputs from the IO domain / sensor 430 can be processed by the GPIO / initial service stage 440, the small processor 450, core complex 460, fabric 420 including a fabric / local advanced programming interrupt controller (LAPIC) timer 473, and main memory 474 remain powered off or in a low-power state. For example, if an interrupt does not require the use of x86 instructions, the GPIO / initial service stage 440 processes the interrupt while the fabric 420 and its included components remain powered off or in a low-power state. GPIO / initial service stage 440 also receives input from always-on timer 471 and interfaces with local memory 472. GPIO / initial service stage 440 may be, for example, a small Advanced Reduced Instruction Set Computer (RISC) machine (ARM™) core, a small microcontroller, a microsequencer, a small hardware machine, or other low-power consumption device that may also be performance-efficient. Performance efficiency is improved by avoiding unnecessary power consumption if GPIO / initial service stage 440 can process incoming tasks / interrupts while fabric 420 and its contained components remain powered off or in a low-power state.

[0035] As shown in the example of FIG. 4 , system 400 includes fabric 420 that includes, among other things, small / micro processor 450. In one example, small / micro processor 450 is relatively more powerful than GPIO / initial service stage 440. If a task or interrupt from IO domain / sensor 430 cannot be serviced by GPIO / initial service stage 440, small / micro processor 450 is woken up and the task or interrupt is passed to small / micro processor 450. Small / micro processor 450 may be, for example, one core of a larger core complex, such as core complex 460. In another example, small / micro processor 450 may be a separate on-die microcontroller. In one example, small / micro processor uses an x86 instruction set. In this example, small / micro processor services ISR tasks that require x86 instructions, performs recovery tasks, and performs low instructions per cycle (IPC) tasks. In one example, small / microprocessor 450 is a less powerful processor than, for example, a more powerful processor from core complex 460. In another example, the operating system or kernel is unaware of small / microprocessor 450. Small / microprocessor 450 receives input from fabric / LAPIC timer 473, and small / microprocessor 450 interfaces with main memory 474. When small / microprocessor 450 is to service an interrupt, for example, fabric 420 is powered up, but core complex 460 remains off or in a low-power state, thus reducing power consumption and improving performance per power used.

[0036] As shown in the example of FIG. 4 , core complex 460 handles interrupts, for example, when GPIO / initial service stage 440 and small / micro processor 450 are unable to do so. In one example, core complex 460 is one or more central processing unit (CPU) cores that are relatively more powerful and / or relatively more power-consuming than, for example, a small or micro processor. One or more CPU cores in core complex 460 can be considered “large” cores. In one example, core complex 460 is a complex of CPU cores used to handle longer tasks and higher IPC tasks. Thus, core complex 460 is woken up to handle input tasks, provided that the input task is a longer or higher IPC task, such as an OS task.

[0037] FIG. 5 is a block diagram illustrating another example of a system 500 for efficiently processing input tasks. The system 500 includes, for example, a GPIO / initial service stage 510 that receives a task or interrupt. The GPIO / initial service stage 510 is coupled to one or more small / micro processors 520. On a condition that the GPIO / initial service stage 510 is unable to process the received task or interrupt, the one or more small processors 520 are woken up along with a fabric 580. The one or more small / micro processors 520, one or more large processors 530, a GPU 540, an IO 550, a global memory interconnect (GMI) 560, and one or more memory controllers 570 are coupled to the fabric 580. In one example, the fabric includes a transport layer and multiple bridges for connecting the one or more small / micro processors 520, the one or more large processors 530, the GPU 540, the IO 550, the GMI 560, and the one or more memory controllers 570 to the transport layer.

[0038] On the condition that one or more small / ultra-small processors 520 are unable to process a received task or interrupt, one or more large processors 530, along with fabric 580, are woken up to process the task or interrupt.

[0039] 6 is a flowchart illustrating an example method 600 for relocating a task from a first processor to a second processor. In one example, the first processor is a relatively low-performance processor and the second processor is a relatively high-performance processor. The method 600 includes, at step 610, monitoring one or more metrics associated with the execution of the task by the relatively low-performance processor.

[0040] The one or more metrics may include, for example, a core utilization metric for a relatively low-performance processor. In one example, the core utilization metric is a measurement of how much a relatively low-performance and / or relatively low-power processor is running at maximum speed. This measurement may indicate, for example, the percentage of time over a period of time that the relatively low-performance and / or relatively low-power processor is operating at or near maximum speed. In another example, the core utilization metric is the percentage of time over a time interval that the core presence of the relatively low-performance and / or low-power processor is in an active state. The one or more metrics may also include, for example, a memory utilization metric. In one example, the memory utilization metric is a measurement of how much memory is being used by the relatively low-performance processor. This measurement may indicate, for example, the percentage of time over a period of time that the memory is operating in a maximum performance state (sometimes referred to as a p-state). The one or more metrics may also include, for example, a direct memory access (DMA) progress indicator. In one example, the DMA progress indicator is a data rate over a period of time. In yet another example, the one or more metrics may include an interrupt arrival rate and / or a number of pending interrupts, where a high number of each indicates an urgency to switch from smaller or fewer intermediate processors to larger and / or more full-capability complexes.

[0041] As shown in FIG. 6 , method 600 includes, at step 620, comparing at least one metric of the one or more metrics to a threshold. In an example where the one or more metrics includes a core utilization metric, the core utilization metric, or more specifically, an indicator of a relatively low-performance processor operating at maximum speed, is compared to the core utilization metric. For example, a relatively low-performance processor may operate at maximum speed 50% of the time, and the threshold is 40%. In another example, the one or more metrics includes a memory utilization metric, and the threshold is a memory utilization threshold. In this example, the memory is at maximum performance 70% of the time, and the memory utilization threshold is 80%. In yet another example, the one or more utilization metrics includes a DMA data rate indicator, and the threshold is a data rate threshold. For example, the DMA data rate indicator indicates 10 megabytes per second, and the threshold is 12 megabytes per second.

[0042] As shown in FIG. 6 , method 600 includes, at step 630, relocating a task to a relatively high-performance processor based on the comparison performed in step 620. In one example, if the core utilization metric is greater than its associated threshold, the system determines that the relatively low-performance processor is over-utilized and relocates the task to the relatively high-performance processor. If the core utilization metric is below the threshold, the task is not relocated. In another example, if the memory utilization metric is greater than its associated threshold, the system determines that the relatively low-performance processor is over-utilized and relocates the task to the relatively high-performance processor. If the memory utilization metric is below the threshold, the task is not relocated. In yet another example, if the DMA progress rate is below an associated threshold, the system determines that the relatively low-performance processor is over-utilized and cannot make sufficient progress in processing the task. Therefore, the task is relocated to the relatively high-performance processor. If the DMA progress rate exceeds its associated threshold, the task is not relocated.

[0043] As shown in FIG. 6 , method 600 includes, at step 640, executing the task on the relatively high-performance processor based on the comparison. Logically, the task will be executed on the processor on which it is located. Thus, if the task is relocated to the relatively high-performance processor, the relatively high-performance processor will execute the task. Additionally, the relatively low-performance task will be powered down or otherwise placed in a low-power state. If the task is not relocated, the task will remain on the relatively low-performance processor and be executed by the relatively low-performance processor.

[0044] Tasks can be migrated from a relatively low-performance processor to a relatively high-performance processor based on other indicators in addition to those disclosed above. In one example, an ISR returns control to the OS. In this example, it is less desirable to run the OS on a relatively low-performance processor. Therefore, execution of OS tasks is migrated to the relatively high-performance processor. Additionally, the relatively low-performance processor is powered down or otherwise placed in a low-power state. In another example, a machine check architecture (MCA) event requires a software stack that is better suited to run on a relatively high-performance processor. MCA events may include, for example, transaction errors, data errors, or parity errors. In another example, any event involving system-level management requiring the OS is migrated to the relatively high-performance processor for execution. Again, the relatively low-performance processor is powered down or otherwise placed in a low-power state.

[0045] 7 is a flowchart illustrating an example method 700 for relocating a task from a first processor to a second processor. In one example, the first processor is a relatively high-performance processor and the second processor is a relatively low-performance processor. The method 700 includes, at step 710, monitoring one or more metrics associated with execution of the task by the relatively high-performance processor.

[0046] The one or more metrics may include, for example, a core utilization metric, a memory utilization metric, or a DMA progress metric, such as those described above with respect to FIG. 6. The one or more metrics may also include, for example, an indication of the amount that a single relatively high-performance core is utilized over a period of time. For example, a system may include multiple relatively high-performance processor cores, each of which may be considered equivalent to a relatively high-performance processor. In one example, a utilization measurement of only a single core among the multiple cores is tracked. In this example, the measurement is not specific to the same single core, but rather tracks the utilization of a single core at a point in time, where the specific core in use may change. In an example where the one or more metrics include a core utilization metric, the core utilization metric may indicate an average idle time of the relatively high-performance processor. For example, the average idle time may indicate how often over a time interval the relatively high-performance processor is in a particular idle state (e.g., a c-state) or indicate the average idle state (e.g., a c-state) that the relatively high-performance processor resides in over a time interval. It should be noted that a c-state is an Advanced Configuration and Power Interface (ACPI) idle state.

[0047] As shown in Figure 7, the method 700 includes comparing at least one metric of the one or more metrics to a threshold value at step 720. In an example where the one or more metrics includes an indication of the amount that a single relatively high performance core is utilized for a certain duration, provided that the single core is utilized above the threshold percentage, the system determines that the relatively high performance processor is unnecessary and relocates tasks to a relatively less high performance processor and powers down the relatively high performance processor.

[0048] 7, method 700 includes, at step 730, relocating the task to a less powerful processor based on the comparison performed at step 720. In one example, the task is relocated to the less powerful processor if the more powerful processor is idle on average 70% of the time, with the threshold being 50% of the time.

[0049] 7, method 700 includes, at step 740, executing the task on the less powerful processor based on the comparison. Logically, the task will be executed on the processor on which it is located. Thus, if the task is relocated to the less powerful processor, the less powerful processor continues executing the task. If the task is not relocated, the task will remain on and be executed by the more powerful processor.

[0050] 8 is a flowchart illustrating another example of a method 800 for relocating one or more tasks from a first processor to a second processor. In one example, the first processor is a relatively high-performance processor and the second processor is a relatively low-performance processor. In another example, the first processor is a relatively low-performance processor and the second processor is a relatively high-performance processor. In yet another example, the two processors are heterogeneous, such as a CPU and a GPU.

[0051] Method 800 includes, at step 810, determining that a first processor is to be placed in an idle or stalled state. The determination of whether the first processor needs to be placed in an idle or stalled state is performed as described above. For example, the first processor is a relatively low-performance processor, and the second processor is a relatively high-performance processor. Furthermore, in this example, the core utilization of the first processor exceeds its associated threshold. Therefore, it is determined that one or more tasks need to be relocated to the relatively high-performance processor. In one example, the relatively low-performance processor is a small core, a mini core, or a micro core. Step 810 may further include initiating a power-up process for the second processor while the first processor is still executing. The power-up process for the second processor may include, for example, raising voltage rails, repairing memory, sourcing fuses, and initializing core states. In this manner, the second processor may be ready to restore its architectural state so that execution can be switched to the second processor without a blackout. The method 800 further includes placing the first processor in an idle or stalled state at step 815. In one example, a microarchitectural scheme is implemented to stall the relatively low-performance processor. In another example, as part of stalling the relatively low-performance processor, it is first determined that all micro-operands have been retired, i.e., there are no outstanding instructions, there are no outstanding requests to memory, there are no remaining internal instruction streams, and there are no instructions being executed. In some examples, the relatively low-performance processor is expected to respond to incoming probes to its cache subsystem without releasing the relatively low-performance processor from a stalled state. In some examples, interrupts need to be blocked from entering the relatively low-performance processor and therefore wait at a boundary.

[0052] In another example, the first processor is a relatively high-performance processor and the second processor is a relatively low-performance processor. In one example, the higher-performance processor is determined to be idle, on average, more than an associated threshold. As such, it is determined that one or more tasks need to be relocated to the less high-performance processor, causing the higher-performance processor to, for example, enter a c-state. Note that, as noted above, this relocation may be between, for example, a GPIO / early service stage and a small / ultra-small processor, or this relocation may be between a small / ultra-small processor and a large processor.

[0053] Further, method 800 includes, at step 820, saving an architectural state of the first processor to a first memory location. In one example, the architectural state is a combination of one or more registers and one or more flags. The first memory location, in some examples, is associated with the first processor. In another example, method 800 includes starting step 815 at a time so that it overlaps with step 810 and ends when step 820 also ends, avoiding any delays associated with completing step 815.

[0054] Further, method 800 includes, at step 830, copying the architectural state from a first memory address to a second memory address. In some examples, the second memory address is associated with a second processor. In some examples, the architectural state is adjusted for the second processor. Optionally, at step 840, this adjustment is performed such that the adjusted architectural state is applied to the second processor. At step 850, the method further includes restoring the architectural state from the second memory address to the second processor. In another example, the memory used to copy the architectural state as in step 830 and to restore the architectural state as in step 850 is dedicated static random access memory (SRAM). In yet another example, instead of using memory in steps 830 and 850, a register bus can be bridged between the first and second processors to move the architectural state directly between the processors. At step 860, the incoming interrupt is redirected to the second processor. 8 as following step 850, an incoming interrupt received at any time prior to the completion of step 850 is stalled, resulting in the redirection of the interrupt to the second processor in step 860. In step 870, the ISR address of the incoming interrupt is fetched by the second processor and the interrupt is processed. After processing of the interrupt is complete, normal execution resumes in step 880 on the second processor.

[0055] Although some examples above describe relatively low performance processors and relatively high performance processors, any two or more heterogeneous processors may be used, for example, tasks from a CPU core may be relocated to a GPU core, and vice versa.

[0056] It should be understood that many variations are possible based on the disclosure herein, and although features and elements have been described above in particular combinations, each feature or element can be used alone without the other features and elements, or in various combinations with or without the other features and elements.

[0057] The various functional units illustrated in the figures and / or described herein (including, but not limited to, processor 102, input driver 112, input device 108, output driver 114, output device 110, accelerated processing device 116, scheduler 136, graphics processing pipeline 134, computational unit 132, and SIMD unit 138) may be implemented as a general-purpose computer, processor, or processor core, or as a program, software, or firmware stored on a non-transitory computer-readable medium or another medium and executable by the general-purpose computer, processor, or processor core. The provided methods may be implemented in a general-purpose computer, processor, or processor core. Suitable processors include, by way of example, a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors in conjunction with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, other types of integrated circuits (ICs), and / or state machines. Such a processor can be manufactured by configuring a manufacturing process using the results of the processed hardware description language (HDL) instructions and other intermediate data, including a netlist (such instructions, which may be stored on a computer-readable medium). The result of such processing may be a maskwork used in a semiconductor manufacturing process to produce a processor implementing the disclosed features.

[0058] The methods or flow charts provided herein may be implemented in a computer program, software, or firmware embodied in a non-transitory computer-readable storage medium for execution by a general-purpose computer or processor. Examples of non-transitory computer-readable storage media include read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs).

Claims

[Claim 1] 1. A method for rearranging computer-implemented tasks, comprising: executing the task in the microprocessor if the task can be processed by the microprocessor; In response to the microprocessor being unable to process the task, powering down the microprocessor; relocating the task from the microprocessor to a less powerful processor and executing the task on the less powerful processor; monitoring one or more metrics associated with the execution of the task by the relatively low performance processor; comparing at least one metric of the one or more metrics to a threshold; selectively relocating the tasks from the relatively lower performance processor to the relatively higher performance processor and executing the tasks on the relatively higher performance processor based on the comparison. method.

Images