Skip to content

WorkFetchMaxConcurrent

Delta edited this page Oct 18, 2023 · 1 revision

Work fetch with max concurrent constraints

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.

Clone this wiki locally