1. 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. 2 Agenda  Introduction  Autonomic features through hot swapping  Autonomically improving performance  An infrastructure for hot swapping  Hot swapping in K42  Conclusions

3. 3 Introduction  Autonomic computing systems are designed to be self-diagnosing and self-healing.  This abilities can improve performance, availability, and security.  This “ hot swapping ” avoids the requisite prescience and additional complexity.  Hot swapping is accomplished either by interpositioning of code, or by replacement of code.

4. 4 Introduction  Interpositioning involves inserting a new component between two existing ones.  Replacement allows an active component to be switched 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. 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. 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. 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. 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. 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. 10 Autonomically improving performance  Multiprocessor optimization : In large multiprocessor systems, parallel applications can benefit from processor locality.

11. 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. 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. 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. 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. 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. 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. 17 An infrastructure for hot swapping

18. 18 Hot swapping in K42  K42 is an open source research kernel for cache- cohernet 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 scalability, 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. 19 Hot swapping in K42  K42 structure :

20. 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 exploit machine-specific features. Much system functionality has been implemented in user- level servers. Using processor-specific memory to achieve good scalable NUMA 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 pageable. Mix of time-shared, real-time, and fine-grained gang- scheduled application. …

21. 21 Hot swapping in K42  Dynamic replacement algorithm: Instantiate the replacement component. Establish a quiescent state for the component to be replaced. Transfer state from the old component to the new one. Swap in the new component replacing all references. Deallocate the old component.

22. 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. 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. 24 Hot swapping in K42  Conceptually there are three stage in replacing a component.

25. 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. 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. 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.