(12) United States Patent
`Cooper
`
`111111
`
`1111111111111111111111111111111111111111111111111111111111111
`US006823516Bl
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 6,823,516 Bl
`Nov. 23,2004
`
`(54) SYSTEM AND METHOD FOR
`DYNAMICALLY ADJUSTING TO CPU
`PERFORMANCE CHANGES
`
`(75)
`
`Inventor: Barnes Cooper, Aloha, OR (US)
`
`(73) Assignee: Intel Corporation, Santa Clara, CA
`(US)
`
`( *) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`(21) Appl. No.: 09/371,751
`
`(22) Filed:
`
`Aug. 10, 1999
`
`Int. Cl? .................................................. G06F 9/46
`(51)
`(52) U.S. Cl. ........................................ 718/108; 718/104
`(58) Field of Search ................................. 713/300-340;
`709/100, 108, 102
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`6/1991 Letwin ....................... 364/200
`5,027,273 A
`6/1994 Hwang ....................... 395!550
`5,319,772 A
`9/1995 Higashiyama et a!. ...... 361!103
`5,453,904 A
`12/1995 Tomiyori .................... 327/145
`5,475,324 A
`5,485,147 A * 1!1996 Jaffe eta!. ............... 340/825.5
`5,511,205 A * 4/1996 Kannan et a!.
`............. 713/324
`5,760,636 A * 6/1998 Noble eta!. ................ 307/117
`5,852,731 A * 12/1998 Wang et a!.
`................ 709/100
`5,903,599 A
`5/1999 Johnson et a!. ............. 375/219
`5,909,594 A * 6/1999 Ross eta!. .................... 710/20
`5,913,068 A * 6/1999 Matoba ...................... 713/322
`5,928,322 A * 7/1999 Bitar eta!. ................. 709/103
`5,994,844 A * 11/1999 Crawford et a!. ........... 315/151
`6,055,577 A * 4/2000 Lee et a!.
`................... 709/233
`
`6,098,123 A * 8/2000 Olnowich .................... 710/31
`6,118,306 A * 9/2000 Orton et a!.
`.................. 327/44
`6,131,166 A * 10/2000 Wong-Insley ............... 713/300
`6,219,742 B1 * 4/2001 Stanley ....................... 710/260
`6,272,642 B2 * 8/2001 Pole et a!.
`.................. 713/300
`6,412,021 B1 * 6/2002 Nguyen eta!. ............. 719/318
`6,418,535 B1 * 7/2002 Kulakowski eta!. ....... 713/320
`
`OTHER PUBLICATIONS
`
`Advanced Configuration and Power Interface Specification,
`Intel Microsoft Toshiba, Revision 1. Ob, 323 p., (Feb. 2,
`1999).
`* cited by examiner
`
`Primary Examiner-David Wiley
`Assistant Examiner-Joseph E. Avellino
`(74) Attorney, Agent, or Firm---Schwegman, Lundberg,
`Woessner & Kluth, P.A.
`
`(57)
`
`ABSTRACT
`
`In a computer system having a processor capable of oper(cid:173)
`ating at a plurality of performance states, including a first
`and a second performance state, wherein while the processor
`operates in any of the performance states it executes tasks at
`an expected processing performance, a system and method
`for dynamically adjusting to transitions between the first and
`second performance states. A determination is made that a
`performance state change is needed and a transition is
`initiated. The system halts task scheduling, measures CPU
`performance at the new performance state and resumes task
`scheduling within the constraints of the new performance
`state. The system also adjusts tasks as a function of CPU
`performance within the new performance state, wherein
`adjusting includes notifying each task of the transition
`between performance states.
`
`25 Claims, 11 Drawing Sheets
`
`THREAD CREATED
`OR DESTROYED
`
`THROffiiNG
`ENGAGED
`
`TRANSITION
`NOTIFICATION
`
`~
`
`45
`
`STOP THREAD
`SCHEDULING
`
`MEASURE CPU
`PERFORMANCE
`
`RESUME
`THREAD SCHEDULING
`
`RECALl BRA TE
`
`ROUTINES
`
`' 46
`' 47
`• 48
`SOFTWARE DElAY - OF PERFORMANCE
`~
`
`49
`NOTIFY PROCESS
`
`CHANGE
`
`DONE
`
`AMD EX1007
`U.S. Patent No. 6,895,519
`
`0001
`
`

`

`U.S. Patent
`
`Nov. 23, 2004
`
`Sheet 1 of 11
`
`US 6,823,516 Bl
`
`10
`
`"'
`
`)6
`PERFORMANCE
`CONTROL LOGIC
`
`\8
`
`10
`
`"'
`
`,..,16
`
`PERFORMANCE
`CONTROL LOGIC
`
`FIG. 1
`
`Vee
`Vss
`
`FIG. 2A
`
`10
`
`"'
`
`)6
`PERFORMANCE
`CONTROL LOGIC
`
`CLK
`
`FIG. 28
`
`14
`
`,J
`
`MEMORY
`
`•
`
`' .,.
`
`,..,12
`
`PROCESSOR
`
`14
`,..,
`
`MEMORY
`
`•
`
`' 7 )2
`PROCESSOR
`
`14
`
`,J
`
`MEMORY
`
`. ;:..
`• 7 )2
`
`PROCESSOR
`
`0002
`
`

