Terry, I am all for changing it to a fasttrack if you can enumerate the benefit of doing so.
I do agree there is a need for a PM umbrella case but that is outside the scope of the project. Darrin Terry (Sarito) Whatley wrote: > 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 >> >> > > Sorry to be a pain, but I disagree that this qualifies for self review. > For self-review, > IIRC, it needs to not introduce any new interfaces, which this does. > This should be a fast-track. > I think you need to list the new keyword as an exported interface. > Do you plan to populate power.conf with this keyword, or only to support > it if it shows up. > I strongly recommend the latter. > Is there any plan to support setting this any other way besides editing > power.conf? > This case is another argument for having the PM umbrella case. > > thanks, > sarito >> 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. >> >> 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. >> >> >> 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 >> > > _______________________________________________ > tesla-dev mailing list > tesla-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/tesla-dev -- Darrin P. Johnson Sr. Manager, SW Engineering Solaris Core Kernel Group Blog: http://blogs.sun.com/darrin Email: darrin.johnson at sun.com Direct: (650) 786-2395 Cell: (408) 916-7322
