Reduce costs using new power efficiencies in Windows Server 8

1. SAC-661T Reduce costs using new power efficiencies in Windows Server 8 Sean McGrane – Program Manager Lead Bruce Worthington – Development Lead Microsoft Corporation

2. Agenda slide WHO WILL BENEFIT FROM THIS TALK TOPICS WHAT YOU’LL LEAVE WITH • Understanding of new power efficiency capabilities in Windows Server 8 • Understanding of how to enable these capabilities on server platforms • Understanding of how to diagnose problems and tune for optimal power management on your servers • Introduction to power management in Windows Server • The new collaborative power management model • Managing power usage in the memory subsystem • Tuning and developing for power management • Server Manufacturers • Server Administrators • Software Developers (particularly management software) • Data Center hardware decision makers

3. Introduction

4. Power and Cooling in Data Centers • Power and cooling continues to be a top of mind issue in data centers • Costs of cooling infrastructure and power usage continue to increase • Carbon Emission levels are being more scrutinized • Must make best use of existing power and cooling infrastructure • Data Center designs are changing • More emphasis is placed on building for optimal cost of operation • The power footprint of the servers used can be a critical component to cost of operation • Increasing power efficiency and improving power management continue to be important goals for Window Server

5. Measuring Power Efficiency Improvements Lower is better Representative OLTP Workload

6. Windows Power Management History Windows Server 8 Focus on Power Efficiency Focus on performance • Windows Server 2008 and R2 • Power Efficiency • Focus on processor power management • Manage performance states based on utilization • Park cores during low utilization • Remote Management • Discover power meter and budget capabilities • Remote power management interface

7. Collaborative Power Management

8. Windows Processor P-State Management • Introduced in Windows Server 2003 SP1 • Enabled by default in Windows Server 2008 • Operation - • Firmware provides a description of the available performance states (P-states) to Windows via ACPI • Windows calculates the performance needed by each Logical Processor (LP) for the next performance check interval • Windows selects a P-state that can provide the necessary performance • Windows writes to the hardware to program the desired P-state for each LP • This continues to be supported in Windows Server 8

9. Collaborative Power Management • Power can be managed by both Hardware and Software • In some cases both provide power policies to customers • Policies are typically exclusive • A collaborative model is a better approach • Hardware and Software work together • Both can innovate and differentiate • Goal is to optimize power efficiency for the platform • Microsoft provided a collaborative power management capability in Server 2008 R2 • This was created in partnership with HP

10. Collaborative Model • A low latency communication transport is used to pass information between the Software and Hardware • A standards-based firmware interface is used • Microsoft is working with the Advanced Configuration and Power Interface (ACPI) forum to define this interface • Processor performance information is passed on the transport • The transport can be used for other purposes • Memory Power Management is another usage model

11. Collaborative Processor Power Management Operation 1. Windows detects the ACPI interface during boot and the platform detects that Windows supports collaborative power management 2. Windows calculates the desired performance for each LP for the next performance check interval 3. Windows sends the desired performance to the platform using the new ACPI interface ACPI Interface 4. The hardware platform receives a notification and reads the desired performance from the ACPI interface 5. The hardware platform manages the power controls on the hardware components to deliver the requested performance 6. The Hardware platform sends the delivered performance for the performance check interval back to Windows using the ACPI interface

12. Power Budgets • Many modern servers provide a power budget solution • The administrator can set a power budget for the server • The hardware platform controls the power budget • Receives the power budget value • Monitors power usage • Reduces power usage on the system when required to stay within the budget • Windows can help the platform stay within the budget

13. Collaborative Power Budgeting(Logical Processor Idling) P0 • Goal: Improve efficiency when Windows Server is under a platform-controlled power budget by allowing firmware to participate in Windows core parking • How: Support the ACPI 4.0 Processor Aggregator device and Logical Processor Idling (_PUR; _OST) • Details: • Firmware requests a certain number of logical processors using _PUR • OS checks to see if the platform has been capped to the lowest CPU power state (Pn) • OS parks the number of cores requested by the platform using the Windows Core Parking algorithm 2 cores parked Pn Power T0 n cores parked Higher performance at same power level Tn Performance PAGE 13 9/15/2011

