Linux Kernel Extensions To Minimize Effects of Software Aging - CLEI2010

Outline Introduction Prototype Summary
Linux Kernel extensions to minimize effects of

Software Aging
Ariel Sabiguero Andrés Aguirre Fabricio González
Daniel Pedraja Agustı́n Van Rompaey
Instituto de Computación, Facultad de Ingenierı́a, Universidad de la República

J. Herrera y Reissig 565, Montevideo, Uruguay
{asabigue|aaguirre}@fing.edu.uy {fabgonz|danigpc|fenix.uy}@gmail.com
20/10/2010
A. Sabiguero, A. Aguirre, F. González, D. Pedraja, A. Van Rompaey Linux Kernel extensions to minimize effects of Software Aging
1 Introduction
Concepts
Finner grained rejuvenation
2 Prototype
Problem definition
Key challenges addressed
Kernel modifications performed
Validation
Performance testing
3 Summary
...ongoing work
finally...
Concepts
Soft Errors
A soft error is a transient failure in semiconductors causing

the eventual lose of data integrity in memory.
It implies a change in a program or a data value.
Soft errors do not imply a permanent damage on system’s
hardware, the only damage is to the data that is being
processed.
Concepts
Software Aging & Rejuvenation
The term Software aging refers to the deteriorating in the availability

of OS resources caused by data corruption.
Concepts
Software Aging & Rejuvenation
The term Software aging refers to the deteriorating in the availability

of OS resources caused by data corruption.
Software Rejuvenation aims at proactive fault management tech-

niques addressing the restoration of system’s internal state in order
to prevent the occurrence of failures.
A new approach
Instead of a proactive full process/system

rejuvenation we address a finner grain.
A new approach

We take advantage of the fact that program
code and parts of program data remain
constant during program execution.
A new approach

We take advantage of the fact that program
code and parts of program data remain
constant during program execution.
We will apply reactive rejuvenation to the constant areas of the

system when they get modified.
Relevance of R.O. memory
State-of-the-art software engineering techniques suggest that

we do not code programs that change their own instructions.

Modern systems allows the definition of certain sections of
programs to be read only, that means, that remain constant
all through program execution.

Different portions of code and data are marked R.O. at
compile time.

Different portions of code and data are marked R.O. at
compile time.
Modern compilers enforce the usage of R.O. memory on their
native formats (ELF - Executable and Linking Format and PE
- Portable Executable for Linux and Windows respectively).
Problem definition
Objective & target platform
Detect and handle the occurrence of Soft Errors in R.O.

memory.
Problem definition
Objective & target platform
Detect and handle the occurrence of Soft Errors in R.O.

memory.
Platform
O.S.: GNU Linux Kernel 2.6.25.9
Distribution: OpenSuSE 11.0
Architecture: Intel x86
Read-Only Memory in Linux
Characteristics
Frame Granularity
Protection scheme: User space only
Frames shared between tasks
Read-Only Memory in Linux
Characteristics
Frame Granularity
Protection scheme: User space only
Frames shared between tasks
Read-only subset: frames mapped to one or more processes
with Read-Only access in every instance
Error detection mechanism
Memory change-detection algorithm

Frame level
Error detection code: CRC32
Error detection mechanism
Memory change-detection algorithm

Frame level
Error detection code: CRC32
Search Strategies
System level Frame Polling
Task subset Polling
Task scheduler checks
Error Handling actions
Error correction code: Hamming

Automatic File Rejuvenation
User space rejuvenation assistance
Error details =⇒ high granularity actions
Agent notifications =⇒ Synchronous actions
Kernel modifications performed
Kernel Map
Validation
Ensuring correctness of the implementation
Motivation: Separate bugs from Soft Errors

Challenges
Low error probability in our typical scenario
Hardware error generation difficult and expensive
Validation
Ensuring correctness of the implementation
Motivation: Separate bugs from Soft Errors

Challenges
Low error probability in our typical scenario
Hardware error generation difficult and expensive
Fault Injection
Software based memory error simulation
Kernel integrated vs High level
Exposed as System call
Performance testing
Case study
We decided to evaluate the impact on an IO-bounded

application and a CPU-bounded one.
Performance testing
Case study

Methodologically, we contrast benchmarks run on a modified
kernel and a standard one (vanilla).
Performance testing
Case study

