Please see inline. On 09/19/08 15:00, 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 >
Deep C-States is a hardware feature that enhances existing x86 processor halting capabilities. Solaris support of Deep C-States is an RFE to the existing cpu idle loop. > about how to enable/disable the features of a simple RFE? > This ARC proposal is only about how to disable/enable using this feature. > (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. > Yes, the description is wrong. It will be changed to state this proposal is only about the interface to disable/enable this 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? > No. Deep C-State support implementation has been done in the open in an OpenSolaris community. The community already continuously reviewed the implementation as it evolved in the open. >> 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. > This sentence is misleading. A description will be added stating this power.conf keyword will not cause the Deep C-State feature to be enabled on systems which cannot support it. The keyword will only have an effect on systems which already support the feature. >> 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.4 is confusing because it relates to the scope of the RFE, not this proposal which just enables/disables the RFE. This will be changed. Perhaps 4.4 should list the RFE itself as being out of scope of this proposal? >> 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. > Ok. >> 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. > Yes. This was changed to exported as per Sarito's earlier comment. >> 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)? > None of the hardware implementation details will be exposed to administrators. Hardware power saving features are changing too rapidly that any hardware details may be useless to administrators on the next revision of hardware. This keyword is kept as implementation-free as possible. The majority of administrators will not want to set this keyword. Only a small percentage of administrators who need the very last performance from systems without regard for power consumption will set this keyword to disable. The existing powertop utility will show an administrator that the system is using C-States. Regards, Bill Holler >> 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 >