14. Benefits of Collaborative Power Management • Simplifies the power policy choice for the customer • Both Hardware and Software contribute to the system power efficiency • Windows does what it does best by providing desired performance information in an abstract form • Hardware does what it does best by managing power controls on various hardware components to deliver the desired performance • Hardware can deliver less than the desired performance if a power cap is in place and report this to Windows • Enables innovation and differentiation in Windows Server and in the hardware platform

15. Memory Power Management

16. Motivation • Previous Windows releases targeted processor power reductions • Memory power can exceed processor power in servers at low utilization levels • When idle, memory can autonomously be dropped into low power states • OS hints to the hardware available in future platforms • The Windows 8 Memory Cooling feature maximizes memory idle time while minimizing any performance impacts

17. Performance-Related Goals • Ideally, memory cooling would be enabled by default • Requires an acceptable tradeoff between perf and power • Improve energy efficiency (power savings >> perf hit) • Unnoticeable perf impact on systems that don’t have memory power management enabled or are configured to favor perf • <1% increase in memory footprint • Dynamic back-off mechanisms for workloads that don’t lend themselves to memory cooling

18. Power-Aware Memory Management • Idle regions of memory can be put into low power states – e.g., Self Refresh (SR) modes • Requires that resulting exit latencies can be tolerated for low frequency accesses • There are two areas of power-aware Memory Management functionality: • Allocation – allocate physical memory in a fashion that facilitates the creation of idle regions • Relocation – dynamically relocate physical memory to create ‘hot’ and ‘cold’ memory regions

19. Power Region Granularities • Cooling decisions are made within a NUMA node, not across NUMA nodes (in Windows 8 Server) • Requires multiple power regions to be exposed under a NUMA node • Memory channel is a typical power region target • Most of the power savings for current and next generation server platforms is obtained by putting full memory channels into SR (vs. other granularities such as banks, ranks, or DIMMs) • Future server generations may have different power regions or different power states that are used for memory cooling

20. Example: Memory Power Regions CPU 0 CPU 1 DDR3 CHNL DDR3 CHNL Memory Power Region 4 Memory Power Region 0 DDR3 CHNL DDR3 CHNL Memory Power Region 5 Memory Power Region 1 DDR3 CHNL DDR3 CHNL Memory Power Region 6 Memory Power Region 2 N0: 0x0 – 0x160000000 N1: 0x160000000 – 0x260000000 N2: 0x260000000 – 0x360000000 N3: 0x360000000 – 0x460000000 N4: 0x460000000 – 0x560000000 N5: 0x560000000 – 0x660000000

21. Platform Enablement • The physical memory topology of the system is provided to the operating system by the platform • A standards-based firmware interface is used • Microsoft is working with the ACPI forum to define this interface • The firmware interface describes – • Power regions on the memory sub-system • Physical addressing for each power region • Available memory power states • The interface will also provide hardware controls

22. Memory Cooling Implementation • Memory cooling leverages existing Windows mechanisms • Memory page access and mapping information drives cooling: • Choosing power regions for new page allocations • Choosing specific physical pages to relocate between power regions • Providing hardware hints • Backing off or reducing memory cooling activities

23. Page and Power Region ‘Heat’ • Pages are roughly categorized as HOT or COLD based on access rates and historical patterns • Some pages may be categorized as HOT because of their contents. E.G.: • Non-Paged Pool pages: can’t be moved once they are allocated • Kernel Stack pages: difficult to track ‘heat’ of pages • Power regions are similarly HOT or COLD based on the pages they contain • Some regions may be categorized as HOT because they contain pages that cannot be moved (and are therefore always HOT) • Primary goal: move HOT pages away from COLD power regions

