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
>   


Reply via email to