forked from BOINC/boinc
-
Notifications
You must be signed in to change notification settings - Fork 0
WorkFetchMaxConcurrent
Delta edited this page Oct 18, 2023
·
1 revision
current:
rr sim: (pick_jobs_to_run) if project reaches a MC limit,
stop picking its jobs
(and take it out of the simulation)
Need to do this to avoid starvation.
work fetch: don't fetch from a project at MC limit
problem: we don't buffer work for projects with MC limits
solution:
rr sim:
keep simulating project even if at MC limit
keep track of MI(P,R) = max # instances used by MC projects P
how many instances the project is able to use, given its MC restriction.
It may be all instances.
maintain "MC shortfall" MCS(R,P) for each MC project P
in update_stats()
y = MI(P,R) - #devices in use by P
x = min(y, nidle)
MCS(R,P) += x*dt
allow work fetch from MC project P, but use MCS(R,P) instead of shortfall; don't request if it's zero
examples (suppose min_buf is 3, max_buf is 6)
4 device instances
p = project with max concurrent constraint
x = other projects
. = idle
example 1: P has lots of work, and can use only 2 instances
7 pp..
6 pp..
5 pp..
4 pp..
3 pp..
2 pp..
1 pp..
In this case shortfall is 6, but we don't want to request any more work from P
example 2: p has limited work. It can use 1 or 2 instances, depending on which app versions run
7 ....
6 **..
5 p*..
4 p*.x
3 p*xx
2 pxxx
1 ppxx
In this case the MC shortfall for P is 5 (the *'s). If P had the highest scheduling priority, we'd ask it for 3 units of work. After that, it wouldn't be eligible for work fetch because the MC shortfall would be zero. But we'd be able to ask another project for 4 units.