Scheduling Status

1
Scheduling Status

• Yury Markovskiy
• 8-5-02

2
Outline

• Ordinary nodes vs CPU
• Stall Detect mechanism
• may create deadlocks
• Analysis
• New mechanism with dynamic adapt

3
Ordinary nodes vs CPU (1)

• Compute graph (ordinary) nodes
• Activity is easily identifiable
• If firing (token cons/prod is not required)
• Buffer empty and full provide necessary
  conditions for stall
• Rate profiling provides consistent results

A
B
C
4
Ordinary nodes vs CPU (2)

• CPU generates new tokens
• Activity cannot be easily identified
• OS scheduling
• Rate profiling provides inconsistent results
• Typically, tokens are emitted in bursts or at
  lower rate than expected by the computation on
  the array
• No empty/full buffer pair to determine stall
  point

CPU
A
B
5
Stall Detect mechanism (1)

• Currently, we use
• Buffer empty/full to identify stall point
• Can and will fail with CPU
• Creates deadlock
• Example CPU emits few token and stalls
• Not enough tokens to fill a buffer, i.e. trigger
  stall detect

CPU
A
B
6
Stall Detect mechanism (2)

• Worked so far
• All our applications have the same behavior
• Continuously feed data to the array and then read
  it back
• Buffers will eventually be filled or streams --
  closed

7
Stall Detect mechanism (3)

• Why is this important now?
• The techniques behind buffer sizing and
  minimizing the overhead rely on conventional data
  flow, i.e. its general behavior is understood.
• Performance numbers I obtain from simulator
  depend on
• OS scheduling algorithm
• Load on the machine
• Ad-hoc chosen parameters for the SCORE scheduler.
• Attempt to tune the scheduler operation.
• Need a justifiable solutions for dealing with uP
• Obtain consistent and explainable results

8
Analysis (1)

• Ultimate indicator of a stall condition is lack
  of activity on the array.
• For example if array has stalled for past Z
  cycles, continue to next scheduling step
• We used this originally, but unsuccessfully
• Is there a relationship between uP token output
  rate and Z?

9
Analysis (2)

• Simple scenario (static rate pipeline)
• uP rate X tokens/cycle
• Number of tokens N tokens/timeslice
• Timeslice exec time (Nkp) cycles
• Timeslice reconf time RTS cycles
• Number of timeslices T
• For steady state

10
Analysis (3)

• Saturation point (10) depends on uP rate and the
  pipeline only
• Buffer requirements grow with overhead.

11
New stall detect mechanism (1)

• uP rate X tokens/cycle
• 1/X the number of cycles between arriving
  tokens.
• Number of stall cycles
• Once the required number of stall cycles elapsed,
  switch to the next timeslice.
• Alternatively, reduce the size of buffers
  according to calculations above.

12
New stall detect mechanism (2)

• Needs more work to apply it to the general case
• Queuing theory
• So far, looked at the processor emitting tokens
• Need to add consumption
• In general, extra stream buffering between
  processor and array may smooth out bursty I/O
  behavior.
• Static approach to dealing with CPU does not seem
  to be sufficient, if outside of saturation
  (yellow) region.