1University of Maryland

Runtime Program Evolution

Jeff Hollingsworth

© Copyright 2000, Jeffrey K. Hollingsworth, All Rights Reserved.

University of MarylandUMIACS

2University of Maryland

Expanding the Application/System Interface

Past Model:Start program execution, hope for best

New Model:Application exposes alternatives

different algorithms/parametersperformance expectations for options

System adapts application to optimize execution

3University of Maryland

Harmony Structure

TuningControl

Applicationsand Libraries

System

Controller

Capacities andRequirements

TuningOptions

Tuning Control

Availabilities andRequirements

MetricInterface

ResourceRequirements

4University 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

5University of Maryland

Harmony APIharmony_startup(<unique id>, <use interrrupts>)

harmony_bundle_setup(“<bundle definition>”)

void *harmony_add_variable(“name”, <default>, <type>, <func>)

harmony_wait_for_update()

harmony_end()

Used by application to:– define options– learn of harmony selections– receive information about the environment

6University of Maryland

Architecture of Harmony ImplementationHarmony Process

ApplicationOptions

PerformanceData

OptionInstantiation

C Code

Option Selection (TCL Code)

Send/ Recv (TCP)

Application Process Application Process

Parameters

(e.g., cache size)

Alternative

Algorithms

Harmony Library

Application Code

Parameters

(e.g., cache size)

Alternative

Algorithms

Harmony Library

Application Code

7University of Maryland

Example: Database Query Processing

Queries Processed on Cluster

SMPActive Disks

Existing PC Cluster

Queries Processed on SMP

SMPActive Disks

Existing PC Cluster

Harmony allows building adaptive systems

–Workload can change where computation is done

8University of Maryland

Database BundleharmonyBundle Dbclient:1 where { {QS {node server

{seconds 9}{memory 20}}{node client {seconds 1}{memory 42}}{link client server 2}

}

{DS {node server{seconds 1}{memory 20}}{node client{memory >=17}{seconds 9}}

{link client server {44 + (client.memory > 24 ? 24 : client.memory) - 17}}

}}

9University of Maryland

Client Response Times

0

5

10

15

20

25

0 100 200 300 400 500 600 700 800 900Time [s]

Resp

onse

tim

e [s

]

Client #1

Client #2

Client #3

Clients added one at a time:– First two clients run with query-shipping– Third client flips all to data-shipping

10University of Maryland

Results from PSTSWM Solves nonlinear shallow water

equations Contains many options:

– Multiple algorithms embedded in the code – Problem-specific options

Communication Parameters All Combinations Size Nodes Min Max T42L16 4 0.75 1.52 T42L16 8 0.50 1.03 T85L32 4 9.55 20.89 T85L32 8 5.99 11.41

Best Combinations Min Max

0.75 1.49 0.50 0.77 9.55 15.38 5.99 7.90

11University 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

12University of Maryland

Gathering Information Data Affinity

– Shared Memory Systems Need Locality– Large Datasets should be processed near

source Example: DSM Correlation

4-processors 8-processors 8-processors

(random layout)

13University 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

14University 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

15University 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

16University 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