From randyf@sac.sfbay.sun.com Thu Dec 18 12:39:40 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBIKdeW5011039 for ; Thu, 18 Dec 2008 12:39:40 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBIKdYuj006026; Thu, 18 Dec 2008 13:39:40 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KC300B1TAQ3CG00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 18 Dec 2008 12:39:39 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KC300B7KAQ27R00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 18 Dec 2008 12:39:38 -0800 (PST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBIKdcw1043270; Thu, 18 Dec 2008 12:39:38 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBIKdbu8011034; Thu, 18 Dec 2008 12:39:37 -0800 (PST) Received: (from randyf@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id mBIKdbrF011030; Thu, 18 Dec 2008 12:39:37 -0800 (PST) Date: Thu, 18 Dec 2008 12:39:37 -0800 (PST) From: Randy Fishel Subject: cpupm keyword mode extensions [PSARC/2008/777 Self Review] To: PSARC-ext@sun.com Cc: eric.saxe@sun.com, tesla-dev@opensolaris.org Message-id: <200812182039.mBIKdbrF011030@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 10471 I am sponsoring this case on behalf of Eric Saxe. The release binding is patch/micro. We believe that this is a self review, but can be changed to a regular fasttrack should someone request. Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: cpupm keyword mode extensions 1.2. Name of Document Author/Supplier: Author: Eric Saxe 1.3 Date of This Document: 18 December, 2008 4. Technical Description Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: cpupm keyword mode extensions 1.2. Name of Document Author/Supplier: Eric Saxe 1.3. Date of This Document: 12/1/2008 1.4. Name of Major Document Customer(s)/Consumer(s): PSARC 1.5. Email Aliases: 1.5.1. Responsible Manager: darrin.johnson@sun.com 1.5.2. Responsible Engineer: eric.saxe@sun.com 1.5.4. Interest List: tesla-dev@opensolaris.org 2. Project Summary 2.1. Project Description: The Power Aware Dispatcher Project seeks to provide an event based CPU power management architecture, where CPU power state changes (Frequency/Voltage scaling) are triggered by changes in processor utilization tracked by the dispatcher's broader efforts to optimize thread placement across Chip Multi-Threading and NUMA system architectures. As part of this effort, the project seeks to extend the cpupm keyword documented in power.conf(4), to support an optional "mode" enabling customers to explicitly choose event based or polling based CPU power management. 2.2. Risks and Assumptions: It is anticipated that the vast majority of customers won't want or need to explicitly specify polling vs. event mode behavior, in which case the system will default to one or another. 3. Business Summary 3.1. Problem Area: This proposal describes extensions to an interface supported by power.conf(4) used in configuring the system's CPU power management behavior, which in turn relates to the power efficiency of [Open]Solaris based systems. 3.3. Business Justification: Allowing customers to express preference for event based vs polling based CPUPM provides a way to fall back on the existing polling implementation...should cases arise where polling based CPUPM is preferred or where polling based CPUPM best meets the customers power/performance objectives. 3.4. Competitive Analysis: It is believe that an event based, dispatcher driven/assisted CPUPM architecture will drive improved power/performance in [Open]Solaris. A patch is available for Linux that provides for scheduler aware CPU power management. See: http://lesswatts.org/tips/cpu.php#smpsched 3.5. Opportunity Window/Exposure: Now. 3.6. How will you know when you are done?: When the work described in this proposal is complete, and integrated into the release. 4. Technical Description: 4.1. Details: pmconfig(1M) parses and interprets /etc/power.conf, and configures the system's power management features via ioctl(2)s to the pm kernel module. Where the cpupm keyword is encountered, the driver's pm_ioctl() interface configures the system's CPU power management features. As documented in power.conf(4): | A cpupm entry may be used to enable or disable Power Manage- | ment of CPUs on a system-wide basis, independent of autopm. | The format of the cpupm entry is: | | cpupm behavior | | Current acceptable behavior values and their meanings are : | | enable CPU Power Management will be started when this | entry is encountered. | | | disable CPU Power Management will be stopped when this | entry is encountered. This work will allow cpupm to take an additional optional argument "mode" when the enable behavior is specified: cpupm enable [mode] where "mode" is one of: event-mode CPU power state transitions will be driven by thread scheduler/dispatcher events. The cpu-threshold, and system-threshold directives are not used for CPUs when operating in event-mode. poll-mode The Power Management framework will poll the idleness of the system's CPUs, and will manage their power once idle for the period of time specified by either the system-threshold or cpu-threshold. Where the "enable" behavior is specified without a "mode" argument, CPU Power Management will be enabled and the system will default to using one of the modes. Some existing keywords supported by power.conf(4) assume a polling based CPU power management architecture. cpu-threshold is one example: | If a system has power manageable CPUs, these may be managed | independently of the system idleness threshold by using one | of the following entries: | | cpu-threshold threshold | | | cpu-threshold always-on | | where threshold is the value of the CPU idleness threshold | in hours, minutes or seconds as indicated by a trailing h, m | or s (defaulting to seconds if only a number is given). If | always-on is specified, then by default, all CPUs will be | left at full power. This work provides an opportunity for us to document in power.conf(4) the availability of the event based architecture, contrast it against the polling based architecture, and indicate that where event based architecture is used, the time based cpu-threshold keyword won't be relevant if expressed. 4.2. Bug/RFE Number(s): 6567156 4.4. Out of Scope: The broader "power aware dispatcher" RFE (6567156) is outside the scope of this proposal, which captures only the power.conf(4) interface changes. 4.5. Interfaces: This project will import these existing interfaces. Interface stability will be "committed". Import: power.conf(4) (PSARC/1992/202) pmconfig(1m) (PSARC/1992/202) Export: "mode" argument for the "cpupm enable" keyword/behavior power.conf(4) man page addition under section describing cpupm keyword behaviors: | Where the behavior is "enable", an optional "mode" argument may be | specified: | | cpupm enable mode | | Acceptable mode values and their meanings are: | | event-mode CPU power state transitions will be driven by thread | scheduler/dispatcher events. The cpu-threshold, and | system-threshold keywords are not used for CPUs in | this mode. | | poll-mode The Power Management framework will poll the idleness | of the system's CPUs, and will manage their power | once idle for the period of time specified by either | the system-threshold or cpu-threshold. power.conf(4) man page addition under section for the cpu-threshold keyword: | The cpu-threshold keyword is used only when CPU Power Management has | been configured to operate in poll-mode, which is expressed through | the cpupm keyword. power.conf(4) man page addition under section for the system-threshold keyword: | The system-threshold is applicable to CPU Power Management only when | CPU Power Management has been configured to operate in poll-mode, | which is expressed through the cpupm keyword. +========================================================================+ |Release Binding: Patch/Micro | | | |Imports: | | | |Name Case Classification | |------------------------------------------------------------------------| |power.conf(4) PSARC/1992/202 Committed | |pmconfig(1m) PSARC/1992/202 Committed | | | | | |Exports: | | | |Name Classification Comments | |------------------------------------------------------------------------| |Optional "mode" argument for "cpupm enable": | |poll-mode Committed Polling based CPU power management | |event-mode Committed Dispatcher / Event based CPUPM | +========================================================================+ 4.6. Doc Impact: power.conf man page. See above. 4.7. Admin/Config Impact: It is the intention of this propsoal to be consistent with the "principle of least surprise". That is, existing power.conf(4) configuration files will continue to work, and the system's power/performance characteristics will transparently improve. Where administrators would wish to fallback on the existing CPUPM mechanism, and continue to use the time based CPU utilization thresholds supported by power.conf, poll-mode will provide this. 4.8. HA Impact: None. 4.9. I18N/L10N Impact: No. 4.10. Packaging & Delivery: This change will be delivered as part of the Power Aware Dispatcher RFE. These changes will be made at the same time: kernel package cpudrv package power.conf package pmconfig package 4.11. Security Impact: None. 4.12. Dependencies: power.conf, pmconfig(1M) 5. Reference Documents: Advanced Configuration and Power Interface: http://www.acpi.info/ 6. Resources and Schedule: 6.1. Projected Availability: Winter 2008 6.4. Product Approval Committee requested information: 6.4.3. Type of CPT Review and Approval expected: BugFix 6.4.5. Is this a necessary project for OEM agreements: Yes. A deliverable of the Intel/SUN master collaboration agreement. 6.4.7. Target RTI Date/Release: RTI around onnv_106 and S10U8 6.4.8. Target Code Design Review Date: 10/10/2008 6.4.9. Update approval addition: No. 6.5. ARC review type: SelfReview 7. Prototype Availability: 7.1. Prototype Availability: Prototype has been available via OpenSolaris since October 2008. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic 6.6. ARC Exposure: open