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
Motivation ● Current fluctuations cause voltage problems ● Conservative voltage margins (~20%) ● Wasted energy ● Unused performance potential
● Voltage emergencies ● Overly conservatively margins ● Sensor based throttling Targeted Problem Sensor based throttling
Solution Goals ● Avoid voltage emergencies ● Operate within aggressive margins (~4%) ● Rollback on timing violations
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
Runtime Example Emergenc y Voltage Current Flush ALU Cache Issue Dispatch Commit
Voltage Signatures ● Recurring phases ● Locality ● Context of system ● uArch events (on/off) ● Control flow
Predictor Accuracy Tradeoff ● Types of events ● Number of events ● Space constraints ● PC anchor
Emergency Avoidance ● Non-zero delay throttling ● Misprediction ● Sensor based learning
Prediction Table Storage ●CAM ●Bloom Filter ●Thresholds
Predictor Accuracy
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
Conclusion ● uArch events create voltage signatures ● Predict emergencies with >90% confidence ● 11-13% performance improvement ● Aggressive voltage margins (4%)
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?