On Friday, July 27, 2007 2:45 PM, tesla-dev-bounces at opensolaris.org
wrote:

> Thanks to Darrin for those notes from today's meeting...
> 
> Attendees
> ---------
> Darrin Johnson
> Terry Whatley
> Sridhar
> Wilson Chi
> Glenn Rysko
> Wilson Chi
> Mark Haywood
> Eric Saxe
> Jonathan Chew
> Phil Edge
> Michelle Le
> Bart Smaalders
> Randy Fishel
> Joe Bonesera
> Rafael Vanoni
> 
> Discussion Notes
> ---------------------
> 
> Mark Haywood putback Intel SpeedStep into NV Build 70
>  - P-state support putback for Intel processors that are    P-state
> TSC Invariant 
>  - Fits into current Solaris power management framework
>    - Drivers supposed to let framework know when they are      busy
> or idle 
>    - Framework then asks devices to power up or down      accordingly
>    - Up to the framework to initiate transitiosn
>    - Okay if you don't need to do it often...current
>      framework only does it every 15 seconds
>    - 15 seconds is far to long for CPU power management
> 
> Is the focus of Tesla to look at only longterm issues or does it also
> include short-term (e.g. tactical fixes)?
>    - Short answer is we want to do both
>    - For example migrate subsystems to be power aware
>    - Also migrate to event based rather than poll based
>    - Driver model good for even notification
> 
> Thoughts on what other short term things could be done
>    - Lower threshold for framework for CPUs
>    - Threshold is currently hard coded (should be definable)
>        - Use system/user as defined by microstate accounting
>    - Important to reduce power step-wise
>    - Could value be set in power.conf? .... Yes, and would      be
> easy to add. 
> 
> How would this work on LDOMs/virtualization?
>    - Where is the observability?
>    - Where should be the control?
>    - Xen currently only runs full out
>      - Problem especially with fractional CPUs
>    - Who ever manages the hardware should take the actions
> 
> Need to figure out how power management works with virtualization....
>    - How we do it on raw iron will help determine what virtualized
>      environments will experience
> 
> Time Stamp Counter (TSC)
>    - Changing frequency of CPU can change TSC causing artifacts
>      (eg. time going backwards)
>    - This occurs on some legacy hardware such that multi socket
>      systems can't be supported
>    - Need a solution to deal with the "variant" TSC on MP and     
> multi-socket 
>    - Can solve for UP/US and possibly MP/US but will not fix     
> problem for MP/MS. 
> 
> Suspend/Resume
>    - UP is working well
>    - MP issues are getting worked out well
>    - Still need to enhance some drivers to support
>      ddi_suspend and ddi_resume
>    - Getting UP putback will help with the driver
>      compliance work
>    - Tesla Community can be the central clearly house
>      for information, although could investigate
>      "suspend / resume compliant driver OpenSolaris project"
> 
> Tickless Clock
>    - Protoype is started but a lot of groundwork needs to be done
>    - Looking on what is hanging off the clock thread
>    - What can be moved to be event based
>    - Prototype event based call out mechanism
>      - Omnicyclic implements per CPU callout
>      - Need to see about implementing tick accounting
>         using new callout scheme
>    - Cyclics currently heavily uses CPU lock
>      which is a challenge to overcome
>    - Strategy is also to get the system out of the way
>      as well as getting applications (e.g. Xserver, etc.)
>      to get out of the way (e.g. go from polling to event      based)
>    - We should see how linux is doing this and leverage      the work
> 
> Requirements Document
>    - Want create a wishlist of what needs to happen
> 
> Misc
>    - Need to look at policies
>    - Need to enable power management by default even for servers
>      with well defined default policy

Thanks for the notes. It's regret I missed the meeting.

For P-state driver, I have one suggestion. There are still some old
machines which support early ACPI specs but not support P-state.
We should not ignore this kind of machine. So IMHO P-state driver should
check the version of ACPI and doesn't make unnecessary warning.

Another thing is ACPICA, I didn't dig into too much, but found the
version in the solaris is some different from the one on intel website.
How often does it sync-up with Intel ACPI CA releases?

Thanks,
-Aubrey 

Reply via email to