`

`U.S. Patent
`
`Nov. 23,2004
`
`Sheet 2 of 11
`
`US 6,823,516 Bl
`
`16
`______________________ L ____ I
`VR_LO/HI#
`
`~--
`
`VGATE
`
`I ,------------,
`
`1
`
`1
`
`12..,.
`
`VOLTAGE
`REGULATOR
`
`I
`
`I
`I
`IV cpu
`I
`I
`I
`I
`____ __j
`
`L
`
`AGP
`GRAPHICS
`DEVICE
`
`..
`
`AGP
`
`·""
`
`STP-
`
`AGP#
`
`PCI
`
`CPU
`
`. "'
`
`<
`
`443BX
`
`SDRAM
`I SDRAM
`
`GPI1 #
`
`EXTSMI#
`
`CPU_STP#
`
`PIIX4E
`
`SUS_STAT1 #
`
`- - - - - -
`-
`- -
`EIO
`~
`~
`2
`0
`(/)
`(/)
`
`I
`I
`I
`I
`I
`I
`I
`I
`I
`L-----------------------------~
`FIG. 2C
`
`EMBEDDED
`CONTROLLER
`
`LO/HI#
`G_STPCLK# I
`G_INIT
`G_INTR
`G_NMI
`G_SMI
`
`PST
`CONTROL
`LOGIC
`
`:
`I
`I
`
`~
`
`"""*== O"'l
`c
`O"'l
`..s:::::.
`0
`0::: >
`
`~
`
`(/)
`(/)
`:::>
`(/)
`I
`(_')
`
`I
`(_')
`
`t
`
`:
`I
`I """*==
`I ~ """*== Q_
`I
`f-
`(/)
`I
`I
`:::>
`I
`Q_
`0
`I
`I
`I
`I
`I
`I
`PST
`I
`SYSTEM
`14
`I
`S_SUSSTAT1 # LOGIC #1
`I
`I
`I
`I
`:
`I
`________ _j
`
`0003
`
`

`

`U.S. Patent
`
`Nov. 23, 2004
`
`Sheet 3 of 11
`
`US 6,823,516 Bl
`
`NO
`
`NO
`
`YES
`
`34
`
`FIG. 3
`
`42.N
`
`42.1
`
`42.2
`
`REAL -TIME
`THREAD 3
`
`___./
`
`42.3
`
`42.4
`FIG. 4A
`
`0004
`
`

`

`U.S. Patent
`
`Nov. 23, 2004
`
`Sheet 4 of 11
`
`US 6,823,516 Bl
`
`THREAD CREATED
`OR DESTROYED
`
`THROTILING
`ENGAGED
`
`TRANSITION
`NOTIFICATION
`
`,.,45
`
`STOP THREAD
`SCHEDULING
`
`.-/46
`
`MEASURE CPU
`PERFORMANCE
`
`,J47
`
`RESUME
`THREAD SCHEDULING
`
`' 48
`
`,.1
`
`RECALIBRATE
`SOFTWARE DEIJ\Y
`ROUTINES
`
`' 49
`
`,.1
`
`NOTIFY PROCESS
`OF PERFORMANCE
`CHANGE
`
`-
`
`--
`
`DONE
`
`FIG. 48
`
`0005
`
`

`

