1 / 24

Hung, Chin-Chieh ESL, Dept. of CSIE , CCU 8/25/2005

Supporting Hot-Swappable Components for System Software Kevin Hui, Jonathan Appavoo, Robert Wisniewski, Marc Auslander, David Edelsohn, Ben Gamsa Orran Krieger, Bryan Rosenburg, Michael Stumm HOTOS 2001. Hung, Chin-Chieh ESL, Dept. of CSIE , CCU 8/25/2005. Outline. Introduction

zita
Télécharger la présentation

Hung, Chin-Chieh ESL, Dept. of CSIE , CCU 8/25/2005

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Supporting Hot-Swappable Components for System SoftwareKevin Hui, Jonathan Appavoo, Robert Wisniewski, Marc Auslander, David Edelsohn, Ben GamsaOrran Krieger, Bryan Rosenburg, Michael StummHOTOS 2001 Hung, Chin-Chieh ESL, Dept. of CSIE , CCU 8/25/2005

  2. Outline • Introduction • Design Overview • Implementation Highlights • Preliminary Results • Conclusion

  3. Outline • Introduction • Design Overview • Implementation Highlights • Preliminary Results • Conclusion

  4. Introduction • A hot-swappable component • Can be replace at running time • Online upgrades • Improve performance • Simplify software

  5. Introduction • The necessary of hot-swappable component • Instantiate a replacement component • Quiescent state • Transfer state • Swap component • Deallocate the old component

  6. Problemsof Hot-Swappable Component • Establish a quiescent state • Safely transfer and swap • Transfer state • The most easy way is not efficient • Swap all of the references held by client • The references now refer to the new one

  7. Design Goals • Zero performance overhead for that will not be swapped • Complete transparency to client component • Minimal code impact on components that wish to be swaped • Zero impact on other components • Good performance and scalability

  8. Outline • Introduction • Design Overview • Implementation Highlights • Preliminary Results • Conclusion

  9. Design Overview • The algorithm is as follows: • Establish a quiescent state • Transfer the component state • Update the references to the component

  10. Establish a quiescent state • Swap the indirection pointer • Point to an interposing object • Track all thread • Could pass the call to original object • Wait for the termination of all calls • Use a efficient means • Blocks all new call

  11. Transfer the component state • Best common format • To make state transfer efficient • Avoid canonical form • A list or array • For example • A hash table to be passed directly through a pointer

  12. Update the references to the component • Changing the indirection pointer • Refer to the new object • Relesaing all the threads blocked in the interposing object • Deallocating the original object and the temporary interposing object

  13. Outline • Introduction • Design Overview • Implementation Highlights • Preliminary Results • Conclusion

  14. Implementation Highlights • The interposing object is called the mediator • Three phases of the swapping operation • Forward • Block • Completed

  15. Forward Phase • Tracks new incoming calls • By identifiers and increments an in-flight call counter • Stores thread identifiers • In a hash table • This phase continues until the swap initiation has the lowest generation number • A generation number in K42

  16. Block Phase • Check the new call • Belong to the in-flight thread(in hash table) • Yes, forward to the original component • No, the thread is suspended • The call counter reached 0 • A quiescent state

  17. Completed Phase • Remove the mediator • Future call be directly handled by the new component • Resume all thread

  18. Outline • Introduction • Design Overview • Implementation Highlights • Preliminary Results • Conclusion

  19. Preliminary Results • Benchmarks • A toy component (simple counter) • A substantial component of the K42 memory management subsystem

  20. Preliminary Results • Counter • Simple:Partitioned/Shared counter

  21. Preliminary Results • File Cache Manager(FCM) • Simple:Partitioned/Shared FCM

  22. Outline • Introduction • Design Overview • Implementation Highlights • Preliminary Results • Conclusion

  23. Conclusion • Describe the hot-swapping mechanism • Totally transparent to the clients • Minimize Impact on performance • The limitation of this mechanism • Threads are relatively short-lived • Many Server-based system are short-lived

  24. Thanks for your listening

More Related