Hi Tixy,
So there are some differences between the EAS code we have in LSK and the latest stuff internally.
In our internal version: 1. Some of the code in tune.c has been moved into fair.c for better efficiency but it also means that this error can't happen. 2. accept_deltas has a bugfix for evaluating boost region selection 3. There are some fixes to sched_tune cgroup accounting to prevent missing dequeue events and accumulating a +ve error in the amount of tasks in the group (this causes incorrect selection of frequency). This is newer stuff and hasn't had the same level of testing of the other parts.
What's your timeline for accepting patches to EAS for 16.06? Patrick has suggested sending a set to review which fixes these issues where the first one will fix the config error and the rest will bring the functionality up to date.
If we are close to deadline, then it might be feasible to take the first patch this month and possibly just not enable schedtune.
I found when comparing HMP and EAS that a global schedtune boost isn't specific enough to make a usable difference in any of the tests we have, and in order to make proper use of boost groups through the cgroup controller we need some changes in Android (which I'll provide as soon as I can). The logic inversion and boost group accounting problems do have an impact on both energy and performance, but maybe the conservative choice is the best for this switch-over release.
On the other hand, having support for boost groups in the kernel and not used by userspace still allows people to experiment with it, and I do intend to land some Android patches to make it automatic. We could equally well ship with it on and include in release notes that userspace doesn't make use of it and that there are a couple of known bugs.
What do you reckon?
--Chris
________________________________________ From: Jon Medhurst (Tixy) tixy@linaro.org Sent: 07 June 2016 10:07 To: Chris Redpath Cc: eas-dev; ryan.harkin@linaro.org Subject: [PATCH] sched/tune: Fix building when CGROUPS not enable
If we enable CONFIG_SCHED_TUNE without CONFIG_CGROUPS we get the following errors:
kernel/sched/fair.c: In function 'energy_diff_evaluate': kernel/sched/fair.c:4795:2: error: implicit declaration of function 'schedtune_normalize_energy' [-Werror=implicit-function-declaration] nrg_delta = schedtune_normalize_energy(eenv->nrg.diff); ^ kernel/sched/fair.c:4798:2: error: implicit declaration of function 'schedtune_accept_deltas' [-Werror=implicit-function-declaration] eenv->payoff = schedtune_accept_deltas( ^
Fix this by making sure the dummy version of these functions are defined if the real ones aren't.
Signed-off-by: Jon Medhurst tixy@linaro.org ---
This is another build fix for the 3.18 backport of EAS [1] but I'm not sure if the missing functions are actually meant to do something in the case when we have SCHED_TUNE without CGROUPS?
[1] http://git.linaro.org/arm/eas/kernel.git/shortlog/refs/heads/linux-3.18-eas-...
kernel/sched/tune.h | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/kernel/sched/tune.h b/kernel/sched/tune.h index da1f7b2..3410a1d 100644 --- a/kernel/sched/tune.h +++ b/kernel/sched/tune.h @@ -1,6 +1,3 @@ - -#ifdef CONFIG_SCHED_TUNE - #ifdef CONFIG_CGROUP_SCHEDTUNE
int schedtune_cpu_boost(int cpu); @@ -13,14 +10,7 @@ int schedtune_normalize_energy(int energy); int schedtune_accept_deltas(int nrg_delta, int cap_delta, struct task_struct *task);
-#else /* CONFIG_CGROUP_SCHEDTUNE */ - -#define schedtune_enqueue_task(task, cpu) do { } while (0) -#define schedtune_dequeue_task(task, cpu) do { } while (0) - -#endif /* CONFIG_CGROUP_SCHEDTUNE */ - -#else /* CONFIG_SCHED_TUNE */ +#else
#define schedtune_enqueue_task(task, cpu) do { } while (0) #define schedtune_dequeue_task(task, cpu) do { } while (0) @@ -28,4 +18,4 @@ int schedtune_accept_deltas(int nrg_delta, int cap_delta, #define schedtune_normalize_energy(energy) energy #define schedtune_accept_deltas(nrg_delta, cap_delta, task) nrg_delta
-#endif /* CONFIG_SCHED_TUNE */ +#endif -- 2.1.4
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.