Last active
August 29, 2015 13:56
-
-
Save yifan-gu/9286214 to your computer and use it in GitHub Desktop.
Discussion on the schedule policy
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For this problem, I tested two policies. | |
The first one is "small tasks first". Using this policy can make the scheduler achieve very high throughput in the terms of "# of tasks it can schedule in a given time". | |
But it will be likely to cause starvation problem. In which case if the small tasks keep coming, they will preempt the scheduler and block the big tasks. | |
So in real environment, this kind of scheduler will incent users not to lie about their actual usage. | |
The second one is "small tasks first + starvation proof" | |
In this policy, small tasks are served first. But all tasks will have a waiting limit. If one task timeout, then it will get served anyway. | |
However this policy has its own problem, | |
1, If the big task demands too much, it will simply block the whole scheduler. Even worse, it will make all other tasks timeouts. Thus the scheduler policy will reduce to FIFO. | |
2, It is not easy to determine the value of the timeout. | |
Idealy, we can use the queue theory to compute the average waiting time dynamically. But since time limits, I didn't implement that. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
To improve:
I think I have commentted some in the source code.
Most are not hard, but to achieve locality is a little bit more complex