24. Memory Cooling Relocation Unmovable Page NUMA Node Hot Page Power Region 0 Power Region 1 Cold Page Pinned/Hot Region Cold Region

25. Memory Cooling Relocation When pages turn cold after minutes of no accesses, and only one hot channel is needed … Unmovable Page NUMA Node Hot Page Power Region 0 Power Region 1 Cold Page Pinned/Hot Region Cold Region

26. Memory Bandwidth Load Decreases PwrReg 0 PwrReg 1 PwrReg 2 PwrReg 3 PwrReg 4 PwrReg 5 PwrReg 6 PwrReg 7 Cooling Starts 2 Hot Power Regions 6 Cold Power Regions

27. Watts

28. Scenarios with Limited Cooling Benefits • Memory bandwidth bottlenecked • Memory interleaving must be turned off across power regions (but not within power regions) to enable memory cooling • Random memory accesses across the majority of physical pages • No clear partitioning of HOT and COLD pages • Continuous repurposing of different pages • Page access history is less accurate • Programming suggestion: Using LIFO instead of FIFO policies for app-managed memory pools • Memory cooling monitors its efficiency and will back off to minimize any performance impact under these scenarios

29. Memory Cooling Summary • Memory power represents a promising source of energy savings for many servers with low utilization levels or diurnal/weekly usage patterns • Windows Server 8 works with hardware to drop large regions of physical memory into deep low power states for appropriate workloads • Predicted power savings have been achieved on multiple server workloads and platforms • Microsoft is working with server and CPU partners to validate and fine-tune Memory Cooling

30. Application Best Practices

31. Hygiene • Goal: Don’t wake CPUs (or other components) out of low power states unless there is useful work to be done • Windows Server 8 vs. Windows Server 2008 R2 • Core-OS periodic timers increased from as low as 15.6 ms to 1+ sec • Major improvement in CPU idle residency, with the important caveat of skew by legacy drivers/hardware and noisy apps • A single frequent timer can have serious impacts on idle power • Power efficiency diagnostic tools • powercfg –energy (ships in Windows) • xperf –? energydiag (ships in the Windows Performance Toolkit and Windows 8 ADK)

32. Best Practices • Avoid periodic CPU activity • Polling, spinning, idle loops, timer wheels • Use event-driven designs instead • Use Coalescable timers with periodicity >= 1 second (preferably multi-second) for any remaining timers • SetCoalescableTimer(), SetWaitableTimerEx(), KeSetCoalescableTimer(), Create/SetThreadpoolTimer() • Avoid periodic Disk or Network activity • Optimize code for performance/path length • Do not adjust system timer resolution (i.e., use default)

33. Session Callout • Collaborative Power Management • Consider enabling your platforms for Collaborative Power Management • Review the new ACPI firmware interface, when available • Consider enabling Logical Processor Idling on your platforms • Memory Power Management • Consider enabling your platforms for Memory Cooling • Review the new ACPI firmware interface, when available • Best Practices: Event driven design • Avoid coding practices that will increase power usage • Idle == Quiet, Quiet, Quiet!!!

34. More information RELATED SESSIONS DOCUMENTATION & ARTICLES Server Power Considerations for IT Administrators http://msdn.microsoft.com/en-us/windows/hardware/gg463263.aspx Performance Tuning Guidelines for Windows Server 2008 R2 http://msdn.microsoft.com/en-us/windows/hardware/gg463392.aspx Energy Savings from Energy Star-Qualified Servers http://www.energystar.gov/index.cfm?fuseaction=find_a_product.showProductGroup&pgw_code=DC Power Meter and Budget Interface http://msdn.microsoft.com/en-us/library/ff543910(v=VS.85).aspx HW-459T: Delivering great performance and battery life HW-251T: Introducing low-power buses for Windows 8

35. thank you Feedback and questions http://forums.dev.windows.com Session feedbackhttp://bldw.in/SessionFeedback

36. © 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.