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. >
