Changes between Version 12 and Version 13 of ClientSchedOctTen


Ignore:
Timestamp:
Oct 14, 2011, 10:20:15 AM (12 years ago)
Author:
davea
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ClientSchedOctTen

    v12 v13  
    6969
    7070== Job scheduling ==
    71 As the job scheduling policy picks jobs to run (e.g. on a multiprocessor) it needs to take into account the jobs already scheduled, so that it doesn't always schedule multiple jobs from the same project. To accomplish this, as each job is scheduled we increment a copy of REC(P) as if the job had run for one scheduling period.
     71As the job scheduling policy picks jobs to run (e.g. on a multiprocessor)
     72it needs to take into account the jobs already scheduled, so that it doesn't always schedule multiple jobs from the same project.
     73To accomplish this, as each job is scheduled we increment a copy of REC(P) as if the job had run for one scheduling period.
    7274
    7375== Work fetch ==
     
    7779 * ask the fetchable project with greatest SP(P) for "shortfall" seconds of work.
    7880 * adjust SP(P) based on the amount of work currently queued
    79  * option: if not at max after this RPC, try the project with 2nd-highest SP(), etc.
    8081 * whenever a scheduler RPC to project P is done (e.g. to report results) and SP(P) is greatest among fetchable projects for a given processor type, request "shortfall" seconds of that type
    8182
     
    8384
    8485 * This will tend to get large (max-min) clumps of work for a single project, and variety will be lower than the current policy.
    85  * What about "overworked" scenario: project A has very long job, runs high-priority for weeks. When it finishes, if other projects are temporarily down, don't want to immediately fetch more work from A.
     86 * What about "overworked" scenario: project A has very long job, runs high-priority for weeks.
     87When it finishes, if other projects are temporarily down, don't want to immediately fetch more work from A.