Changes between Version 7 and Version 8 of ClientSched


Ignore:
Timestamp:
Nov 21, 2011, 12:29:41 AM (13 years ago)
Author:
davea
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ClientSched

    v7 v8  
    1111
    1212Note: a '''processor type''' is either CPU or a GPU vendor.
    13 There may be multiple '''instances'' of each processor type.
     13There may be multiple '''instances''' of each processor type.
    1414
    1515The goals of these policies are (in descending priority):
     
    4545 * For each processor type, the number of currently idle instances.
    4646
    47  * For each processor type, the '''saturated''': the amount of time
     47 * For each processor type, the '''saturated time''': the amount of time
    4848   that all instances are busy.
    4949
    50  * For each task T, a flag T.deadline_miss indicating whether the task
     50 * For each task T, a flag '''T.deadline_miss''' indicating whether the task
    5151   missed its deadline in the simulation.
    5252
     
    6464recently by the project's tasks relative to its resource share.
    6565
    66 The '''scheduling priority''' of a project P is computed as
     66The scheduling priority of a project P is computed as
    6767
    6868{{{
     
    9494  whenever the saturated period is less than min_buffer.
    9595 * Adjust SP(P) based on the amount of work currently queued
    96  * Ask the fetchable project with greatest SP(P) for "shortfall" seconds of work.
     96 * Ask the fetchable project with greatest SP(P) for work.
     97   We request enough jobs to fill the number of idle instances,
     98   and to use at least "shortfall" instance-seconds.
    9799 * Whenever a scheduler RPC to project P is done
    98100   (e.g. to report results) and SP(P) is greatest among fetchable projects
    99101   for a given processor type, request "shortfall" seconds of that type.
    100102
     103=== Per-processor-type backoff ===
     104
     105The client keeps track of whether projects have work for particular processor types,
     106so that it doesn't keep asking them for types of work they don't have.
     107
     108To do this, it maintains a separate backoff timer per (project, resource type).
     109The backoff interval is doubled up to a limit (1 day)
     110whenever we ask for work of that type and don't get any work;
     111it's cleared whenever we get a job of that type.
     112Note: if we decide to ask a project for work for resource A,
     113we may ask it for resource B as well, even if it's backed off for B.
     114
     115This mechanism is independent of the overall backoff timer for each project,
     116which is triggered by requests from the project, RPC failures, job errors and so on.