The EAR Library is the core of the EAR package. The EARL offers a lightweight and simple solution to select the optimal frequency for applications at runtime.
EARL is dynamically loaded next to the running applications by the EAR Loader. The loader detects whether the application is MPI or not. In case it is MPI, it also detects whether it is Intel or OpenMPI. Moreover, in the case of MPI, it intercepts the MPI symbols through the PMPI interface, and next symbols are saved in order to provide compatibility with MPI or other profiling tools. The EAR library is divided in several stages summarized in the following picture:
The loop signature is used to classify the application activity in different phases. The current EAR version supports the following phases for: IO bound, CPU computation and GPU idle, CPU busy waiting and GPU computing, CPU-GPU computation, and CPU computation (for CPU only nodes). For phases including CPU computation, the optimization policy is applied. For other phases, the EAR library implements some predefined CPU/Memory/GPU frequency settings.
Some specific configurations are modified when jobs are executed sharing nodes with other jobs. For example the memory frequency optiization is disabled. See section environment variables page for more information on how to tune the EAR library optimization using environment variables.
The EAR Library uses the $(EAR_ETC)/ear.conf
file to be configured. Please visit the EAR configuration file page for more information about the options of EARL and other components.
The library receives its specific settings through a shared memory regions initialized by EARD.
For information on how to run applications alongside with EARL read the User guide. Next section contains more information regarding EAR's optimisation policies.
EAR offers three energy policies plugins: min_energy
, min_time
and monitoring
. The last one is not a power policy, is used just for application monitoring where CPU frequency is not modified (neither memory or GPU frequency). For application analysis monitoring
can be used with specific CPU, memory and/or GPU frequencies.
The energy policy is selected by setting the --ear-policy=policy
option when submitting a SLURM job. A policy parameter, which is a particular value or threshold depending on the policy, can be set using the flag --ear-policy-th=value
. Its default value is defined in the configuration file, for more information check the configuration page for more information.
The goal of this policy is to minimise the energy consumed with a limit to the performance degradation. This limit is is set in the SLURM --ear-policy-th
option or the configuration file. The min_energy
policy will select the optimal frequency that minimizes energy enforcing (performance degradation <= parameter). When executing with this policy, applications starts at default frequency(specified at ear.conf).
The goal of this policy is to improve the execution time while guaranteeing a minimum ratio between performance benefit and frequency increment that justifies the increased energy consumption from this frequency increment. The policy uses the SLURM parameter option mentioned above as a minimum efficiency threshold.
Example: if --ear-policy-th=0.75
, EAR will prevent scaling to upper frequencies if the ratio between performance gain and frequency gain do not improve at least 75% (PerfGain >= (FreqGain * threshold).
When launched with min_time
policy, applications start at a default frequency (defined at ear.conf
). Check the configuration page for more information.
Example: given a system with a nominal frequency of 2.3GHz and default P_STATE set to 3, an application executed with min_time
will start with frequency F\\\[i\\\]=2.0Ghz
(3 P_STATEs less than nominal). When application metrics are computed, the library will compute performance projection for F\\\[i+1\\\]
and will compute the performance_gain as shown in the Figure 1. If performance gain is greater or equal than threshold, the policy will check with the next performance projection F\\\[i+2\\\]
. If the performance gain computed is less than threshold, the policy will select the last frequency where the performance gain was enough, preventing the waste of energy.
Figure 1: min_time
uses the threshold value as the minimum value for the performance gain between F\\\[i\\\]
and F\\\[i+1\\\]
.
EAR offers a user API for applications. The current EAR version only offers two functions, one to read the accumulated energy and time and another to compute the difference between the two measurements.
int ear_connect()
int ear_energy(unsigned long \\\*energy_mj, unsigned long \\\*time_ms)
void ear_energy_diff(unsigned long ebegin, unsigned long eend, unsigned long \\\*ediff, unsigned long tbegin, unsigned long tend, unsigned long \\\*tdiff)
int ear_set_cpufreq(cpu_set_t \\\*mask,unsigned long cpufreq);
int ear_set_gpufreq(int gpu_id,unsigned long gpufreq)
int ear_set_gpufreq_list(int num_gpus,unsigned long \\\*gpufreqlist)
void ear_disconnect()
EAR's header file and library can be found at $EAR_INSTALL_PATH/include/ear.h and $EAR_INSTALL_PATH/lib/libEAR_api.so respectively. The following example reports the energy, time, and average power during that time for a simple loop including a sleep(5)
.