TLB Reliability: Architectural Analysis

1. TLB Reliability: Architectural Analysis Feihui Li Swapna Dontharaju 12/04/2003

2. Outline • Motivation • TLB Behavior Collection • Experiments with Errors Injection • Protection scheme • Future work

3. Motivation • Importance of TLB’s Reliability • Program proceeding, security • TLB’s impact on performance • In the critical path of the processor • How to ensure reliability without compromising the performance much?

4. Current solution • Intel’s ITANIUM processor • Critical fields in TLB are protected by parity. • Parity detection is not necessarily done before memory transaction submitting, so a hardware bus rest action may be needed • IBM’s POWER4 • ECC or Hardware refresh

5. Exploit the lifetime behavior of TLB • TLB entries have the similar lifetime behavior with cache decay • We want to use the “dead” space to save redundancy information for “hot” entries, so the reliability would be improved

6. TLB Behavior Collection: Experiment setup • Simulator: SimpleScalar 3.0 • Benchmarks: Spec2000 Integer part • Default TLB configuration • iTLB: 64 entries, associativity 4 • dTLB: 128 entries, associativity 4 • Page size 4096 bytes

7. dTLB Dead Percentage

8. dTLB Dead Percentage

9. dTLB Dead Percentage

10. Effect of the TLB Size on Dead Percentage

11. Observation • Most benchmarks provide a dead percentage over 40%: It’s promising to make use of them • Larger TLB size means larger dead percentage over the time, and means high possibility to use those dead entries to save redundant information

12. Experiments with Error Injection • Goal: To analyze the effect of soft error on different parts of TLB • Assumption for soft error generation • Random Distribution (even probability for each bit, bits are independent) • Assumption for each TLB entry: Tag(VA, 20bits) data(PA, 18bits) Status, protection (10bits)

13. Effective Error Distribution

14. Protection Scheme • Based on parity and ECC, we can save redundancy(e.g., replication) in “dead” region and do background refresh (err correction) • This refresh may be selective, just for those “hot”, active entries.

15. Future work • Experiments about iTLB • Detailed proposal and implementation of protection scheme • Comparison of this protection scheme with basic parity and ECC protection

16. Thank you!