It's about Enable/Disable of a simple RFE - Deep C-States. darrin
Randy Fishel wrote: > > On Thu, 18 Sep 2008, 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 >> > > I may (or may not) have been hasty on a previous comment. > > Is this ARC proposal about implementing Deep C-States, or is it > about how to enable/disable the features of a simple RFE? > > (original comments kept as they may well be relevant either way) > >> >> 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. > > I think that this description is wrong. Though there is an RFE to > support Deep C-States, *this* proposal is about an interface that will > allow a user to enable/disable the feature. > > However, I may have missunderstood what this is about. Are there > interfaces with the implementation of Deep C-States that should be > presented for review? > > >> 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. > > Need to add a description as to how the keyword in power.conf will > change the behavior, and when/why it should be used. > >> 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. > > This makes me think that there is more to this proposal, and might > require further discussion. > >> 4.5. Interfaces: > > These are usually best as a table, especially for a self review, as > most readers will gravitate directly to the table for review, and > bypass the text. > > >> 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. > > This would be an export. > >> 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. > > Hmm, Terry might well be right about status. Are there TSC/HPET > interfaces here that need to be described (either imports or exports)? > How does this case, or an adminstrator know if the TSC is invariant > (further imports/exports)? > >> 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 -- 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
