A Design Framework for Morphable Applications

1
A Design Framework for Morphable Applications

• Puneet Chopra
• Ramakrishna Kotla

2
What is a Morphable Application?

• 1,000,000 foot definition
• An application that can adapt, at run-time, to
  obtain performance in proportion to the
  capabilities of the underlying hardware resources.

3
Why should we be interested?

• Applications written once
• Maybe in a specified manner
• Run on any hardware configuration
• Any number of processors
• Any cache size or number of cache banks
• Any amount of memory
• Heterogeneous hardware elements.
• Performance comparable to hand tuned version.

4
When is Morphing initiated?

• At compile time?
• At application invocation time
• On changing workload characteristics
• On changing resource availability
• On changing environmental conditions
• Temperature, radiation etc.

5
Examples of Morphing

• Regrouping of code to increase I-cache locality
• Balance a stage to the size of the cache.
• Change software architecture on changing workload
• Migrating from thread to event driven concurrency
  architecture on increasing workload.
• Adapt to changing resource availability
• E.g. processors, cache, energy etc.
• Redundant execution on increasing error rates.
• Remapping of code fragments onto hardware
  components based on communication between them.
• Adaptation to OS capabilities e.g. No/Bad thread
  support.

6
What is required?

• Conceptual framework
• Should embody the hardware software trends
• Hardware Trends
• Space bound to communication bound
• Smaller caches
• Closer to processing core
• Multiprocessor on a chip
• Heterogeneous resources
• Entities having different computational
  capabilities, access latencies etc.
• Software Trends
• Software from components
• OOP, Click Router, JAWS, X-Kernel/Scout OS,
  Proposal for databases
• Extensible Software

7
Framework for Morphable Apps

• Atomic elements of framework -
• Components
• Contexts
• Processing Element
• Composite elements of framework -
• Stages
• Paths
• Morphing elements of framework -
• Monitors
• Policy Abstraction

8
Component

• Definition -
• Indivisible collection of instructions.
• Compiler generates component graph from input
  code.
• Program Dependence Graph with V ? component set
• Automatically/ Programmer assisted/ Both
• Typically -
• Independent sub tasks of application that access
  local data.
• Amount of information shared between components
  is small.
• Multiple component graphs generated for different
  potential application executions.

9
Context

• Definition -
• State associated with an operation
• Operation ? execution of a component.
• State ?
• Pointer to code in program
• Data associated with operation
• Context specific information e.g. stack snapshot
• Properties -
• Mapped and executed on a PE.
• Can be passed across different address spaces.

10
Processing Element (PE)

• Definition -
• Abstraction of underlying hardware.
• Each PE has execution unit and association set
  (i.e. PE ? EU,AS)
• EU hardware execution stream.
• AS set of hardware resources associated with
  EU.
• Exports the EU and AS capabilities.
• Properties
• One-to-one or one-to-many mapping between
  hardware resources (e.g. registers, cache,
  memory, ports etc) and ASs.
• Associations could be static or dynamic.
• Facilitates Hardware Morphing!

11
Stage

• Definition
• Runtime entity composed of -
• One or more components
• Zero or more contexts
• Zero or more PEs
• Operations invoked on stage
• Mapped to corresponding component
• Contexts Revisited -
• Context associated with stage as Inactive
  context.
• Not amenable to execution by PE
• Inactive context converted to Active context.
• Amenable to execution by augmenting additional
  state.
• Active context executed by PE.

12
Staging

• Definition - Mapping component graph to stage
  graph
• Components aggregated into a stage
• Based on some criteria provided by policy
  abstraction
• E.g. I-cache/D-cache locality, Communication
  latency, Staging hints (user/compiler provided)
• Aggregate contains integral components
• Mapping of components to stages is dynamic
• Typically -
• Aggregation s.t. cumulative requirements is
  satisfiable by PEs.
• Compiler associates expected amount of resource
  requirement with component.
• Stages may be replicated.

13
Essentially
Component Graph (compile time)
Stage Graph (run time)
14
Paths

• Definition -
• Set of stages of stage graph, associated with a
  service.
• Application exports multiple services.
• Abstraction for service differentiation.
• Properties -
• Intuitively, the execution path for requests
  desiring a certain service.
• Resources reserved according to service
  requirements.
• May be non disjoint
• Can span multiple address spaces.
• Enables extensibility
• Specify new paths for new services
• Created dynamically by stringing together, and
  staging, components.
• Code specialization opportunity along path.

15
Monitors

• Definition -
• Entities that trigger morphing.
• Associated with any framework element.
• Selected from a supported set or user provided.
• Notify policy abstraction regarding any change in
  monitored conditions.
• Typically -
• Hierarchical organization of monitors.
• Information filtered and aggregated by lower
  level monitors and passed up the hierarchy.

16
Policy Abstraction

• Glue for all other elements.
• Definition -
• RTS augmented by user defined morphing actions.
• Properties -
• Provides stage specific policies
• Provides service differentiation policy across
  paths.
• Facilitates staging.
• Supports dynamic path creation.

17
Policy Abstraction (cont)

• Policies for
• Assigning contexts to stages
• Stage.Assoc_C C ? S
• Mandatory, RR, Work Stealing etc
• Policy for activating contexts
• Thread Pool, Thread per request, Wavefront
  algorithm (e.g. Staged Server) etc
• Assigning PEs to stages
• Stage.Assoc_P PE ? S
• Sticky policy for D-cache locality etc

18
Policy Abstraction (cont)

• Assigning PEs to active contexts within a stage
• Space Partitioning, Time Multiplexing, Gang
  Scheduling, Process Control etc.
• Stage.Bind_AP AC ? PE ? (AC, PE)
• Activation order of contexts within a stage
• FIFO, any type of scheduling, Local queue Work
  Stealing etc.
• Stage.Activate IC ? AC
• Grouping components into stages
• Restaging
• Dynamic component/stage replacement

19
A stage during execution
I-Contexts
A-Contexts