Data criticality estimation in software applications

Benso, Alfredo; Carlo, Stefano Di; Natale, Giorgio Di; Prinetto, P.; Taghaferri, L.

doi:10.1109/test.2003.1270912

Cited by 22 publications

(13 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…We split the non-SESE regions (with multiple entry and/or exit points) into two or three regions such that a new SESE region is created with as many static instructions as possible (and with many potential error sites) in it. For a basic block with multiple entry edges, 3 we split it into two blocks such that the first one with multiple entry edges has as few instructions as possible and the second block has a single entry edge. If the original block had only one exit edge, then the new second block becomes a new SESE region providing error sites in it with extra opportunity to compare state.…”

Section: When To Compare Executions?mentioning

confidence: 99%

“…(2) Program analysis: Some evaluation techniques examine certain (static or dynamic) program properties to identify program locations that are susceptible to producing SDCs [9,20,3,25]. These techniques are much faster than error injection based techniques (running time average of approximately 5 CPU hours for the techniques and applications we study), but their accuracy in finding SDC-causing error sites has previously been hard to validate.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

GangES: Gang error simulation for hardware resiliency evaluation

Hari

Venkatagiri

Adve

et al. 2014

2014 ACM/IEEE 41st International Symposium on Computer Architecture (ISCA)

View full text Add to dashboard Cite

As technology scales, the hardware reliability challenge affects a broad computing market, rendering traditional redundancy based solutions too expensive. Software anomaly based hardware error detection has emerged as a low cost reliability solution, but suffers from Silent Data Corruptions (SDCs). It is crucial to accurately evaluate SDC rates and identify SDC producing software locations to develop software-centric low-cost hardware resiliency solutions.A recent tool, called Relyzer, systematically analyzes an entire application's resiliency to single bit soft-errors using a small set of carefully selected error injection sites. Relyzer provides a practical resiliency evaluation mechanism but still requires significant evaluation time, most of which is spent on error simulations. This paper presents a new technique called GangES (Gang Error Simulator) that aims to reduce error simulation time. GangES observes that a set or gang of error simulations that result in the same intermediate execution state (after their error injections) will produce the same error outcome; therefore, only one simulation of the gang needs to be completed, resulting in significant overall savings in error simulation time. GangES leverages program structure to carefully select when to compare simulations and what state to compare. For our workloads, GangES saves 57% of the total error simulation time with an overhead of just 1.6%. This paper also explores pure program analyses based techniques that could obviate the need for tools such as GangES altogether. The availability of Relyzer+GangES allows us to perform a detailed evaluation of such techniques. We evaluate the accuracy of several previously proposed program metrics. We find that the metrics we considered and their various linear combinations are unable to adequately predict an instruction's vulnerability to SDCs, further motivating the use of Relyzer+GangES style techniques as valuable solutions for the hardware error resiliency evaluation problem.

show abstract

Section: When To Compare Executions?mentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

GangES: Gang error simulation for hardware resiliency evaluation

Hari

Venkatagiri

Adve

et al. 2014

2014 ACM/IEEE 41st International Symposium on Computer Architecture (ISCA)

View full text Add to dashboard Cite

show abstract

“…Benso et al [15], therefore, proposed a solution that performs run-time analysis of the application variables to obtain the criticality behavior of every variable. It first develops an analytical model to compute the criticality of a variable.…”

Section: Related Workmentioning

confidence: 99%

Relyzer: Application Resiliency Analyzer for Transient Faults

et al. 2013

View full text Add to dashboard Cite

Abstract-Future microprocessors need low-cost reliability solutions to enable reliable operations in the presence of failureprone devices. The state-of-the-art reliability solutions detect the presence of hardware faults by deploying low-cost software-level symptom monitors. Recently researchers have shown that these detection mechanisms provide high fault coverage with only few faults being undetected. There is a risk that these undetected faults can result in silent data corruptions or SDCs. The SDC rates demonstrated by the state-of-the-art symptom detection mechanisms have been an impressive <0.5% for permanent and transient hardware faults in all hardware units studied except the data-centric FPU. However, a thorough and accurate analysis is needed to evaluate the SDC rate to make these techniques practically viable. This paper presents Relyzer, an approach that analyzes the fault-free execution of applications and performs smart selective fault injection experiments, as opposed to random fault injections. Relyzer can thus provide a tight bound on the SDC rate. Relyzer first lists all the architecture level hardware faults that can possibly affect an application. It then employs a set of novel fault pruning techniques to eliminate a large fraction of them by predicting their outcomes and showing them equivalent to others. The hardware faults that remain after the pruning phase are the only ones that need thorough fault injection experiments. Our results show that Relyzer is capable of pruning about 99.9979% of hardware faults for the workloads that we studied. Some of our pruning techniques are heuristic based and validating them is a part of our ongoing work.

show abstract

“…Technology can be hardened [2][3][4][5][6][7][8], hardware architectures may include redundancy [9][10][11][12][13][14][15][16][17][18][19], and finally all software layers may implement error detection and recovery mechanisms [20][21][22][23][24][25][26]. On the one hand, this enables designers to apply cross-layer holistic design approaches to manage errors in their systems.…”

Section: Introductionmentioning

confidence: 99%

Cross-layer reliability evaluation, moving from the hardware architecture to the system level: A CLERECO EU project overview

Vallero

Tselonis

Foutris

et al. 2015

Microprocessors and Microsystems

Self Cite

View full text Add to dashboard Cite

International audienceAdvanced computing systems realized in forthcoming technologies hold the promise of a significant increase of computational capabilities. However, the same path that is leading technologies toward these remarkable achievements is also making electronic devices increasingly unreliable. Developing new methods to evaluate the reliability of these systems in an early design stage has the potential to save costs, produce optimized designs and have a positive impact on the product time-to-market

show abstract

Data criticality estimation in software applications

Cited by 22 publications

References 13 publications

GangES: Gang error simulation for hardware resiliency evaluation

GangES: Gang error simulation for hardware resiliency evaluation

Relyzer: Application Resiliency Analyzer for Transient Faults

Cross-layer reliability evaluation, moving from the hardware architecture to the system level: A CLERECO EU project overview

Contact Info

Product

Resources

About