`U.S. Patent
`
`Nov. 23,2004
`
`Sheet 5 of 11
`
`US 6,823,516 Bl
`
`50
`COLD RESET EVENT
`(CPU IN LOW POWER
`STATE)
`
`NO
`
`ADD PST SSDT
`TO ACPI TABLES
`
`60
`NOTIFY HARDWARE/
`FIRMWARE COMPONENTS
`THAT PST IS ENABLED
`
`NO
`
`TRANSITION TO
`HIGH PERFORMANCE
`STATE
`
`66
`
`BOOT SYSTEM
`
`FIG. 5
`
`0006
`
`

`

`U.S. Patent
`
`Nov. 23, 2004
`
`Sheet 6 of 11
`
`US 6,823,516 Bl
`
`70
`PERTINENT EVENT
`(AC, DOCK, PASSIVE
`THERMAL, BUSY, IDLE)
`72
`EVALUATE NUMBER
`OF PERFORMANCE
`STATES AVAilABLE
`
`76
`
`DISENGAGE THROTTLING
`
`YES
`
`YES
`
`NO
`
`TRANSITION
`TO LOW POWER
`STATE
`
`ENGAGE/ADJUST
`THROTTLING
`DUTY CYCLE
`
`YES
`
`88
`
`TRANSITION TO
`HIGH PERFORMANCE
`STATE
`
`DONE
`
`FIG. 6
`
`0007
`
`

`

`U.S. Patent
`
`Nov. 23,2004
`
`Sheet 7 of 11
`
`US 6,823,516 Bl
`
`304
`
`NO
`
`YES
`
`310
`DISABLE BUS
`MASTER ARBITER
`
`YES
`
`YES
`
`YES
`
`314
`
`316
`
`NO
`
`NO
`
`PREPARE HW FOR NEXT
`PERFORMANCE TRANSITION
`
`318
`
`320
`
`NO
`
`FIG. 7A
`
`0008
`
`

`

`U.S. Patent
`
`Nov. 23,2004
`
`Sheet 8 of 11
`
`US 6,823,516 Bl
`
`NO
`
`NO
`
`NO
`
`326
`ENABLE BUS
`MASTER ARBITER
`
`YES
`
`330
`
`ENABLE
`CPU CACHES
`
`YES
`
`NO
`
`336
`
`PERFORM TRANSITION
`
`NOT FINISHED
`
`FINISHED
`
`DONE
`
`340
`
`FIG. 78
`
`0009
`
`

`

`U.S. Patent
`
`Nov. 23,2004
`
`Sheet 9 of 11
`
`US 6,823,516 Bl
`
`NO
`
`102
`
`PROCESS
`NON-PST
`SMI
`
`106
`TRANSITION TO
`ACPI MODE AND
`ENABLE SCI
`
`ADJUST THERMAL
`THRESHOLDS FOR AC
`POWERED STATE (ACTIVE
`BELOW PASSIVE)
`
`ADJUST THERMAL
`HRESHOLDS FOR BATTER
`POWERED STATE (PASSIVE
`BELOW ACTIVE)
`
`126
`.------1.,--<~
`TRANSITION TO ENGAGE/ ADJUST
`LOW POWER
`LINEAR
`STATE
`THROTTLING
`
`DISENGAGE
`LINEAR
`1 34 THROTTLING
`TRANSITION TO
`LOW POWER
`STATE
`
`FIG. 8
`
`NO
`
`116
`TRANSITION TO
`LOW POWER
`STATE
`
`0010
`
`

`

`U.S. Patent
`
`Nov. 23,2004
`
`Sheet 10 of 11
`
`US 6,823,516 Bl
`
`APPLICATION
`COMMAND
`
`OPERATING
`SYSTEM COMMAND
`
`ENABLE/DISABLE L....-----,
`APP SUPPORT, GET STATUS,
`INITIATE TRANSITION REQUEST
`
`....---------' ENABLE OS SUPPORT
`
`SMI HANDLER
`RECEIVES
`REQUEST
`
`164
`
`170
`DISABLE SMM PST
`SUPPORT AND
`DISABLE APP
`INTERFACE
`
`DONE
`
`174
`DISABLE SMM PST
`SUPPORT AND
`ENABLE APP
`INTERFACE
`
`180
`
`DISABLE
`APPLICATION
`INTERFACE
`(ENABLESSMI)
`184
`PERFORM
`TRANSITION AND
`RETURN STATUS
`
`188
`
`RETURN
`STATUS
`
`FIG. 9A
`
`0011
`
`

`

`U.S. Patent
`
`Nov. 23,2004
`
`Sheet 11 of 11
`
`US 6,823,516 Bl
`
`HARDWARE EVENT
`GENERATION
`LOGIC
`
`INSERTION/REMOVAL
`AC
`EVENTS, USER FUNCTION KEY
`PRESSES, THERMAL THRESHOLD
`TRAVERSAL EVENTS
`.----------L.----,
`SMI HANDLER
`RECEIVES
`HARDWARE SMI
`
`150
`
`154
`
`RECORD
`>-----t~HARDWARE STATUS1-------.
`FOR APPLICATION
`
`158
`
`PERFORM
`TRANSITION
`
`NO
`
`A
`
`DONE
`
`FIG. 98
`
`0012
`
`

`

`US 6,823,516 Bl
`
`1
`SYSTEM AND METHOD FOR
`DYNAMICALLY ADJUSTING TO CPU
`PERFORMANCE CHANGES
`
`FIELD OF THE INVENTION
`
`The present invention is related to computing systems,
`and more particularly to a system and method for adjusting
`to changes in processor performance.
`
`BACKGROUND INFORMATION
`
`2
`executes tasks at an expected processing performance, a
`system and method is described for dynamically adjusting to
`transitions between the first and second performance states.
`A determination is made that a performance state change is
`5 needed and a transition is initiated. The system halts task
`scheduling, measures CPU performance at the new perfor(cid:173)
`mance state and resumes task scheduling within the con(cid:173)
`straints of the new performance state. The system also
`adjusts tasks as a function of CPU performance within the
`10 new performance state, wherein adjusting includes notifying
`each task of the transition between performance states.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`In the drawings, where like numerals refer to like com-
`15 ponents throughout the several views:
`FIG. 1 illustrates a computer system having enhanced
`thermal management characteristics;
`FIG. 2a illustrates a processor which shifts between
`performance dates as a function of a voltage level supplied
`by the performance control logic;
`FIG. 2b illustrates a processor which shifts between
`performance dates as a function of a frequency of a periodic
`wave form applied to its clock input;
`FIG. 2c illustrates a processor which shifts between
`performance dates as a function of both voltage level and
`clock frequency;
`FIG. 3 illustrates a process for switching between perfor(cid:173)
`mance dates;
`FIG. 4a illustrates a round robin execution scheme which
`can be used to divide available performance;
`FIG. 4b illustrates dynamic rescaling of real-time threads;
`FIG. 5 illustrates a boot process which can be used in a
`system having performance date transitions;
`FIG. 6 illustrates an example operating system policy
`scheme for managing performance date transitions;
`FIGS. 7a and 7b illustrate one method of transitioning
`between performance states.
`FIG. 8 illustrates use of SMis to implement performance
`date transitions; and
`FIG. 9 illustrates an alternate operating system policy
`scheme for managing performance state transitions.
`
`45
`
`DESCRIPTION OF THE PREFERRED
`EMBODIMENTS
`
`Designers of mobile computing platforms are faced with
`a delicate balance. They seek to increase performance of the
`CPU but at the same time limit the power consumed in order
`to conserve battery life and limit the heat generated by the
`system. As part of this balancing act mobile systems often
`rely on software-controlled thermal management systems in
`order to operate efficiently within a varying group of thermal
`constraints. For instance, a specification may define two or 20
`more thresholds that indicate temperatures at which different
`forms of software-controlled thermal management are acti(cid:173)
`vated. Active objects may be used to define a temperature
`threshold for a given thermal zone. When this threshold is
`exceeded, the operating system activates an active device 25
`(e.g., a fan or a remote heat exchanger), or reduces the
`battery charge current.
`Historically, CPUs have had a discrete operating point,
`characterized by a given frequency and power. The fre(cid:173)
`quency is typically some multiple of the external clock 30
`delivered to the CPU; the power dissipated by the CPU is a
`function of the core frequency and voltage applied to the
`CPU. As the applied voltage level is increased, advanced
`processing technologies allow for the core frequency to be
`increased, resulting in a nonlinear increase in power con- 35
`sumption.
`Mobile systems typically operate at the lowest voltage
`and frequency pair required to keep the typical dissipated
`power below mobile battery-powered limits. Because volt(cid:173)
`age can be increased to deliver higher performance for a 40
`given component, desktop CPUs typically deliver higher
`performance than their mobile counterparts at any given
`point in time.
`Systems have been proposed which use passive thresholds
`to define a temperature at which the power of one or more
`CPUs should be reduced in order to cool a given thermal
`zone. In the Advanced Configuration and Power Interface
`(ACPI) model, the operating system varies the CPU duty
`cycle so the power dissipation of the CPU matches the
`power dissipation capabilities of the system. See, Advanced
`Configuration and Power Interface (ACPI) Specification,
`Revision 1.0., published by Intel, Microsoft and Toshiba in
`1997. This type of thermal management is termed "throt(cid:173)
`tling" or "passive cooling. To support throttling, the ACPI
`model defines registers that allow the operating system to
`control the duty cycle of the CPU.
`Throttling reduces the heat generated by the mobile
`computing platform but does so without regard for process(cid:173)
`ing efficiency. What is needed is a system and method for
`reducing power generation without throttling the CPU.
`
`55
`
`50
`
`In the following detailed description of the preferred
`embodiments, reference is made to the accompanying draw(cid:173)
`ings which form a part hereof, and in which is shown by way
`of illustration specific embodiments in which the invention
`may be practiced. It is to be understood that other embodi(cid:173)
`ments may be utilized and structural changes may be made
`without departing from the scope of the present invention.
`Some portions of the detailed descriptions which follow
`are presented in terms of algorithms and symbolic repre(cid:173)
`sentations of operations on data bits within a computer
`memory. These algorithmic descriptions and representations
`are the means used by those skilled in the data processing
`60 arts to most effectively convey the substance of their work
`to others skilled in the art. An algorithm is here, and
`generally, conceived to be a self-consistent sequence of steps
`leading to a desired result. The steps are those requiring
`physical manipulations of physical quantities. Usually,
`65 though not necessarily, these quantities take the form of
`electrical or magnetic signals capable of being stored,
`transferred, combined, compared, and otherwise manipu-
`
`SUMMARY OF THE INVENTION
`
`In a computer system having a processor capable of
`operating at a plurality of performance states, including a
`first and a second performance state, wherein while the
`processor operates in any of the performance states it
`
`0013
`
`

`

`US 6,823,516 Bl
`
`3
`lated. It has proven convenient at times, principally for
`reasons of common usage, to refer to these signals as bits,
`values, elements, symbols, characters, terms, numbers, or
`the like. It should be borne in mind, however, that all of these
`and similar terms are to be associated with the appropriate
`physical quantities and are merely convenient labels applied
`to these quantities. Unless specifically stated otherwise as
`apparent from the following discussions, it is appreciated
`that throughout the present invention, discussions utilizing
`terms such as "processing" or "computing" or "calculating"
`or "determining" or "displaying" or the like, refer to the
`action and processes of a computer system, or similar
`electronic computing device, that manipulates and trans(cid:173)
`forms data represented as physical (electronic) quantities
`within the computer system's registers and memories into 15
`other data similarly represented as physical quantities within
`the computer system memories or registers or other such
`information storage, transmission or display devices.
`A computer system 10 with enhanced thermal manage(cid:173)
`ment characteristics is shown in FIG. 1. System 10 includes 20
`a processor 12 connected to a memory 14 and to perfor(cid:173)
`mance control logic 16. In one embodiment, performance
`control logic 16 places processor 12 in one of a plurality of
`discrete performance states by manipulating performance
`control input 18. Each of the performance states provides a 25
`certain level of processor performance while executing user
`threads.
`The presence of a plurality of performance states allows
`a given processor 12 to operate at increased performance
`levels in mobile systems when additional active cooling can
`be provided by the system. A CPU with performance state
`transition support is capable of dynamically switching
`between two or more discrete operating points (voltage/
`frequency pairs) by altering the bus ratio multiplier or the
`core voltage. The operating system is responsible for man(cid:173)
`aging these transitions to deliver the maximum performance
`possible while ensuring that battery life, thermal constraints
`and system integrity are not compromised.
`To ensure stable transitions, in one embodiment, perfor(cid:173)
`mance state transitions can only occur across resets. In
`another embodiment, however, performance state transitions
`are permitted to occur on either reset or by entering a
`quiescent state such as deep sleep. In yet another
`embodiment, performance control logic 16 is designed to
`permit transitions while the CPU is running. Such an
`approach may require additional logic to prevent race con(cid:173)
`ditions and other sources of instability.
`In one embodiment, as is shown in FIG. 2a, processor 12
`shifts between performance states as a function of a voltage so
`level applied to the power input (VcJ of processor 12. In
`another embodiment, as is shown in FIG. 2b, processor 12
`shifts between performance states as a function of the
`frequency of a periodic waveform applied to the clock input
`(CLK) of processor 12.
`In a third embodiment, processor 12 shifts between per(cid:173)
`formance states both as a function of a voltage level applied
`to the power input of processor 12 and as a function of the
`frequency of a periodic waveform applied to the clock input
`of processor 12. One such embodiment is shown in FIG. 2c.
`In the third embodiment, performance states are defined as
`core frequency and voltage pairs, and are made possible
`through the use of voltage reduction technology. By increas(cid:173)
`ing the core voltage, a processor 12 can operate at higher
`frequencies. In one such embodiment, the performance state
`of processor 12 can be increased to desktop levels of
`performance (and power consumption). Such platforms
`
`4
`therefore must be equipped with enhanced thermal capabili(cid:173)
`ties in order to dissipate power generated at the highest
`performance states. At the same time, system 10 also
`requires enhanced power supply capabilities in order to
`s effectively move between power supply voltages.
`In another embodiment, performance control logic 16
`provides a continuous range of voltage levels and adjusts the
`performance level of processor 12 as a function of a voltage
`level or a clock frequency supplied by performance control
`10 logic 16.
`Finally, in one embodiment, performance control logic 16
`simply modifies the core frequency to bus frequency ratio
`seen by processor 12, in order to move to a different
`performance state.
`In one embodiment, performance control logic 16
`includes circuitry that allows the CPU performance to be
`altered while the computer is functioning. In one such
`embodiment, logic 16 alters the performance of the CPU by
`changing the bus to core ratio that is latched from signals
`IGGNE#, A20M#, UNTO#, LINTl# during a hard proces(cid:173)
`sor reset. This allows the processor to run at different core
`frequencies depending upon the available system power in a
`mobile computer depending upon the amount of active
`cooling that can be accommodated given the system power
`constraints. Note that the external bus frequency is not
`altered, simply the internal core frequency is changed. In
`addition, in order to run at faster speeds (essentially above
`100%), the voltage is altered in addition to the bus ratio. This
`works in accordance with voltage reduction technology that
`30 allows a given processor to run at higher frequency when a
`higher voltage is applied. The side result, is that the power
`dissipated increase in a roughly cube-law fashion with
`increases in performance.
`For example, a mobile system might run at 300/100 (CPU
`core frequency/frontside bus frequency) while on battery, at
`350/100 while the AC adapter is inserted, and at 400/100
`while docked. This allows the notebook computer to operate
`at desktop performance levels when it is connected to a
`40 docking station that can provide the additional cooling
`needed to dissipate the additional CPU power.
`In one embodiment, processor 12 includes a hard reset
`capability used to perform state transitions. This means that
`for this embodiment, the entire processor state and L1/L2
`45 cache state is lost. In order to accommodate dynamic per(cid:173)
`formance state transitions, for one such embodiment, the
`system firmware makes this reset and all of its associated
`side effects transparent to the operating system.
`In one embodiment, performance transitions are governed
`by a cache protection mechanism and by a transition control/
`status mechanism. The cache protection mechanism is used
`by the operating system to protect the CPU's caches during
`a performance state transition. The transition control/status
`mechanism includes a set of registers used to initiate tran-
`ss sitions between different performance states, as well as to
`determine the current CPU performance state. In addition, in
`one embodiment, a separate voltage control is provided for
`moving between voltage levels at the processor. In one such
`embodiment, the voltage control includes separate voltage
`60 sequencing which operates under control of the operating
`system.
`To operate correctly in systems having performance state
`transition capability, the operating system must deal with the
`changes in processor performance. In situations where the
`65 operating system uses an internal time-stamp counter to
`implement software delays for device drivers, changes in the
`CPU core frequency may cause proportionate charges in the
`
`35
`
`0014
`
`

`

`US 6,823,516 Bl
`
`6
`5
`time-stamp counter, thereby altering the delay generated by
`cases, timeouts are typically needed to guarantee that the
`minimum time constraints are met. In other words, the delay
`the operating system function, and possibly causing device
`is expected to be at least some specified minimum value (it
`driver failure due to timing parameter violation. The oper(cid:173)
`could be more). In order to implement delays of this nature,
`ating system should take this into account when performing
`a performance state transaction.
`5 poorly written software may rely upon sections of code that
`have been timed either at boot time or (even worse) during
`In addition, allowing performance state transitions dras(cid:173)
`the software development cycle. These sorts of timing loops
`tically alters the CPU performance (i.e. MIPS). This is not
`are extremely primitive and can exhibit wildly varying
`a problem for normal applications, where a task will simply
`actual timing values depending upon CPU performance,
`take less or more time depending upon the amount of CPU
`10 CPU throttling, background task execution requirements,
`bandwidth. It is, however, a problem for real-time applica(cid:173)
`and interrupt handler CPU demands. This type of code uses
`tions. Real-time applications typically have a requirement of
`the following algorithm to calibrate a timing loop:
`a certain amount of instruction throughput per time quantum
`(i.e. MIPS/millisecond). As a result, technology will alter the
`1) Read and save CPU speed independent timer (e.g.,
`MIPS of the processor. In one embodiment, therefore, a
`8254 PIT timer zero)
`mechanism is defined to notify each process using real-time 15
`2) Loop a fixed number of times on a delay code fragment
`threads to adjust to the new processor performance.
`(same code fragment as used in delay routine)
`In one embodiment, processor 12 is limited to switching
`3) Read CPU speed independent timer
`performance states only during relatively quiescent states. In
`4) Subtract timer read of #1 from timer read of #3 to
`one such embodiment, as can be seen in FIG. 3, at 30 a
`indicate elapsed time
`determination is made as to whether a performance state 20
`5) Divide elapsed times by number of loops to indicate
`change is needed. If not, control remains at 30. If, however,
`time per loop
`a determination is made that a performance state change is
`6) Store time per loop in memory for later use
`needed, control moves to 32 and system 10 waits for
`A delay routine such as above calculates the number of
`processor 12 to enter a quiescent state. When the processor
`enters a quiescent state, control moves to 34 and perfor- 25
`loops required to implement the requested timing delay
`values by dividing the time requested by the time per loop.
`mance control logic 16 moves processor 12 to a new
`Although primitive, this delay provides a minimum con(cid:173)
`performance state. In one embodiment, performance control
`strained delay in non-performance-state-enabled systems.
`logic 16 ensures that processor 12 is in a relatively quiescent
`However, this type of delay poses a problem for
`state by intercepting all interrupts. In another embodiment,
`processor 12 is taken into a Deep Sleep state to ensure that 30
`performance-state-enabled systems because the system may
`be calibrated at the low power performance level, and then
`it is quiescent.
`transition to a higher performance state during runtime.
`In one embodiment, performance control logic 16 and
`Because the software is not notified of the CPU performance
`processor 12 cooperate to provide a plurality of performance
`change, it does not get a chance to recalibrate, and as a result
`states. In one embodiment, system 10 includes a low power
`state and a high performance state. Low power state is used 35 the delays could be shortened below some minimum timeout
`value. This situation can result in failure if the minimum
`to conserve battery power and reduce heat generated by
`timing (e.g., a timeout used for a hardware device to become
`system 10. High performance state provides the highest
`ready) causes device failure. Clearly, this sort of timing
`processing state possible given the power supply and ther(cid:173)
`delay methodology should be discouraged.
`mal capabilities of system 10. In another embodiment, 40
`The next type of timing delay is accomplished by reading
`system 10 includes a plurality of high performance states
`a hardware register directly and calculating the elapsed time
`covering a range of processing performance.
`between successive reads. This delay is calibrated by cal(cid:173)
`Performance state transitions introduce three potential
`culating the known frequency of the timer. The code then
`software issues that must be addressed. The first issue is that
`performs reads of the current time to delay some predeter-
`these transitions dramatically change the performance of the
`45 mined amount of time (TimePerTickxNumberOfTicks=
`CPU, which requires an accurate implementation of soft(cid:173)
`TotalTime). The following sequence of the steps is per(cid:173)
`ware timing methodologies. The second issue is that these
`formed to generate a delay using this technique (assuming
`transitions affect the ability of the system to accurately
`count up timer):
`execute real time threads. The third issue is that these
`1) Read and save initial timer value
`transitions induce additional latency into the operating sys- 50
`2) Divide requested time delay by timer tick granularity
`tern transition.
`3) Add timer ticks of step 2 to initial timer value of step
`1
`4) Read timer value until timer value of step 4 is above or
`equal to timer value needed of step 3
`This type of timing mechanism can generate CPU-speed
`independent delays if the timer itself is CPU speed inde(cid:173)
`pendent. One system timer that is not CPU speed indepen(cid:173)
`dent is the CPU Time Stamp Counter, which is incremented
`at the internal core clock frequency. If operation of the CPU
`Time Stamp Counter is modified as a function of perfor-
`mance state, this type of timing delay implementation is not
`recommended for Performance-state-enabled systems.
`Computer systems have been designed using architectures
`65 that provide one or more CPU-speed independent mecha(cid:173)
`nisms for implementing timing delays in software. The
`operating system should use one of these CPU-speed inde-
`
`Software Timing Issues
`As noted above, the fact that a processor 12 has a plurality
`of performance states does not necessarily give rise to 55
`software timing issues. If, for example, the performance
`level is set at boot time and never changed, there will be no
`software timing problems due to the fact that processor 12
`has a plurality of performance states, as this is no different
`than booting the system with a different performance CPU. 60
`However, when the CPU performance level is increased or
`decreased while the system is running (e.g., during AC
`insertion or removal), several operating system and appli(cid:173)
`cation software issues must be considered.
`Software timing is critical for many operations, particu(cid:173)
`larly when the software communicates directly with the
`hardware (e.g., device drivers, SMI code, BIOS). For these
`
`0015
`
`

