1 University of Maryland Runtime Program Evolution Jeff Hollingsworth © Copyright 2000, Jeffrey K. Hollingsworth, All Rights Reserved. University of Maryland UMIACS

2 University of Maryland Expanding the Application/System Interface Past Model: Start program execution, hope for best New Model: Application exposes alternatives different algorithms/parameters performance expectations for options System adapts application to optimize execution

3 University of Maryland Harmony Structure Tuning Control Applications and Libraries System Controller Capacities and Requirements Tuning Options Tuning Control Availabilities and Requirements Metric Interface Resource Requirements

4 University of Maryland Features of Harmony RSL Bundles –primary unit of adaptation –mutually exclusive sets of application options Resource Requirements –expected utilization for each option and resource Performance Prediction –expected performance of selected bundles –allows optimizing multiple applications on a system

5 University of Maryland Harmony API harmony_startup(, ) harmony_bundle_setup(“ ”) void *harmony_add_variable(“name”,,, ) harmony_wait_for_update() harmony_end() Used by application to: –define options –learn of harmony selections –receive information about the environment

6 University of Maryland Architecture of Harmony Implementation

7 University of Maryland Example: Database Query Processing Queries Processed on Cluster SMP Active Disks Existing PC Cluster Queries Processed on SMP SMP Active Disks Existing PC Cluster Harmony allows building adaptive systems –Workload can change where computation is done

8 University of Maryland Database Bundle harmonyBundle Dbclient:1 where { {QS{node server {seconds 9} {memory 20}} {node client {seconds 1} {memory 42}} {link client server 2} } {DS{nodeserver {seconds 1} {memory 20}} {node client {memory >=17} {seconds 9}} {link client server {44 + (client.memory > 24 ? 24 : client.memory) - 17}} }

9 University of Maryland Client Response Times Clients added one at a time: –First two clients run with query-shipping –Third client flips all to data-shipping

10 University of Maryland Results from PSTSWM Solves nonlinear shallow water equations Contains many options: –Multiple algorithms embedded in the code –Problem-specific options Communication Parameters

11 University of Maryland Integration with ADR Allows ADR Applications to –automatically adapt to available resources –support multiple users more efficiently Use Harmony to –select number of outstanding I/O requests –manage memory allocation –share information between clients & servers

12 University of Maryland Gathering Information Data Affinity –Shared Memory Systems Need Locality –Large Datasets should be processed near source Example: DSM Correlation 4-processors8-processors (random layout)

13 University of Maryland Runtime Code Patching Permits –Modifying code at runtime –Inserting instrumentation into running systems –Machine independent representation of a program Can be used for –Performance measurement –Correctness debugging –Testing Code coverage Hard to execute paths

14 University of Maryland Applications of Runtime Code Patching Performance measurement –Recording application behavior Correctness debugging –Fast conditional breakpoints –Data breakpoints Execution driven simulation –Architecture studies Testing –Code coverage testing –Forcing hard to execute paths to be taken

15 University of Maryland Current Work Application resource usage –potential, not necessarily achievable –user, compiler, profiling Performance prediction –structural models –POEMS, AppLeS ADR & Vision Integration More applications –web server –video server –commercial database system

16 University of Maryland Conclusions Launch and forget is not sufficient: –Capacities are dynamic –Demands are dynamic System-directed adaptation gives us: –Complete information –Handles to running applications But requires: –Application restructuring (or layering, i.e. DSM) –Detailed resource requirements Data Collection –Enables better choices to be made