1

Enabling autonomic behavior in systems software with hot swapping

By J. Appavoo, K. Hui, C. A. N. Soules,R. W. Wisniewski, D. M. Da Silva,

O. Krieger, M. A. Auslander, D. J. Edelsohn,B. Gamsa, G. R. Ganger, P. McKenney,

M. Ostrowski, B. Rosenburg,M. Stumm, J. Xenidis

IBM SYSTEMS JOURNAL, 2003

2

Agenda Introduction Autonomic features through hot swapping Autonomically improving performance An infrastructure for hot swapping Hot swapping in K42 Conclusions

3

Introduction Autonomic computing systems are designed to be s

elf-diagnosing and self-healing. This abilities can improve performance, availability,

and security. This “hot swapping” avoids the requisite prescien

ce and additional complexity. Hot swapping is accomplished either by interpositi

oning of code, or by replacement of code.

4

Introduction Interpositioning involves inserting a new compone

nt between two existing ones. Replacement allows an active component to be swi

tched with a different implementation of that component while the system is running.

An important goal of autonomic systems software is achieving good performance.

More importantly, new implementation can be introduced in a running system.

5

Autonomic features through hot swapping

Autonomic features : Performance System monitoring Flexibility and maintainability System availability Extensibility Testing

How hot swapping via interposition and replacement of components can support these autonomic features ?

6

Autonomic features through hot swapping Performance :

The optimal resource-management mechanism.( replacement )

System monitoring : Monitoring is required for autonomic system to be

able to detect security threats, performance problem, and so on. ( interposition )

Flexibility and maintainability : Autonomic systems must evolve as their environment

and workloads change, but must remain easy to administer and maintain. ( modularized & replaced )

7

Autonomic features through hot swapping System availability :

Numerous mission-critical systems require five-nine-level availability, making software upgrades challenging. ( without having to take the system down )

Extensibility : As they evolve, autonomic systems must take on

tasks not anticipated in their original design. ( interposition and dynamic replacement )

Testing : Even in existing relatively inflexible systems, testing

is a significant cost that constrains development. ( hot swapping can ease the burden; interposition )

8

Autonomically improving performance How hot swapping can support and extend

existing performance enhancements ? Optimizing for the common case Optimizing for a wide range of file attribute values Access patterns Exploiting architecture features Multiprocessor optimizations Enabling client-specific customization Exporting system structure information Supporting specialized workloads

9

Autonomically improving performance Optimizing for common case :

For many OS resources the common access pattern is simple. However, it become expensive when it has to support all the complex and less common cases.

Optimizing for a wide range of file attribute values. Access patterns :

By using the appropriate policy, researcher have shown up to 30 percent fewer cache misses.

Exploiting architecture features : Many features of modern processors are

underutilized in today. Hot swapping make it easier to take advantage of such architectural features.

10

Autonomically improving performance Multiprocessor optimization :

In large multiprocessor systems, parallel applications can benefit from processor locality.

11

Autonomically improving performance Enabling client-specific customization :

Extensible OSs offer new interface that enable clients to customize OS components.

Exporting system structure information : Some technologies require detailed knowledge about the

state of system structure. Supporting specialized workloads :

In monolithic systems, optimizations in support of one type of workload often negatively impact the performance of other types of workload. Hot swapping can dynamically switch components optimized to handle these types of workload.

12

An infrastructure for hot swapping

Achieving an effective generic hot-swapping mechanism for systems software requires careful design.

We first describe system requirements for supporting hot swapping, which involve both interposition and replacement.

We conclude by comparing hot swapping to adaptive code.

13

An infrastructure for hot swapping System structure :

The modular structure is critical for hot swapping. If there is only one global component, it becomes difficult

to tune the system to specific application. Modularity and the use of object-oriented design in OSs is

expanding. Triggering hot swapping :

In many cases we expect an object itself to trigger a replacement.

To do this, monitoring is required. Additional monitoring can be enabled by more accurate information.

14

An infrastructure for hot swapping Choosing the target :

In some cases, the initiator of a hot swap can identify the target directly as.

In most cases, however, it is more appropriately identified by its behavior than by its specific name or type.

Transferring state : A key issue is how to transfer state efficiently

between the source and the target of an object replacement.

15

An infrastructure for hot swapping Dynamically adding object types :

Downloading new code into the OS provides two challenges that need to be handled by the infrastructure.

First, if an object class is changed, it is necessary to track all instances of that class.

Second, if library or subsystem code is changed, it is necessary to download code into all running applications and subsystem.

16

An infrastructure for hot swapping Adaptive code alternative :

A more common approach in systems software to handling varying environments is to use adaptive code.

But, adaptive code has three major disadvantages : required foreknowledge, higher code complexity and higher overhead.

17

An infrastructure for hot swapping

18

Hot swapping in K42 K42 is an open source research kernel for cache-coherne

t 64-bit multiprocessor systems, which currently runs on PowerPC and MIPS platforms, and will soon be available for x86-64 platforms.

The motivation and goals : K42 focuses on achieving good performance and scalabilit

y, on providing a customizable and maintainable system, on supporting a wide variety of platforms, systems, and problem domains.

K42 fully supports the Linux API and ABI and uses Linux libraries, device drivers, file systems, and other code without modification.

19

Hot swapping in K42 K42 structure :

20

Hot swapping in K42 K42 key technologies :

Object-oriented. Traditional kernel functionality is implemented in libraries in the

application’s own address space. It’s easily ported to new hardware. Due to its structure can expl

oit machine-specific features. Much system functionality has been implemented in user-level s

ervers. Using processor-specific memory to achieve good scalable NUM

A performance .(nonuniform memory access ) Designed to run on 64-bit and taken advantage of 64-bit to make

performance gains by. Fully preemptable and most of the kernel data structure are pag

eable. Mix of time-shared, real-time, and fine-grained gang-scheduled a

pplication. …

21

Hot swapping in K42 Dynamic replacement algorithm:

Instantiate the replacement component. Establish a quiescent state for the component to be replac

ed. Transfer state from the old component to the new one. Swap in the new component replacing all references. Deallocate the old component.

22

Hot swapping in K42 There are three key issues to be addressed in this

design. We need to establish a quiescent state so that it is

safe to transfer state and swap references. We need to determine what state needs to be

transferred and how to transfer it to the new component safely and efficiently.

We need to swap all of the references held by the clients of the component so that the references refer to the new one.

23

Hot swapping in K42 K42 features used :

Object-oriented structure. Each k42 object is accessed through a single pointer

indirection, where the indirection pointer of all objects is maintained in an Object Translation Table ( OTT ).

K42 has a generation count mechanism that allow us to easily determine when all threads reached a safe point.

24

Hot swapping in K42 Conceptually there are three stage in replacing a

component.

25

Hot swapping in K42 To perform a replacement, a mediator object is

interposed in front of the old one. This mediator object proceeds through the three

phases. Forward Blocked Completed

26

Hot swapping in K42 Forward

Forward each call on to the original component. Blocked

Temporarily blocks new calls, while it waits for the tracked called to complete.

Exceptions are made for recursive calls that need to be allowed to proceed to avoid deadlock.

Completed It removes its interception by updating the

appropriate indirection pointer in the OTT to point to the new component.

27

Conclusion Autonomic systems software should have self-

maintenance capabilities. We proposed an object-oriented system structure

that supporting hot swapping as an infrastructure toward meeting these autonomic challenges by dynamic monitoring and modifying the OS.