`

`US 6,823,516 Bl
`
`7
`pendent mechanisms in order to provide robust APis with
`solid timing services for performance-state-enabled plat(cid:173)
`forms. Some examples of CPU-speed independent mecha(cid:173)
`nisms available in, for instance, architectures designed by
`Intel Corporation are as follows:
`Programmable Interval Timer 0 (IRQO)
`Real-Time Clock Periodic Rate Interrupt (IRQ8)
`ACPI Power Management Timer (SCI)
`Timing services based upon these or other CPU-speed
`independent mechanisms will not become inaccurate as a 10
`result of transitions between performance states.
`
`5
`
`8
`This method allows an operating system to dynamically
`adjust to changing CPU performance, and provides support
`for performance state transition technology.
`
`Latency Due to Performance State Transitions
`
`Another software visible impact of a performance-state(cid:173)
`enabled approach is that transitions between performance
`states hold off CPU operation for the duration of time it takes
`to switch between the performance states. This induces
`additional latency into the operating system transition that,
`if of long enough duration, could cause operating system
`failure. Care must therefore be taken to limit the latency due
`to performance state transitions.
`In one embodiment, the latency due to performance state
`15 transitions is limited to no more than approximately two
`hundred microseconds. Since operating systems currently
`operate with latencies which approach or even exceed this
`amount of performance state transition latency, such latency
`should not cause any appreciable problems for today's
`20 operating systems and peripheral demands. (The following
`events can induce latencies that may approach or even
`exceed the duration of performance state transition latencies:
`shared interrupt processing (e.g., PCI interrupt
`determination), coincident interrupt processing (probable
`25 net sum of masked ISR service time), CPU throttling (e.g.,
`244 microseconds), C2 State Exit Latency (e.g., 50
`microseconds), C3 State Exit Latency (e.g., 1 millisecond)
`and SMI Event Processing (e.g., 500 microseconds).)
`
`Real Time Threads
`Multitasking operating systems work by dividing the
`bandwidth of the processor across one or more threads of
`execution. Preemptive multitasking allows each thread to
`execute for some amount of time, and then the operating
`system moves onto to some other thread waiting to be
`executed. Typically, threads of execution are scheduled by
`means of a priority-based scheme, and typically, real-time
`threads receive nearly the highest priority. Because of their
`nature, real-time threads cannot afford to be delayed or
`interrupted for any length of time without losing data,
`dropping frames, or performing poorly (depends upon
`application). In addition, real-time threads must have a
`means for determining the available system bandwidth at
`boot, in order to gauge the amount of processing they can
`safely perform during each iteration of their execution. The
`diagram shown in FIG. 4a depicts a simple round-robin
`ex