spdf/elektron
Archived
1
0
Fork 0
Code Issues 4 Pull requests 1 Projects Releases Packages Wiki Activity

modified schedulers/README.md to now use Elektron instead of Electron. Also, changed the content to just display the contained scheduling policies with an explaination for each of them.

Browse source
This commit is contained in:
Pradyumna Kaushik 2017-09-26 13:43:23 -04:00
parent 04f24beac5
commit 971f6833c3
1 changed files with 22 additions and 22 deletions
Download patch file Download diff file Expand all files Collapse all files

44
schedulers/README.md
View file

@ -1,24 +1,24 @@
Electron: Scheduling Algorithms
================================
Elektron: Pluggable Scheduling Policies
=======================================
To Do:
##__Scheduling Policies__
* Design changes -- Possible to have one scheduler with different scheduling schemes?
* Fix the race condition on 'tasksRunning' in proactiveclusterwidecappingfcfs.go and proactiveclusterwidecappingranked.go
* **Critical**: Separate the capping strategies from the scheduling algorithms and make it possible to use any capping strategy with any scheduler.
* Create a package that would contain routines to perform various logging and move helpers.coLocated(...) into that.
Scheduling Algorithms:
* First Fit
* First Fit with sorted watts
* Bin-packing with sorted watts
* BinPacked-MaxMin -- Packing one large task with a bunch of small tasks.
* Top Heavy -- Hybrid scheduler that packs small tasks (less power intensive) using Bin-packing and spreads large tasks (power intensive) using First Fit.
* Bottom Heavy -- Hybrid scheduler that packs large tasks (power intensive) using Bin-packing and spreads small tasks (less power intensive) using First Fit.
Capping Strategies
* Extrema Dynamic Capping
* Proactive Cluster-wide Capping
* Piston Capping
* **First Fit** - *Find the first task in the job queue whose
resource constraints are satisfied by the resources available in
a resource offer. If a match is made between an offer and a task,
the offer is consumed in order to schedule the matching task. Else,
move onto a new mesos resource offer and repeat the process.*
* **Bin-packing** - *For each resource offer received, tasks are matched
from the priority queue keyed by the Watts resource requirement. If a task's
resource requirements are not satisfied by the remaining resources in the
offer, the next task in the queue is evaluated for fitness. This way, tasks
are packed into a resource offer.*
* **Max-Min** - *Pack a resource offer by picking a mixed set of tasks
from the job queue (used as a double-ended queue) that is sorted in
non-decreasing order of tasks' Watts requirement. Max-Min alternates
between picking tasks from the front and back of the queue.*
* **Max-GreedyMins** - *Similar to Max-Min, a double-ended queue,
sorted in non-decreasing order of tasks' Watts requirement, to store
the tasks. Max-GreedyMins aims to pack tasks into an offer by picking
one task from the end of the queue, and as many from the beginning,
until no more task can fit the offer.*