Build Configuration with Kconfig¶
To configure the compilation options of the framework execute:
$ make menuconfig
Once the menu has appeared, we can navigate through it as it follows:
Target Hardware¶
In the configuration of the target hardware platform, first, we must choose the
Host System
option. This typically includes the combination of the
operating system, the CPU architecture family and the native or
cross-compilation mode.
Linux - Native
: compile for the local host system
Linux - Cross-compile ARM
: cross-compile for an ARM-based embedded board
Android - Cross-compile ARM
: cross-compile for an Android device
Going one level back, we have a further option that affects the host system configuration: Emulated Host (cgroup). When selected, the BarbequeRTRM will run without actually enforcing any resource assignment, for resources of type CPU (and related processing elements) and MEMORY (host-side). This option can be useful for some framework development purposes, or in case of development of integrated applications. In the latter, the developer may be interested in testing the integration, without taking care of the resource assignment.
The second aspect of the target hardware is related to the Acceleration
Platform
. The configuration menu includes the possibility of enabling the
support for additional processing units, through OpenCL and the NVIDIA
run-time. Special cases instead are the ones included in the FPGA-Based
Platform menu. Here it is possible to choose between the H2020 projects
MANGO and RECIPE. This requires the availability of the specific
hardware developed for the two research projects. As an alternative, the option
Emulate Accelerators, similarly to Emulated Host, allows the developers to
test the framework in an emulated configuration, also for the heterogeneous
part. In case of selection of one of the FPGA-based options, the MANGOLIBS
Installation path must be specified, providing the path to the root
installation directory containing the other libraries and frameworks, the
software stack is based on.
Heterogeneous target platforms from EU H2020 projects¶
Deployment¶
This submenu allows you to specify the installation directory of the framework and, in case of cross-compilation, all the data required to establish a SSH connection towards the target device.
Run-Time Resource Manager¶
This submenu includes the options regarding the BarbequeRTRM daemon and the libraries provided to the application developers.
Daemon Setup¶
This is the menu containing the resource manager daemon specific options, which include:
Platform Loader
: tools to be used for reading the target platform description (RXML is the default and suggested one).
Linux Resource Manager
: Linux-specific management options. Here we can enable the Linux Process Management option for enabling the management of legacy workload, i.e. applications not implementing the Adaptive Execution Model provided by the RTLib.
Power Management
: the power management capabilities of the BarbequeRTRM. Through this menu, the user can enable the resource-specific power monitor and control interfaces (CPU, AMD/NVIDIA GPUs, MANGO,…). Moreover, we may want periodic run-time monitoring of the platform (Periodic Monitoring), with the period length to be set in the daemon configuration file. The Battery Management option instead, if enabled, allows us to trigger the current policy in case of charge status under a given threshold. Obviously, the policy should include an energy-aware approach. Finally, the NO ACPI Interface is the default selection for target hosts based on a Linux kernel version >= 4.
Distributed Systems
: the set of options for enabling the BarbequeRTRM in a distributed context. The Server port value is the port number for the daemon to wait for a connection. The Agent Proxy plugin requires the selection of an implementation of the RPC interface onto which it will be based the communication between remote instances of the resource manager. Finally, the Distributed Configuration selection can drive the behaviour of the resource allocation policy.
Policies¶
Name |
Description |
Recipe-based |
Process support |
---|---|---|---|
DynamicRandom |
Random assignment of CPU quota. |
No |
Yes |
Random |
Random assignment of Application Working Mode. |
Yes |
Yes |
TempBalance |
Priority-proportional and thermal-aware allocation of CPUs. |
No |
Yes |
Test |
Priority-proportional allocation of CPUs. |
No |
Yes |
Run-Time Library¶
In this menu, you can find some configuration options for the Run-time Library (bbque_rtlib), including the maximum length for the application name, the timeout related to the communication bewteen application and daemon, the selection of the type of channel and the profiling options.
Programming Model¶
On top of the Adaptive Execution Model we built also an intermediate layer for the integration of further programming models: the Programming Model Synchronization Layer. In the current version, BOSP provides also the task-graph library (libtg), to implement programming models based on providing a task-graph based description of the managed application. A first example of programming model exploiting this feature comes with the MANGO Library included in the MANGOLIBS Project.
Advanced Options¶
Advanced options include the possibility of enabling a Debug build, the maximum number of application priorities, number of managed resources (per type), the selection of additional optional managers (Event Manager or Data Manager) and the policy profiler.
External Libraries and Tools¶
This menu groups two types of components: dependency libraries and tools. The dependencies are typically automatically selected, according to the configuration options enabled above.
AEM-integrated applications¶
Sample applications and samples from benchmark suites ported to the Adaptive Execution Model.