Portable computing devices (PCDs) are ubiquitous. These devices may include cellular telephones, portable digital assistants (PDAs), portable game consoles, palmtop computers, and other portable electronic devices. In addition to the primary function of these devices, many include peripheral functions. For example, a cellular telephone may include the primary function of making cellular telephone calls and the peripheral functions of a still camera, a video camera, global positioning system (GPS) navigation, web browsing, sending and receiving emails, sending and receiving text messages, push-to-talk capabilities, etc. As the functionality of such a device increases, the computing or processing power required to support such functionality also increases. Further, as the computing power increases, there exists a greater need to effectively manage the processor, or processors, that provide the computing power.
Accordingly, what is needed is an improved method of executing a dynamic clock and voltage scaling algorithm in a central processing unit.
In the figures, like reference numerals refer to like parts throughout the various views unless otherwise indicated.
The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects.
In this description, the term “application” may also include files having executable content, such as: object code, scripts, byte code, markup language files, and patches. In addition, an “application” referred to herein, may also include files that are not executable in nature, such as documents that may need to be opened or other data files that need to be accessed.
The term “content” may also include files having executable content, such as: object code, scripts, byte code, markup language files, and patches. In addition, “content” referred to herein, may also include files that are not executable in nature, such as documents that may need to be opened or other data files that need to be accessed.
As used in this description, the terms “component,” “database,” “module,” “system,” and the like are intended to refer to a computer-related entity, either hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computing device and the computing device may be a component. One or more components may reside within a process and/or thread of execution, and a component may be localized on one computer and/or distributed between two or more computers. In addition, these components may execute from various computer readable media having various data structures stored thereon. The components may communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems by way of the signal).
Referring initially to
In a particular aspect, as depicted in
Referring to
As illustrated in
As further illustrated in
As depicted in
In a particular aspect, one or more of the method steps described herein may be stored in the memory 344 as computer program instructions. These instructions may be executed by the multicore CPU 324 in order to perform the methods described herein. Further, the multicore CPU 324, the memory 344, or a combination thereof may serve as a means for executing one or more of the method steps described herein in order to execute a dynamic clock and voltage switching algorithm within a central processing unit based on a type of workload.
Referring to
Moreover, as illustrated, the memory 404 may include an operating system 420 stored thereon. The operating system 420 may include a scheduler 422 and the scheduler 422 may include a first run queue 424, a second run queue 426, and an Nth run queue 428. The memory 404 may also include a first application 430, a second application 432, and an Nth application 434 stored thereon.
In a particular aspect, the applications 430, 432, 434 may send one or more tasks 436 to the operating system 420 to be processed at the cores 410, 412, 414 within the multicore CPU 402. The tasks 436 may be processed, or executed, as single tasks, threads, or a combination thereof. Further, the scheduler 422 may schedule the tasks, threads, or a combination thereof for execution within the multicore CPU 402. Additionally, the scheduler 422 may place the tasks, threads, or a combination thereof in the run queues 424, 426, 428. The cores 410, 412, 414 may retrieve the tasks, threads, or a combination thereof from the run queues 424, 426, 428 as instructed, e.g., by the operating system 420 for processing, or execution, of those task and threads at the cores 410, 412, 414.
In a particular aspect, the controller 440 may be a software program. However, in an alternative aspect, the controller 440 may be a hardware controller that is external to the memory 404. In either case, the controller 440, the memory 404, the cores 410, 412, 414, or any combination thereof may serve as a means for executing one or more of the method steps described herein in order to execute a dynamic clock and voltage switching algorithm within a central processing unit based on a type of workload.
Referring to
At decision 506, the controller may determine if a workload is added. The workload may be a video application, an audio application, an email application, a wireless network application, a cellular network application, a short message service (SMS) application, a communication application, a security application, a calendar application, an instant messaging application, a still camera application, a global positioning system (GPS) application, a browser application, a memo pad application, a clock application, a game application, a calculator application, a banking application, a password keeper application, a help application, an ecommerce application, a software delivery application, a search application, an options application, a setup application, a telephone application, a connection management application, a security application, any other application, or a combination thereof.
In a particular aspect, if a workload is not added at decision 506, the method 500 may return to block 504 and the method 500 may continue as described herein. Otherwise, at decision 506, if a workload is added, the method 500 may continue to decision 508, and the controller may determine whether the workload is a special workload, i.e., a type of workload which may warrant different treatment by a DCVS algorithm. The special workload may be an impulse workload, a registered workload, an isochronous workload, a pulsed workload, a best effort workload, a scheduled workload, or a combination thereof. The controller may determine whether the workload is a special workload based on an input received from the workload.
At decision 508, if the workload is not special, the method 500 may proceed to block 510 and the controller may execute an unaltered DCVS algorithm. Thereafter, the method 500 may move to decision 512 and the controller may determine whether the device is powered off. If the device is not powered off, i.e., the device remains on, the method 500 may return to block 504 and the method 500 may continue as described herein. Otherwise, if the device is powered off, the method 500 may end.
Returning to decision 508, if the workload is a special workload, the method 500 may continue to block 513 and the controller may receive a registration for the special workload. At block 514, the controller may assign a unique identifier to the special workload. Then, at decision 516, the controller may determine whether a DCVS solution is associated with workload, i.e., whether a modification, or an alteration, to a DCVS algorithm is associated with the workload. The workload may indicate a type associated the workload and a solution associated with the workload.
If a DCVS solution is associated with the special workload, the method 500 may proceed to block 518 and the controller may automatically retune the DCVS algorithm based on solution associated with the special workload. Next, at block 520, the controller may execute the retuned DCVS algorithm. The method 500 may then move to decision 512 and the method 500 may continue as described herein.
Returning to decision 516, if there is not a DCVS solution associated with the special workload, the method 500 may proceed to decision 522 and the controller may determine whether to create a new solution. For example, the controller may query the workload to determine if the workload has a predetermined solution. If so, the controller may implement that solution. Alternatively, the controller may query the workload for specific workload requirements and the controller may create a new solution for the workload based on the requirements of the workload. The workload requirements, for example, may be expressed in millions of instructions per second (MIPS). In another aspect, the workload requirement may be expressed as a frequency, e.g., a kilohertz value (kHz), a megahertz (MHz) value, a gigahertz (GHz) value, etc. In yet another aspect, the workload requirement may be expressed as a data transfer rate, e.g., kilobits per second (KB/S), megabits per second (MB/S), gigabits per second (GB/S), or a combination thereof. The workload requirements may further include a responsivity value. The responsivity may be a rate of change of a system setting. For example, the responsivity may be a rate of change of a CPU frequency, a rate of change of a voltage, or a combination thereof. Further, the responsivity may be a maximum delay as expressed in milliseconds, a CPU slew rate bound as expressed frequency per milliseconds (MHz/ms), or a combination thereof. Also, the workload requirements may include any combination of the preceding workload requirements.
At decision 522, if the controller does not decide to create a new solution, the method 500 may proceed to block 510 and the method 500 may continue as described herein. Otherwise, if the controller does decide to create a new solution, the method 500 may move to block 524 and the controller may create a new solution for the current workload, e.g., based on one or more workload requirements received from the current workload. Next, at block 526, the controller may store the new solution in a table or database associated. The solution may be stored in conjunction with a unique identifier associated with the workload. The method 500 may then move to block 518 and the method 500 may continue as described herein.
As shown in
Referring to
At decision 706, the controller may determine if a workload is added. The workload may be a video application, an audio application, an email application, a wireless network application, a cellular network application, a short message service (SMS) application, a communication application, a security application, a calendar application, an instant messaging application, a still camera application, a global positioning system (GPS) application, a browser application, a memo pad application, a clock application, a game application, a calculator application, a banking application, a password keeper application, a help application, an ecommerce application, a software delivery application, a search application, an options application, a setup application, a telephone application, a connection management application, a security application, any other application, or a combination thereof.
In a particular aspect, if a workload is not added at decision 706, the method 700 may return to block 704 and the method 700 may continue as described herein. Otherwise, at decision 706, if a workload is added, the method 700 may continue to decision 708, and the controller may determine whether the workload is an impulse workload. An impulse workload may be a key press event, a touchscreen event, another impulse type event, or a combination thereof. Further, an impulse workload may have a well known starting point, but no well known end, and no well known load. The response of the DCVS algorithm may depend on the specifics of each impulse workload. For example, the DCVS may respond to a keypad event by jumping to full performance, while a touchscreen event may not require a full performance response.
At decision 708, if the workload is not an impulse workload, the method 700 may move to block 710 and the controller may execute a standard, i.e., unaltered, DCVS algorithm. Thereafter, the method 700 may return to block 704 and the method 700 may continue as described herein.
Returning to decision 708, if the added workload is an impulse workload, the method 700 may proceed to block 712 and the controller may assign a unique identifier associated with the added workload. Next, at decision 714, the controller may determine whether there is a CPU frequency associated with the workload. The CPU frequency may be determined from historical values associated with the workload. The historical values may be stored in a controller associated with the workload.
If there is a CPU frequency associated with the workload, the method 700 may continue to block 716 and the controller may aggregate the new workload with any concurrent workloads, e.g., registered and un-registered. For example, if there were 100 MIPS of load associated with the impulse and 50 MIPS of other load, the controller would jump to 150 MIPS. Then, at block 717, the controller may jump to the aggregated CPU frequency. Thereafter, at block 718, the controller may execute the DCVS algorithm from current CPU frequency. Moving to decision 720, the controller may determine whether the device is powered off. If the device is not powered off, the method 700 may return to block 704 and the method 700 may continue as described herein. Otherwise, at decision 720, if the device is powered off, the method 700 may end.
Returning to decision 714, if the controller does not find a CPU frequency in the database that is associated with the added workload, the method 700 may move to block 722. At block 722, the controller may jump to a maximum CPU frequency. Next, at block 724, the controller may execute the DCVS algorithm from the maximum frequency and the controller, using the DCVS algorithm, may step down the CPU frequency until a correct, or appropriate, frequency value for the workload is found. At block 726, the controller may store the frequency. The method 700 may then move to decision 720 and the method 700 may continue as described herein.
The DCVS response indicator 904 may include a first DCVS response 910 and a second DCVS response 912. The first DCVS response 910 is a response without using historical information associated with the workload. As shown, the first DCVS response 910 jumps to a maximum CPU frequency. Thereafter, the first DCVS response 910 may decrease as the DCVS algorithm is executed.
The second DCVS response 912 is a response that utilizes historical information associated with the workload. As shown, the second DCVS response 912 jumps to CPU frequency that meets or slightly exceeds the need previously associated with the workload. Thereafter, the second DCVS response 912 may decrease as the DCVS algorithm is executed. Removing high responsivity events from the DCVS problem space, as shown, allows for lower power during low responsivity operations, while providing better performance for high responsivity operations and enabling power savings for those same operations.
In a particular aspect, impulse density may be used as a workload indicator. For example, having impulses close together may inhibit the DCVS response since the DCVS may ignore impulses from a single source that occur sufficiently close together. Alternatively, having dense impulse train may imply a greater workload and may intensify the DCVS. In a particular aspect, close may be workload specific.
Referring to
At decision 1006, the controller may determine if a workload is added. The workload may be a video application, an audio application, an email application, a wireless network application, a cellular network application, a short message service (SMS) application, a communication application, a security application, a calendar application, an instant messaging application, a still camera application, a global positioning system (GPS) application, a browser application, a memo pad application, a clock application, a game application, a calculator application, a banking application, a password keeper application, a help application, an ecommerce application, a software delivery application, a search application, an options application, a setup application, a telephone application, a connection management application, a security application, any other application, or a combination thereof.
In a particular aspect, if a workload is not added at decision 1006, the method 1000 may return to block 1004 and the method 1000 may continue as described herein. Otherwise, at decision 1006, if a workload is added, the method 1000 may continue to decision 1008, and the controller may determine whether a minimum CPU requirement for the workload is received, i.e., whether the workload is a registered workload with a particular requirement. If a minimum CPU requirement is not received, the method 1000 may proceed to block 1010 and the controller may execute, or cause to execute, a standard DCVS algorithm. Thereafter, the method 1000 may move to decision 1012. At decision 1012, the controller may determine whether the device is powered off. If the device is not powered off, the method 1000 may return to block 1004 and the method 1000 may continue as described herein.
Returning to 1008, if a minimum CPU requirement is received from the workload, the method 1000 may continue to block 1014. At block 1014, the controller may jump to the minimum CPU requirement received from the workload. Next, at block 1016, the controller may cause the DCVS to not execute for the workload. In other words, the controller may exempt the added workload from execution of the DCVS algorithm for the workload. Then, the method 1000 may continue to decision 1012 and continue as described herein.
For example, if a workload, task, or event, requests one hundred (100) MIPS of processing, and the DCVS algorithm simultaneously sees the CPU load increase by one hundred (100) MIPS, the DCVS algorithm may infer that there was no change in unrequested tasks. This may enable the DCVS algorithm to avoid false spikes in CPU usage. In such a case, the CPU response may track the workload on the performance critical leading region and the power critical trailing region without having the DCVS to respond to the workload.
Referring to
At decision 1306, the controller may determine if a workload is added. The workload may be a video application, an audio application, an email application, a wireless network application, a cellular network application, a short message service (SMS) application, a communication application, a security application, a calendar application, an instant messaging application, a still camera application, a global positioning system (GPS) application, a browser application, a memo pad application, a clock application, a game application, a calculator application, a banking application, a password keeper application, a help application, an ecommerce application, a software delivery application, a search application, an options application, a setup application, a telephone application, a connection management application, a security application, any other application, or a combination thereof.
In a particular aspect, if a workload is not added at decision 1306, the method 1300 may return to block 1304 and the method 1300 may continue as described herein. Otherwise, at decision 1306, if a workload is added, the method 1300 may continue to decision 1307 and the controller may determine whether the workload is an isochronous workload. An isochronous workload may be a workload that occurs at a substantially regular duration. Alternatively, an isochronous workload may be workload that occurs at a substantially regular interval at a substantially regular duration.
If the workload is not isochronous, the method 1300 may return to block 1304 and the method 1300 may continue as described herein. If the workload is isochronous, the method 1300 may proceed to block 1308. At block 1308, the controller may receive indication that a work interval has begun. Further, at block 1310, the controller may receive a suggested CPU setting from the workload. Next, at block 1312, the controller may receive a deadline for completion of the work.
Moving to decision 1314, the controller may determine whether a historical setting is available for the workload. If so, the method 1300 may proceed to block 1316 and the controller may determine CPU settings, e.g., a frequency, a voltage, etc., based on the deadline, the suggested CPU setting, and the historical setting. Next, at block 1318, the controller store a length of time and a frequency required to complete the work, when the work terminates. This may allow the controller to adapt to the workload and use the information on subsequent workload requests. In other words, this allows for adaptive learning by the controller.
Then, the method 1300 may move to decision 1320 and the controller may determine whether the device is powered off. If the device is not powered off, the method 1300 may return to block 1304 and the method 1300 may continue as described herein. Otherwise, if the device is powered off, the method 1300 may end.
Returning to decision 1314, if the controller does not have a historical setting for the workload, the method 1300 may proceed to block 1322 and the controller may determine one or more CPU settings based on the deadline and the suggested CPU setting. Thereafter, the method 1300 may proceed to block 1318 and the method 1300 may continue as described herein.
If the work in a particular use case is largely repeatable from interval to interval, it is possible to use data from previous work intervals to predict the amount of work that will be necessary in the next interval. In order to inform the dynamic resource manager, e.g., the controller, of its requirements, the use case indicates that a work interval has begun along with the deadline when the work needs to be completed. When the work is actually completed, the use case indicates that the work has finished.
With knowledge of how long the work had to complete versus how long the work actually took to complete, it is possible to find alternate resource settings that would be more power optimal yet still complete processing before the deadline. On subsequent requests, the resource receives the same information, but can use past history in order to determine more power optimal resource settings yet still complete the work before the deadline.
There is a series of statistics that the resource manager may keep for each use case. These statistics include the mean work per interval and the variance in work from interval to interval. These statistics may be determined adaptively from the requests, seeded via benchmarks, or fixed as constants. There are also some statistics that may be kept about the resource, which include the amount of work performed per resource setting and the variability of that work, possibly per resource setting.
To correctly function, future requests may have similar work requirements to previous ones. There are occasions when this is known to be false (say the video being decoded changes from 480i to 1080p—each frame now has a radically different amount of work). A mechanism may be provided to allow the use case to indicate that new requests constitute a new application and any previously learned statistics should be discarded. It is permissible for the use case to provide a hint to the resource manager, as shown in
It is permissible for the use case to provide a headroom requirement to the resource manager. This headroom specification is the amount of processing margin the resource must maintain when adjusting the resource setting. The headroom may alternatively be derived via work load variance.
With the indicators, it is possible for the target to optimize for power consumption independently of the use case—that is the use case implementation remains the same independent of the power optimization algorithm, even potentially independent of the target. A trivial initial implementation may include executing the resource at maximum, guaranteeing performance. Later, via offline optimization or adaptively determined statistics, the resource settings may be changed to a more power-optimal setting without having to modify the use case implementation.
In each of the methods described herein, rather than attempt to make the dynamic resource manager, i.e., the controller, be completely general purpose, the dynamic resource manager may be informed directly about the task requirements. This may allow the dynamic resource manager to make better resource management decisions. Use cases, or workloads, that benefit from informing the dynamic resource manager of their performance requirement may be identified and the requirements may be formalized. Further, an interface to the dynamic resource manager may be extended to integrate the information from the workloads.
The interface to the dynamically managed resources may include support for a series of common work models, e.g., required, isochronous, impulse, etc. All common work models may be placed in a library and may or may not be supported by any particular resource at the resource author's discretion. In addition, this may allow a resource author to define their own, potentially custom, work models and allow clients to issue these requests as well. These custom work models may be used to inform a resource of active client needs and minimize the required generality of the DCVS algorithm and increase optimization opportunities.
In a particular aspect, additional work models may include pulsed workloads, i.e., workloads that begin at a certain level and automatically cease at given time interval. Further, the work models may include best effort workloads that may include a hint that there is work that could be performed, but is not performance critical, it can be arbitrarily deferred. Also, the work models may include scheduled workloads that may include a notification that some amount of work will be required at a defined point in the future.
The methods described herein may allow the DCVS algorithm problem space to be arbitrarily reduced, and particular use case to be arbitrarily optimized, without impact to other use cases or other resources.
The methods described herein may further include additional inputs to the DCVS algorithm. For example, these additional inputs may include an idle distribution signal, an interrupt firing signal, and a timer firing signal. Further, the distribution of interrupts and timers may be used as additional inputs into the DCVS algorithm. By including these inputs, the DCVS algorithm may function more effectively and efficiently by having more enhanced system knowledge.
These inputs can be used to detect modes, such as audio playback, and adjust the DCVS algorithm to yield a more optimal solution for the detected case. The inputs may also be used to detect changes in modes, such as a phone call coming in, a user event, or even just the detection of non-volatile (NV) memory access to buffer audio content. Further, these inputs may enable tuning of the DCVS algorithm with substantially minimal client interaction.
It is to be understood that the method steps described herein need not necessarily be performed in the order as described. Further, words such as “thereafter,” “then,” “next,” etc. are not intended to limit the order of the steps. These words are simply used to guide the reader through the description of the method steps. Moreover, the methods described herein are described as executable on a portable computing device (PCD). The PCD may be a mobile telephone device, a portable digital assistant device, a smartbook computing device, a netbook computing device, a laptop computing device, a desktop computing device, or a combination thereof. Further, the method steps described herein may be executed on a single core processor, a multicore processor, multiple single core processors, multiple multicore processors, or any combination thereof. Also, the methods herein may be used to dynamically control various types of processors. For example, the methods herein may be used to control a central processing unit (CPU), a graphics processing units (GPU), etc.
In one or more exemplary aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a computer program product such as a machine readable medium, i.e., a non-transitory computer-readable medium. Computer-readable media includes computer storage media that facilitates transfer of a computer program from one place to another. A storage media may be any available media that may be accessed by a computer. By way of example, and not limitation, such non-transitory computer-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to carry or store desired program code in the form of instructions or data structures and that may be accessed by a computer. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of non-transitory computer-readable media.
Although selected aspects have been illustrated and described in detail, it will be understood that various substitutions and alterations may be made therein without departing from the spirit and scope of the present invention, as defined by the following claims.
The present application claims priority to U.S. Provisional Patent Application Ser. No. 61/294,019, entitled SYSTEM AND METHOD OF DYNAMICALLY CONTROLLING A PROCESSOR, filed on Jan. 11, 2010, the contents of which are fully incorporated by reference.
Number | Name | Date | Kind |
---|---|---|---|
5396635 | Fung | Mar 1995 | A |
5408663 | Miller | Apr 1995 | A |
5623647 | Maitra | Apr 1997 | A |
5692204 | Rawson et al. | Nov 1997 | A |
6081901 | Dewa et al. | Jun 2000 | A |
6230279 | Dewa et al. | May 2001 | B1 |
6278421 | Ishida et al. | Aug 2001 | B1 |
6298448 | Shaffer et al. | Oct 2001 | B1 |
6515530 | Boerstler et al. | Feb 2003 | B1 |
6684341 | Malcolm et al. | Jan 2004 | B1 |
6859882 | Fung | Feb 2005 | B2 |
7017060 | Therien et al. | Mar 2006 | B2 |
7131015 | Flautner et al. | Oct 2006 | B2 |
7131016 | Oh et al. | Oct 2006 | B2 |
7155617 | Gary et al. | Dec 2006 | B2 |
7174468 | Gary et al. | Feb 2007 | B2 |
7178043 | Nakazato | Feb 2007 | B2 |
7194385 | Flautner et al. | Mar 2007 | B2 |
7278136 | Moritz et al. | Oct 2007 | B2 |
7305521 | Park | Dec 2007 | B2 |
7321942 | Flautner et al. | Jan 2008 | B2 |
7386739 | Ghiasi et al. | Jun 2008 | B2 |
7437580 | Henderson et al. | Oct 2008 | B2 |
7463096 | Chi et al. | Dec 2008 | B2 |
7500124 | Seo | Mar 2009 | B2 |
7505795 | Lim et al. | Mar 2009 | B1 |
7512820 | Flautner et al. | Mar 2009 | B2 |
7583555 | Kang et al. | Sep 2009 | B2 |
7622979 | Bhatia et al. | Nov 2009 | B2 |
7624287 | Khodorkovsky et al. | Nov 2009 | B2 |
7711966 | Prabhakaran et al. | May 2010 | B2 |
7721127 | Vishin et al. | May 2010 | B2 |
7783759 | Eilam et al. | Aug 2010 | B2 |
7805620 | Yang et al. | Sep 2010 | B2 |
7821350 | Dai et al. | Oct 2010 | B2 |
7840825 | Altevogt et al. | Nov 2010 | B2 |
7913071 | Mallik et al. | Mar 2011 | B2 |
7930573 | Bland et al. | Apr 2011 | B2 |
7975155 | Rozen et al. | Jul 2011 | B2 |
7983870 | Hildebrand et al. | Jul 2011 | B2 |
8009090 | Vishin et al. | Aug 2011 | B2 |
8032317 | Houston et al. | Oct 2011 | B2 |
8112644 | Huang et al. | Feb 2012 | B2 |
8117469 | Schmitz et al. | Feb 2012 | B2 |
8127160 | Bieswanger et al. | Feb 2012 | B2 |
8145918 | Borghetti et al. | Mar 2012 | B2 |
8181051 | Barth | May 2012 | B2 |
8245057 | Lyu | Aug 2012 | B2 |
8255915 | Blanding et al. | Aug 2012 | B1 |
20020087611 | Tanaka et al. | Jul 2002 | A1 |
20040123297 | Flautner et al. | Jun 2004 | A1 |
20040139302 | Flautner et al. | Jul 2004 | A1 |
20050060597 | Albonesi et al. | Mar 2005 | A1 |
20050097228 | Flautner et al. | May 2005 | A1 |
20050193115 | Chellis et al. | Sep 2005 | A1 |
20050198102 | Hahn et al. | Sep 2005 | A1 |
20050268133 | Beard | Dec 2005 | A1 |
20050278561 | Seo | Dec 2005 | A1 |
20060100826 | Peterson | May 2006 | A1 |
20070011476 | Flautner et al. | Jan 2007 | A1 |
20070016817 | Albonesi et al. | Jan 2007 | A1 |
20070150763 | Yang et al. | Jun 2007 | A1 |
20070226741 | Seshadri | Sep 2007 | A1 |
20070234091 | Vishin et al. | Oct 2007 | A1 |
20080034366 | Tanaka et al. | Feb 2008 | A1 |
20080059813 | Khodorkovsky et al. | Mar 2008 | A1 |
20080077348 | Hildebrand et al. | Mar 2008 | A1 |
20080148273 | Huang et al. | Jun 2008 | A1 |
20080162965 | Marinas et al. | Jul 2008 | A1 |
20080301474 | Bussa et al. | Dec 2008 | A1 |
20080301690 | Do et al. | Dec 2008 | A1 |
20080313482 | Karlapalem et al. | Dec 2008 | A1 |
20090043493 | Sakai | Feb 2009 | A1 |
20090049314 | Taha et al. | Feb 2009 | A1 |
20090077290 | Dolwin | Mar 2009 | A1 |
20090193419 | McAlinden et al. | Jul 2009 | A1 |
20090204830 | Frid et al. | Aug 2009 | A1 |
20090254909 | Hanson et al. | Oct 2009 | A1 |
20090258641 | Yaqub et al. | Oct 2009 | A1 |
20090276639 | Saha et al. | Nov 2009 | A1 |
20100017042 | Lopata | Jan 2010 | A1 |
20100146316 | Carter et al. | Jun 2010 | A1 |
20100174928 | Borghetti et al. | Jul 2010 | A1 |
20100285769 | Conroy et al. | Nov 2010 | A1 |
20100289553 | Wang | Nov 2010 | A1 |
20110004774 | Hansquine et al. | Jan 2011 | A1 |
20110163801 | Chua-Eoan | Jul 2011 | A1 |
20110173463 | Gargash et al. | Jul 2011 | A1 |
20110173628 | Gargash et al. | Jul 2011 | A1 |
20130132973 | Gargash et al. | May 2013 | A1 |
Number | Date | Country |
---|---|---|
0992876 | Apr 2000 | EP |
H10501911 | Feb 1998 | JP |
H10333773 | Dec 1998 | JP |
2000112544 | Apr 2000 | JP |
2001273057 | Oct 2001 | JP |
0038038 | Jun 2000 | WO |
2009138953 | Nov 2009 | WO |
Entry |
---|
Gurun, Selim et al., AutoDVS: An Automatic, General-Purpse, Dynamic Clock Scheduling System for Hand-Held Devices UCSB Technical Report Apr. 2004, Mar. 1, 2005. |
Zhu, Yifan, Dynamic Voltage Scaling with Feedback Scheduling for Real-time Embedded Systems North Carolina State University, 2005. |
Lin, Bin et al., User and Process-Driven Dynamic Voltage and Frequency Scaling IPASS09, My 2009. |
Herbert, Sebastian et al., Variation-Aware Dynamic Voltage/Frequency Scaling Proc. Of the 15th International Symposium on High-Performance Computer Architecture (HPCA), Feb. 2009. |
Choi, Kihwan et al., Frame-Based Dynamic Voltage and Frequency Scaling for an MPEG Player Proc. of International Conference on Computer Aided Design (ICCAD), Nov. 2002. |
Gossens, Kees et al., Composable Dynamic Voltage and Frequency Scaling and Power Management for Dataflow Applications, DSD, 2010. |
Dhiman, Gaurav et al., Dynamic Voltage Frequency Scaling for Multi-tasking Systems Using Online Learning ISLPED,07, ACM, 2007. |
Flautner, Krisztian et al., Automatic Performance Setting for Dynamic Voltage Scaling Seventh Annual International Conference on Mobile Computing and Networking, May 30, 2001. |
Pillai, Padmanabhan et al., Real-Time Dynamic Voltage Scaling for Low-Power Embedded Operating Systems ACM, 2001. |
Chen, Jian-Jia et al., Energy-Efficient Scheduling for Real-Time Systems on Dynamic Voltage Scaling Platforms RTCSA '07 Proceedings of the 13th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications, 2007. |
Flautner, Krisztian et al., Vertigo: Automatic Performance Setting for Linux Proceedings of the 5th Symposium on Operating Systems Design and Implementation, Dec. 2002. |
Weissel, Andreas et al., Process Cruise Control: Event-Driven Scaling for Dynamic Power Management ACM, CASES2002, Oct. 8-11, 2002. |
Herbert, Sebastian et al., Analysis of Dynamic Voltage/Frequency Scaling in Chip-Multiprocessors ACM, ISLPED'07, Aug. 27-29, 2007. |
Wonyoung Kim, Meeta S. Gupta, Gu-Yeon Wei and David Brooks, “System Level Analysis of Fast, Per-Core DVFS using On-Chip Switching Regulators.” IEEE International Symposium on High-Performance Computer Architecture (HPCA), Feb. 2008. |
International Search Report and Written Opinion—PCT/US2011/020696—ISA/EPO—Apr. 1, 2011. |
Selim, S et al., Auto DVS: An Automatic, General-Purpose, Dynamic Clock Scheduling System for Hand-Held Devices ACM, EMSOFT'05, Sep. 19-22, 2005. |
Dhiman G., et al., “Dynamic Power Management Using Machine Learning,” ICCAD, 2006, pp. 747-754. |
Jung H., et al., “Continuous Frequency Adjustment Technique Based on Dynamic Workload Prediction,” 21st International Conference on VLSI Design, Jan. 2008, pp. 249-254. |
Lorch J.R., et al., “Improving Dynamic Voltage Scaling Algorithms with Pace,” Proceedings of the ACM Sigmetrics 2001 Conference, Jun. 2001, pp. 50-61. |
Lorch J.R., et al., “Using User Interface Event Information in Dynamic Voltage Scaling Algorithms,” Proceedings of the 11th IEEE/ACM International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunications Systems (MASCOTS), Oct. 2003, 10 Pages. |
Mallik A., et al., “PICSEL: Measuring User-Perceived Performance to Control Dynamic Frequency Scaling,” ASPLOS, 2008, pp. 1-10. |
Mallik A., et al., “User-Driven Frequency Scaling,” IEEE Computer Architecture Letters, 2006, vol. 5 (2), 2006, 4 pages. |
Poellabauer C., et al., “Feedback-Based Dynamic Voltage and Frequency Scaling for Memory-Bound Real-Time Applications,” in Proceedings IEEE Real-Time and Embedded Technology and Applications Symposium, 2005, 10 pages. |
Varma A., et al., “A Control-Theoretic Approach to Dynamic Voltage Scheduling,” CASES '03 Proceedings of the 2003 international conference on Compilers, architecture and synthesis for embedded systems, 2003, pp. 255-266. |
Yang L., et al., “HAPPE: Human and Application Driven Frequency Scaling for Processor Power Efficiency,” IEEE Transactions on Mobile Computing (TMC), May 31, 2012, 13 Pages. |
Number | Date | Country | |
---|---|---|---|
20110173617 A1 | Jul 2011 | US |
Number | Date | Country | |
---|---|---|---|
61294019 | Jan 2010 | US |