Optimistic Active Messages

1
(Optimistic) Active Messages

• T. Von Heicken, D. Culler, S. Goldstein, and K.
  Schauser, ISCA 92.
• D. Wallach, W. Hsieh, K. Johnson, M. Kaashoek and
  W. Weihl, PPOPP 95.

2
Introduction

• Problems with message passing parallel machines
• Use msg passing for scalability
• blocking send/receive limit utilization of CPU
  and communication infrastructure
• Common cost Model
• T Tcompute Tcommunicate
• Tcommunicate Nc ( Ts Ls . Tb)
• High performance CPU does not help much
• Faster communication infrastructure? It would be
  underutilized!
• (CM-5 Ts 86 ?s/msg, Tb 12 ?s/byte and Tfp
  0.33 ?s/flop)
• Solution
• Overlap computation with communication

3
Synchronous send/receive

• Mismatch bet/ programming model and HW
  functionality!
• Send/receive
• Wait until buffering space got secured
• Network bandwidth is underutilized
• avoid the 3-phase protocol?

4
Asynchronous send/receive
5
Active Messages

• Semantic gap between h/w and programming model
• Send/receive is not native to h/w
• Buffering mem alloc
• Initiating message handler interrupt,
  scheduling, ..
• Translated into performance loss
• Active message generalizes hardware functionality
• Message contains the address of handler
• The handler is in user space
• traditional per-process protection can be used
• Differs from RPC in that it just extracts data
  from network and integrates it into the ongoing
  computation
• Simple scheduling a simple handler is invoked
  and run to completion

6
Active Messages

• Eliminate buffering
• For receive(), it is done in user space
• No buffering for small messages
• Pre allocation for long messages
• For send(), buffering is needed
• Handler runs on stack of running computation (no
  thread of its own)
• Avoid thread management time
• Immediately integrate msg into computation
• Deadlock is possible! message handler should not
  block

7
Split-C Programming Model for AM
PUT message
GET message
Node 1
Node 2
PUT
1
GET
1
8
TAM Compiling to Active Messages

• Compiler help manage storage allocation and
  scheduling
• Compiler generates codes (threads) and handlers
  (inlets) for messages to receive
• At message arrival, inlets
• Inlet msg handler not a schedulable entity
• Handle arguments/results passing
• Activation frame
• Similar to address space
• Use continuation for fast codes (threads)
  execution
• Ready queue linked list of enabled AFs

9
TAM Activation Tree
10
H/W Support for Active Messages

• Network Interface
• DMA for large msgs
• Msgs in/from processor registers
• Protection for user level accesses to the network
  interface
• Range checks for destination(node, address,
  length)
• Header checks at receiver
• Processor
• Fast polling
• PC injection for fast handler invocation
• Dual processor computation communication

11
Active Messages Review

• Handler is just a fragment of codes
• Runs on the process stack
• No overhead for thread management
• No data copying
• Scheduling is by interrupt disable/enable and
  polling
• Handler must be simple
• No blocking to avoid deadlock
• Short execution time to avoid net congestion
• All these restrictions are burdens to programmers
• they are not free to use threads, mutex,
  condition vars,
• Solution be optimistic, assume you can!

12
Overview of OAM

• Optimistic Active Messages (OAM)
• Relieve restriction on AM handler
• Arbitrary user code can be executed for a message
• Arbitrary synchronization between messages and
  computation
• Comparable performance with Active Messages
• Deadlock from blocking handler
• Assume a handler will not block (be optimistic!)

13
Overview of OAM

• If wrong at run time
• Needs to wait for a lock or condition var
• to send a msg and the network is busy
• to run for a long time
• run the handler in a general thread
• Use continuation for the thread
• Undo and redo with the thread (if call must
  execute atomically)
• Undo and reply NAK

14
Thread Package

• Optimistic RPC user level threads lib and stub
  compiler
• Fast non-preemptive
• Context switch occurs only when
• A thread executes yield()
• A thread blocks for mutex, condition variable
• Thread scheduler runs in the context of the
  invoking tread
• Live stack optimization to avoid cost of context
  switch
• New thread runs on the stack used by the
  scheduler if invoking thread has terminated
• Terminating thread does not need to save the
  context

15
Stub Compiler

• Can create stubs for both Traditional RPC
  (always create a thread) and Optimistic RPC
• Generate code to detect when to abort a handler
• Thread scheduler knows when a thread is about to
  block
• Requires a lock that is held
• Needs to wait on a condition variable that is
  false
• For long running remote procedures insert code
  to check if handler runs too long