Wiki code for CPU Power Management

Hide Line numbers
1: ==  CPU Power Management
2: 
3: OpenSolaris provides support for Dynamic Frequency and Voltage Scaling (DVFS) across a range of Intel and AMD based processors. DVFS provides a mechanism enabling a processor to operate across a range of clock frequencies and voltages, allow one to trade off performance vs. power consumption. Intel’s "Enhanced Speedstep Technology", and AMD’s "PowerNOW!" are examples of DVFS. On x86 architectures, DVFS features are exposed to the OpenSolaris kernel through ACPI Performance States (P-States), where a P-State is an abstraction for a power/performance state. Changing P-states will typically cause the processor to change it’s operating voltage and frequency, resulting in a corresponding change in performance, and power consumed.
4: 
5: The ACPI standard also defines Core States (C-States), where a C-State is an abstraction for a state that a processor may enter while idle. Entering the C-State will typically cause the processor to suspend instruction execution. Because the processor doesn’t have to do any work, it may off-line various micro-architectural components facilitating an even lower dropping of voltage than would be possible in active operation. Entering deeper C-States results in lower power consumption, at the cost of an increased latency to recover to active operation.
6: 
7: This page describes the Tesla team’s project work to collectively provide OpenSolaris with a next-generation CPU Power management architecture, fully event-driven, predictive, adaptive, and integrated with the kernel’s thread scheduler/dispatcher subsystems.
8: 
9: ==  Projects
10: 
11: === OpenSolaris Power Aware Dispatcher (PAD)
12: 
13:  [[image:PAD.jpg||alt="PAD.jpg"]]
14: 
15:  CPU power management as it it implemented today is relatively isolated from the rest of the system. As such, it is forced to periodically poll to measure the utilization of the system’s CPU resources. When CPU utilization drops to a sufficiently low level, the power state (P-State) of the CPU is dropped. Likewise, when a CPU’s utilization increases, the P-State is raised to higher performing state. The present day architecture suffers from a few shortcomings:
16: 
17: * **Polling** is a poor thing for the power management subsystem to have to do. First, the question arises...how often to poll? There is a trade off that arises around polling more often to improve responsiveness to changes in utilization, vs. polling less often to minimize overhead. The current architecture polls relatively infrequently...which means that there are non-trivial durations of time where a thread may run on a clocked-down CPU before the PM subsystem notices that utilization has increased (and the CPU should be clocked up)...or where the CPU has become idle, but remains clocked up until the PM subsystem notices it should be clocked down. Polling is also inefficient, because it means that even on an otherwise quiescent system, the power management implementation still needs to wake up (bringing at least some resources into a higher power consuming state) to check to see if the system is still idle.
18: * **Power Management decoupled from Resource Management - ** The thread dispatcher is the kernel subsystem responsible for deciding where (on which CPUs) threads should be scheduled to run. At present, it has no notion of CPU power/performance states. At the same time, the CPU power management subsystem is polling looking for idle CPU resources to power manage. Having these two subsystems decoupled leads to situations where the two subsystems can undermine each other’s efforts, leading to poorer performance as threads are inadvertantly run on clocked down CPUs, or where utilization across the system remains light, but is distributed across the system to the point where nothing is quiescent enough to be power managed.
19: 
20:  This project extends the kernel’s existing topology aware scheduling facility to bring "power domain" awareness to the dispatcher. With this awareness in place, the dispatcher can implement coalescence dispatching policy to consolidate utilization onto a smaller subset of CPU domains, freeing up other domains to be power managed. In addition to being domain aware, the dispatcher will also tend to prefer to utilize domains already running at higher power/performance states...this will increase the duration and extent to which domains can remain quiescent, improving the kernel’s ability to take advantage of features like deep C-states. Because the dispatcher will track power domain utilization along the way, it can drive active domain state changes in an event driven fashion, eliminating the need for the CPUPM subsystem to poll.
21: 
22: ==== Status
23: 
24:  PAD and Deep C-states support integrated into Nevada build 110 on Wednesday Feb 25th, 2009. For more information, please see the [[Flag Day and Heads Up announcement>>Community Group on.2009022501]].
25: 
26: ====  Bugs/RFE CR numbers
27: 
28:  Integration:
29: 
30: * [[6567156>>http://bugs.opensolaris.org/view_bug.do?bug_id=6567156]] bring CPU power awareness to the dispatcher
31: 
32: ====  Documents
33: 
34: * [[Status update presentation>>./PAD_status.pdf]], 7/8/08
35: * [[PSARC 2008/777>>Community Group arc.777]] cpupm keyword mode extensions
36: * [[Overview and Code Walkthrough>>./PAD_code_intro.pdf]], 1/15/09
37: 
38: ====  Power Aware Dispatcher Source Repository
39: 
40: * **pad-gate**: This repository is closed, as the project has integrated. Please see the current ON source base
41: 
42: === OpenSolaris Deep C-State Support
43: 
44:  Modern x86 processors support several different idle states for power conservation. ACPI defines these as C-states. Solaris as of onnv_102 supports only ACPI C1 via the HLT (halt) and MONITOR/MWAIT instructions. Deeper ACPI C-states C2 and C3 can conserve more power, but they can take longer to enter and resume. The ACPI specification allows CPU internal clock state to halt during C2, and caches may loose state in ACPI C3. Operating system support is required because of possible CPU state loss in C2 and C3 and because of the additional idle wakeup latency.
45: 
46:  There is currently OpenSolaris Deep C-state work ongoing in several areas:
47: 
48: * **cpudrv** The existing cpudrv is being modified to support Deep C-states. The cpudrv is being modified to:
49: ** detect processors which support deep C-states
50: ** query ACPI properties
51: ** implement idle loops to enter deep C-states via ACPI methods.
52: * **kernel** General kernel work to support Deep C-states
53: ** support different CPU wakeup mechanisms for CPUs in different idle states.
54: ** Read timers such as the local APIC and expire times such as for the top cyclic on a CPU’s cyclic heap
55: ** Scheduler improvements to choose CPUs based on idle states.
56: ** support Real Time (RT) thread scheduling time requirements on CPUs with variable wakeup latencies
57: * **HPET** Solaris uses the local APIC timer to generate interrupts for the Cyclic Backend (CBE). The lAPIC timer in a CPU may stop counting and will not generate interrupts while the processor is in ACPI states C2 and C3. Ongoing work is being done to use the High Precision Event Timer (HPET) as a proxy for stalled lAPIC timers. The HPET is located on the chipset isolated from CPU C-State power side effects. CPU must schedule their next CBE interrupt on the HPET when they enter a deep C-state.
58: 
59: ==== Status
60: 
61:  Deep C-states support integrated (along with PAD) into Nevada build 110 on Wednesday Feb 25th, 2009. For more information, please see the [[Flag Day and Heads Up announcement>>Community Group on.2009022501]].
62: 
63: ====  Bugs/RFE CR numbers
64: 
65: * [[6700904>>http://bugs.opensolaris.org/view_bug.do?bug_id=6700904]] deeper C-State support required on follow-ons to Intel Penryn processor generation microarchitecture
66: * [[C-State Development bugs>>http://defect.opensolaris.org/bz/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=power-mgmt&component=c-state&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ACCEPTED&bug_status=CAUSEKNOWN&bug_status=FIXUNDERSTOOD&bug_status=FIXINPROGRESS&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]]
67: 
68: ==== Deep C-State HPET Source Repository
69: 
70:  C-State work has merged with Power Aware Dispatcher work. Please see pad-gate above.
71:  HPET and C-State work was developed in separate gates to maintain quality of other gates. **These gates are no longer active.**
72: 
73: ==  Mercurial Repositories
74: 
75:  Please read [[these instructions>>Community Group tools.hg_help]] on how to use Mercurial repositories. For help with using Mercurial, or the ON tools, you can also:
76: 
77: * Ask on the [[tools-discuss@opensolaris.org>>http://www.opensolaris.org/jive/forum.jspa?forumID=9]] mailing list ([[subscribe here>>mailto:tools-discuss-subscribe@opensolaris.org]]).
78: * You can also check out the Mercurial [[how-to page>>Community Group tools.hg_help]].
79: 
80: * To make a (debug) kernel (using **pad-gate** as an example workspace, and **opensolaris.sh** as the environment file)
81: 
82: {{{
83:     $ cd pad-gate
84:     $ /opt/onbld/bin/bldenv -d /opt/onbld/bin/opensolaris.sh 
85:     $ cd usr/src/tools
86:     $ dmake install
87:     $ cd $CODEMGR_WS/usr/src/uts
88:     $ dmake install
89: }}}
90: 
91: * To create a kernel tarball to install (x86)...
92: 
93: {{{
94:     $ /opt/onbld/bin/Install -G my_pad-gate_kernel -k i86pc
95: }}}
96: 
97: * To build BFU archives, you need to get (and extract) the "closed bins" tarball(s) into your workspace. See above for current pointers (you must use versions appropriate for the build of onnv against which your repo is synced).
98: 
99: {{{
100:     $ cd pad-gate
101:     $ tar xf on-closed-bins.i386.tar
102:     $ /opt/onbld/bin/nightly /opt/onbld/bin/opensolaris.sh
103: }}}
104: 
105: * See the [[OpenSolaris Developer’s Reference>>Community Group on.devref_toc]] for details on how to use kernel tarballs generated by Install(1).
OpenSolaris

Top Menu

Wiki code for CPU Power Management

Search

Collectives

Community Group

Project

User Group

Subsites

Project tesla Pages
