Hey everyone,
I did an evaluation of EAR and its energy policies as part of my studies, and I am reasonably sure that I discovered a bug in the implementation of min_energy:
Essentially, the problem is that the values of curr_freq and curr_pstate are overwritten with the defaults from the configuration in min_energy.c:537. This means that compute_reference will assume that the data from the signature was collected at the default frequency, instead of whatever frequency EAR has currently configured. Most importantly, it will set time_ref to signature->time instead of using the energy model for an accurate projection.
The value of time_ref is then passed to compute_cpu_freq_min_energy, where it is scaled by the configured penalty and used to select a new P-State, without accounting for the fact that it already includes (part of) the penalty from previous runs of the policy. In my evaluation, this meant that once min_energy selected a lower P-State, it was mostly unable to switch back into a higher one. One of my benchmarks ran 25 % slower, even though the policy was supposed to only reduce its speed by up to 5 % (and in fact, raising that to 20 % made the program run faster overall).
Based on some quick tests, the following patch solves the problem for me and makes min_energy behave more like one would expect from the documentation:
diff --git a/src/library/policies/policy_plugins/min_energy.c b/src/library/policies/policy_plugins/min_energy.c
index 7a25bd6..b32cbf1 100644
--- a/src/library/policies/policy_plugins/min_energy.c
+++ b/src/library/policies/policy_plugins/min_energy.c
@@ -534,8 +534,6 @@ state_t policy_apply(polctx_t *c, signature_t *sig, node_freqs_t *freqs, int *re
}
if (use_energy_models) {
/* If energy models are availables, we use them for CPU frequency selection. */
- curr_freq = def_freq;
- curr_pstate = def_pstate;
compute_reference(my_app, cpu_energy_model, &curr_freq, &def_freq, &best_freq, &time_ref, &power_ref);
verbose_master(3, "Time ref %lf Power ref %lf Freq ref %lu", time_ref, power_ref, best_freq);
// verbose_master(3, "Min energy: cur pstate %u min pstate %u max pstate %u", curr_pstate, min_pstate,
Hey everyone,
I did an evaluation of EAR and its energy policies as part of my studies, and I am reasonably sure that I discovered a bug in the implementation of min_energy:
Essentially, the problem is that the values of
curr_freqandcurr_pstateare overwritten with the defaults from the configuration inmin_energy.c:537. This means thatcompute_referencewill assume that the data from the signature was collected at the default frequency, instead of whatever frequency EAR has currently configured. Most importantly, it will settime_reftosignature->timeinstead of using the energy model for an accurate projection.The value of
time_refis then passed tocompute_cpu_freq_min_energy, where it is scaled by the configured penalty and used to select a new P-State, without accounting for the fact that it already includes (part of) the penalty from previous runs of the policy. In my evaluation, this meant that once min_energy selected a lower P-State, it was mostly unable to switch back into a higher one. One of my benchmarks ran 25 % slower, even though the policy was supposed to only reduce its speed by up to 5 % (and in fact, raising that to 20 % made the program run faster overall).Based on some quick tests, the following patch solves the problem for me and makes min_energy behave more like one would expect from the documentation: