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

CPUActuator

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

Emergency

Emergency

Emergency

Emergency

Emergency

Emergency

Voltage

Current

Flush

ALU

Cache

Issue

Dispatch

Commit

2

1

3

4

1 1 1 14 4 4 4

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

Scheme Performance Gain (%)

Predictor Throttling

Oracle 14.2

Voltage Emergency Signature (VES) 13.5

VES with 8KB Table 11.1

Microarchitectural Event 4.1

Ideal Sensor Throttling

2% Soft Threshold 2.2

3% Soft Threshold 9

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?