1 Providing Dynamic Update in an Operating System By Liao,Hsiao-Win Andrew Baumann, Gernot Heiser University of New South Wales & National ICT Australia Jonathan Appavoo, Dilma Da Silva, Orran Krieger, Robert W. Wisniewski IBM T.J. Watson Research Center Jeremy Kerr IBM Linux Technology Center

2 Classification for dynamic update  Updates that only affect code, where any data structures remain unchanged across the update.  Updates that affect both code and global, single-instance, data.  Updates that affect multiple-instance data structures.

3 Fundamental Requirements for Dynamic Update  Updatable unit  Safe point  State tracking  State transfer  Redirection of invocations  Version management

4 Dynamic update requirement in K42 ( I )  Updatable unit Hot-swapping object instance Hot-swapping object instance  Safe point Detect quiescent state (generation count mechanism) similar to RCU Detect quiescent state (generation count mechanism) similar to RCU

5 Dynamic update requirement in K42 ( II )  State tracking factory object factory object  State transfer transfer function ( intermediate format ) transfer function ( intermediate format )  Redirection of invocations object translation table object translation table  Version management Version numbers on factory objects Version numbers on factory objects

6 Dynamic Update Implementation  Module loader  Factory mechanism  Steps in a dynamic update

7 Module loader  Consist of Object in kernel that allocates pinned memory in the kernel text area and a trusted user-space program that access to kernel’s symbol table  Perform the relocations and symbol table management at user-level, and leave only the space allocator object in the kernel

8 Factory mechanism  Use the factory design pattern  Factory object provides an interface for creating and destroying objects of one particular class, and maintains the set of objects that it has created.  The majority of the factory implementation is factored out using inheritance and preprocessor macros.

9 Factory object

10 Example of Factory mechanism ProcessReplicated::Create( ProcessReplicated::Create( ProcessRef &out, HATRef h, PMRef pm, ProcessRef &out, HATRef h, PMRef pm, ProcessRef creator, const char *name); ProcessRef creator, const char *name); This leads to problems for dynamic update This leads to problems for dynamic update → Create call is bound at compile-time, and cannot easily be redirected to an updated implementation of the ProcessReplicated object → Create call is bound at compile-time, and cannot easily be redirected to an updated implementation of the ProcessReplicated object → we rely on the caller of this method to track the newly created instance → we rely on the caller of this method to track the newly created instance

11 Example of Factory mechanism DREF_FACTORY_DEFAULT(ProcessRe plicated)->create(...); DREF_FACTORY_DEFAULT(ProcessRe plicated)->create(...); But where (...) represents the arguments as before. But where (...) represents the arguments as before.

12 Example of Factory mechanism (*ProcessReplicated::Factory::factoryRef) (*ProcessReplicated::Factory::factoryRef) ->create(...); ->create(...); Using a factory reference allows us to hot-swap the factory itself. Using a factory reference allows us to hot-swap the factory itself.

13 Steps in a dynamic update

14 Steps in a dynamic update Before update, the old factory tracks instances of a class

15 Steps in a dynamic update Instantiate a new factory for the updated class

16 Steps in a dynamic update Hot-swap old factory with its replacement (transferring set of instances)

17 Steps in a dynamic update New instantiations handled by the updated factory

18 Steps in a dynamic update Hot-swap each old instance to updated replacement (in parallel on each CPU)

19 Steps in a dynamic update Destroy old factory

20 Experiments  All the experiments were conducted on an IBM pSeries 630 Model 6E4 system, with four 1.2GHz POWER4+ processors and 8GB of main memory.  Each test was repeated 10,000 times  The total time measured using the processor’s cycle counter.

21 Overhead of factory mechanism  Microbenchmarks for creation cost using factories:  No noticeable performance degradation on system throughput, as measured by a version of SPEC SDET

22 The end The end