Bill Holler wrote: > Hi Tesla-dev, > > Here is a proposed PSARC self review. Please send > feedback. We plan to submit this as soon as possible. > All of its content has already been discussed here. > > I filled out most all of the onepager template. Please > let me know if this should be cut down to a smaller > subset. > > Thank you, > Bill > > > > Copyright 2008 Sun Microsystems > > 1. Introduction > 1.1. Project/Component Working Name: Deep C-States > > 1.2. Name of Document Author/Supplier: Bill Holler > > 1.3. Date of This Document: 09/18/2008 > > 1.4. Name of Major Document Customer(s)/Consumer(s): PSARC > > 1.5. Email Aliases: > 1.5.1. Responsible Manager: darrin.johnson at sun.com > 1.5.2. Responsible Engineer: bill.holler at sun.com > 1.5.4. Interest List: tesla-dev at opensolaris.org > > 2. Project Summary > 2.1. Project Description: > Solaris support for ACPI processor C-States beyond C1. > Enhanced power savings idle loop. > > 2.2. Risks and Assumptions: > As with most power saving features this change may introduce > a small performance regression for the sake of saving power. > > 3. Business Summary > 3.1. Problem Area: > Reduce power consumption of computer systems. > Idle CPUs use the same amount of power as working CPUs without > power saving features. Solaris currently supports processor > halting (ACPI C1) which can reduce power consumption about 30% > on idle CPUs. Next generation Intel server processors will > support ACPI C-States beyond C1. Solaris can save more power > on under-utilized systems by using these C-States. > > 3.3. Business Justification: > Feature will save customers power and colling costs. > "cooling"
> 3.4. Competitive Analysis: > Solaris has the opportunity to be a stand out power/performance > leader with to its advanced support for processor groups, diverse > system topologies, and hardware utilization. > > 3.5. Opportunity Window/Exposure: > Now. > > 3.6. How will you know when you are done?: > CPUs on completely idle system will spend the majority of their > time (> 50%) in a Deep C-State if not interrupted. > Overall power consumption of the system will be less. > Total power savings will be greater than any reduction in maximum > performance (if there is any maximum performance reduction). > > 4. Technical Description: > 4.1. Details: > Solaris will support the ACPI mechanism for entering Deep C-State > on idle processors. The HPET (High Performance Event Timer) on the > chipset will be used to wake up CPUs from Deep C-States if their > Local APIC Timer cannot wake them up. > > This project is an OpenSolaris project done with community > contributions. > > Systems without invariant TSC (Time Stamp Counter) will not > initially support Deep C-States. > > 4.2. Bug/RFE Number(s): 6700904 > > 4.4. Out of Scope: > Deep C-State will not be supported on legacy processors which > do not have a stable TSC. This may be done in the future by > a new project or by members of the OpenSolaris community. > > 4.5. Interfaces: > This project will import these existing interfaces. > Interface stability will be "committed". > Import: > power.conf(4) (PSARC/1992/202) > pmconfig(1m) > > cpu_deep_idle keyword. > Some systems may wish to disable Deep C-States due to unavoidable > increased idle CPU wakeup latency. A cpu_deep_idle entry will be > added to power.conf(4) to disable Deep C-States. If this entry is > set to default or is not present then the default Deep C-State > support will be used. The default behavior will enable > Deep C-States on all X86 systems which have an invariant TSC and > the ability to wake the processors from Deep C-State. > The disable option will disable this feature. > > > power.conf(4) man page addition: > > If supported by the platform, a cpu_deep_idle entry may be used > to enable or disable automatic use of power saving cpu idle states. > > The format of the cpu_deep_idle entry is cpu_deep_idle behavior. > > Acceptable behavior values are: > > default Advanced cpu idle power saving features will be > enabled on hardware which supports it. On X86 systems > this may translate to the use of ACPI C-States beyond C1. > > enable Enables the system to automatically use idle cpu power > saving features. > > disable The system does not automatically use idle cpu power > saving features. This option may be used when maximum > performance is required at the expense of power. > This keyword is a bit of a departure from the other keywords in power.conf(4). All of the other keywords deal with either suspend/resume or with how the power management framework is going to manage a device. I just point this out as I'm afraid that it might be a little confusing to users. That said, I don't have a good alternative suggestion. > > 4.6. Doc Impact: > power.conf man page. See above. > > 4.7. Admin/Config Impact: > Administrators of systems where maximum performance is more > important than power/performance can disable this feature. > It is not anticipated than many customers will choose to disable > this feature as it provides improved power/performance. > > 4.8. HA Impact: None. > > 4.9. I18N/L10N Impact: No. > > 4.10. Packaging & Delivery: > 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/ > > IA-PC HPET (High Precision Event Timers) Specification: > http://www.intel.com/hardwaredesign/hpetspec_1.pdf > > 6. Resources and Schedule: > 6.1. Projected Availability: Fall 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_103 and S10U8 > 6.4.8. Target Code Design Review Date: 09/22/2008 > 6.4.9. Update approval addition: No. > > 6.5. ARC review type: SelfReview > > 7. Prototype Availability: > 7.1. Prototype Availability: > Prototype available on OpenSolaris in August 2008. > > _______________________________________________ > tesla-dev mailing list > tesla-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/tesla-dev >
