1. Voltage Emergency Prediction: Using Signatures to Reduce Operating Margins V.J. Reddi, M.S. Gupta, G. Holloway, G. Wei, M.D. Smith, D. Brooks Presented by: Kelsey Rosenthal and Irving Olmedo

2. Motivation ● Current fluctuations cause voltage problems ● Conservative voltage margins (~20%) ● Wasted energy ● Unused performance potential

3. ● Voltage emergencies ● Overly conservatively margins ● Sensor based throttling Targeted Problem Sensor based throttling

4. Solution Goals ● Avoid voltage emergencies ● Operate within aggressive margins (~4%) ● Rollback on timing violations

5. CPU Actuator Checkpoint-Recovery Proposed Solution: Predictor ● Monitor events ● Predict emergencies ● Throttle to avoid ● Recover if mistaken Monitor Control Flow and Microarchitectural Events Predictor Throttle On / Off Emergency Notification

6. Runtime Example Emergenc y Voltage Current Flush ALU Cache Issue Dispatch Commit 2 1 3 4 1 11 1 4 4 44

7. Voltage Signatures ● Recurring phases ● Locality ● Context of system ● uArch events (on/off) ● Control flow

8. Predictor Accuracy Tradeoff ● Types of events ● Number of events ● Space constraints ● PC anchor

9. Emergency Avoidance ● Non-zero delay throttling ● Misprediction ● Sensor based learning

10. Prediction Table Storage ●CAM ●Bloom Filter ●Thresholds

11. Predictor Accuracy

12. How does it stack up SchemePerformance Gain (%) Predictor Throttling Oracle14.2 Voltage Emergency Signature (VES)13.5 VES with 8KB Table11.1 Microarchitectural Event4.1 Ideal Sensor Throttling 2% Soft Threshold2.2 3% Soft Threshold9 Explicit Checkpoint and Recovery-13 Delayed Commit and Rollback (DeCoR)13

13. Conclusion ● uArch events create voltage signatures ● Predict emergencies with >90% confidence ● 11-13% performance improvement ● Aggressive voltage margins (4%)

14. Discussion ● How does this compare/differ from Razor? ● Is an 8KB CAM reasonable for this improvement? ● How relevant is this to a multithreaded/multicore system?