Changes between Version 12 and Version 13 of ClientSchedOctTen
- Timestamp:
- Oct 14, 2011, 10:20:15 AM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ClientSchedOctTen
v12 v13 69 69 70 70 == 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. 71 As the job scheduling policy picks jobs to run (e.g. on a multiprocessor) 72 it needs to take into account the jobs already scheduled, so that it doesn't always schedule multiple jobs from the same project. 73 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. 72 74 73 75 == Work fetch == … … 77 79 * ask the fetchable project with greatest SP(P) for "shortfall" seconds of work. 78 80 * 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.80 81 * 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 81 82 … … 83 84 84 85 * 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. 87 When it finishes, if other projects are temporarily down, don't want to immediately fetch more work from A.
