AllScale Scheduler

The dynamic multi-objective optimizer/scheduler component of the AllScale architecture is responsible for efficiently utilizing the target platform for steering applications towards fulfilling  customizable trade-offs among a variety of (conflicting) optimization objectives, such as, minimizing execution time, energy consumption or resource utilization (=computational cost). 

The scheduler is organized in two-level hierarchical design: 

  1. A top layer, strategic scheduler – this layer interprets the user provided objective function and runs asynchronously independent of the application on each node; it evaluates the objective function periodically and re/configures the available resources accordingly. The configurations may include throttling the number of cores, disabling/enabling hardware threads, changing the frequency, and/or voltage of the compute units, etc. 
  2. A bottom layer, tactical scheduler – this layer is responsible for effectively utilizing the resources provided by the top layer; the decision of whether to split the work items or process, the selection of the work item variants and assigning them to compute units, and moving data item fragments are all responsibility of this layer. Each node has their own tactical scheduler and they mostly work independently of each other, except when they need to move data across the nodes for load-balancing purposes, or satisfy the requirements imposed by the resiliency manager.

The user can provide his or her objective preference using the application command line options. These options can be self-descriptive for the end user and can be any from the predefined parameter list below: time, resource, energy, time_resource, time_energy, resource_energy, time_resource_energy. The user provided objectives are interpreted by the run-time as the following objective function:

 \huge T^{k}E^{m}R^{n}

Here, T is the total execution time, E is the total energy requirement, and R is the total resource usage. This function is general enough to cover either one or more of the given objectives by manipulating the weights within their domains: 0≤k,m,n<2, k,m,n are natural numbers. For example, a user provided time_resource objective is interpreted by the run-time with the weights of  n=1,m=0,r=1, that is, the dynamic optimizer should find the best trade-off between the total execution time and the total resource usage.

The following figure illustrates the design of the dynamic multi-objective optimizer. It is worth mentioning that the evaluation periods are conditional and subject to change:

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 671603

Contact Details

General Coordinator

Thomas Fahringer

Scientific Coordinator

Herbert Jordan