Different levels of performance in tasks depending on
resources used:
Memory corruption correction routines almost do not compete
with IO-bounded loads.
Performance testing
Case study

Different levels of performance in tasks depending on
resources used:
Memory corruption correction routines almost do not compete
with IO-bounded loads.
CPU-bounded applications compete for the same resource
impacting on system performance.
Performance testing
Case study: performance results
IO-bounded CPU-bounded
...ongoing work
Future work
Address lose of cache locality.
...ongoing work
Future work

Consider power consumption due to continuous 100% CPU
usage.
...ongoing work
Future work

usage.
Focus in embedded solutions
Improve CPU usage (different approach than on desktops).
Test in architectures different from x86
...ongoing work
Future work

usage.
Focus in embedded solutions
Improve CPU usage (different approach than on desktops).
Test in architectures different from x86
Wish: to be able to test in ambient with more probability of
soft errors (EMI).
finally...
Conclusions
We built and tested a prototype with the expected

characteristics.
finally...
Conclusions

characteristics.
The software rejuvenation implementation is based on
software instead the traditional hardware based scheme.
finally...
Conclusions

characteristics.
Our approach avoids full system restart or full process restart,
for the kind of errors addressed.
finally...
Conclusions

characteristics.
Our approach avoids full system restart or full process restart,
for the kind of errors addressed.
Being simple and non-intrusive, it is aplicable to any piece of
(Linux) software without any modifications.
finally...
Thank you for your time
Questions?
finally...
Linux Kernel extensions to minimize effects of

Software Aging
Ariel Sabiguero Andrés Aguirre Fabricio González
Daniel Pedraja Agustı́n Van Rompaey
Instituto de Computación, Facultad de Ingenierı́a, Universidad de la República

J. Herrera y Reissig 565, Montevideo, Uruguay
{asabigue|aaguirre}@fing.edu.uy {fabgonz|danigpc|fenix.uy}@gmail.com
20/10/2010

Linux Kernel Extensions To Minimize Effects of Software Aging - CLEI2010

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Linux Kernel Extensions To Minimize Effects of Software Aging - CLEI2010

Caricato da

Copyright:

Formati disponibili

Outline Introduction Prototype Summary

Linux Kernel extensions to minimize effects of

Ariel Sabiguero Andrés Aguirre Fabricio González

Daniel Pedraja Agustı́n Van Rompaey

Instituto de Computación, Facultad de Ingenierı́a, Universidad de la República

A soft error is a transient failure in semiconductors causing

Software Aging & Rejuvenation

The term Software aging refers to the deteriorating in the availability

Software Aging & Rejuvenation

The term Software aging refers to the deteriorating in the availability

Software Rejuvenation aims at proactive fault management tech-

Finner grained rejuvenation

Instead of a proactive full process/system

Finner grained rejuvenation

Instead of a proactive full process/system

Finner grained rejuvenation

Instead of a proactive full process/system

We will apply reactive rejuvenation to the constant areas of the

Finner grained rejuvenation

Relevance of R.O. memory

State-of-the-art software engineering techniques suggest that

Finner grained rejuvenation

Relevance of R.O. memory

State-of-the-art software engineering techniques suggest that

Finner grained rejuvenation

Relevance of R.O. memory

State-of-the-art software engineering techniques suggest that

Finner grained rejuvenation

Relevance of R.O. memory

State-of-the-art software engineering techniques suggest that

Objective & target platform

Detect and handle the occurrence of Soft Errors in R.O.

Objective & target platform

Detect and handle the occurrence of Soft Errors in R.O.

Key challenges addressed

Read-Only Memory in Linux

Key challenges addressed

Read-Only Memory in Linux

Key challenges addressed

Error detection mechanism

Memory change-detection algorithm

Key challenges addressed

Error detection mechanism

Memory change-detection algorithm

Key challenges addressed

Error Handling actions

Error correction code: Hamming

Kernel modifications performed

Ensuring correctness of the implementation

Motivation: Separate bugs from Soft Errors

Ensuring correctness of the implementation

Motivation: Separate bugs from Soft Errors

We decided to evaluate the impact on an IO-bounded

We decided to evaluate the impact on an IO-bounded

We decided to evaluate the impact on an IO-bounded

We decided to evaluate the impact on an IO-bounded

Case study: performance results

Address lose of cache locality.

Address lose of cache locality.

Address lose of cache locality.

Address lose of cache locality.

We built and tested a prototype with the expected