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
Hi Tixy,
Let me check this out with Patrick - I think the cgroup controller is supposed to be separate from the actual schedtune feature, although that's the only way it is really used.
Best Regards,
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.
Hi Chris,
I noticed the compilation error because I build my BusyBox configuration without CGROUPS enabled, but with EAS.conf included.
Do we need CGROUPS and CGROUP_SCHEDTUNE to say that we've enabled EAS? Or do we only need CGROUP_SCHEDTUNE if CGROUPS is enabled?
I'm wondering if EAS.conf should enable CGROUPS, if Kconfig should select CGROUPS if CGROUP_SCHEDTUNE is selected or if it's OK as it is?
Cheers, Ryan.
On 7 June 2016 at 10:54, Chris Redpath Chris.Redpath@arm.com wrote:
Hi Tixy,
Let me check this out with Patrick - I think the cgroup controller is supposed to be separate from the actual schedtune feature, although that's the only way it is really used.
Best Regards,
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.
Hi Ryan,
The cgroup controller for sched-tune is logically distinct from the scheduler feature sched-tune :) so at least logically, it ought to be separately configurable. However, sched-tune on it's own is a rather crude tuning control as it operates globally without the cgroup controller. In terms of having an EAS configuration which makes sense, we should have both turned on, and that probably means we should auto-select cgroups if CGROUP_SCHEDTUNE is on.
I've been toying with the idea of having an EAS-Android.conf as well, which is where we could put these things which are probably necessary for Android builds but not necessarily for barebones - what do you think about having an additional config fragment?
Whatever we do, we also should make sure that the code builds with sched-tune enabled but without the cgroup controller as this is supposed to be a valid configuration :)
--Chris
________________________________________ From: Ryan Harkin ryan.harkin@linaro.org Sent: 08 June 2016 10:12 To: Chris Redpath Cc: Jon Medhurst (Tixy); eas-dev Subject: Re: [PATCH] sched/tune: Fix building when CGROUPS not enable
Hi Chris,
I noticed the compilation error because I build my BusyBox configuration without CGROUPS enabled, but with EAS.conf included.
Do we need CGROUPS and CGROUP_SCHEDTUNE to say that we've enabled EAS? Or do we only need CGROUP_SCHEDTUNE if CGROUPS is enabled?
I'm wondering if EAS.conf should enable CGROUPS, if Kconfig should select CGROUPS if CGROUP_SCHEDTUNE is selected or if it's OK as it is?
Cheers, Ryan.
On 7 June 2016 at 10:54, Chris Redpath Chris.Redpath@arm.com wrote:
Hi Tixy,
Let me check this out with Patrick - I think the cgroup controller is supposed to be separate from the actual schedtune feature, although that's the only way it is really used.
Best Regards,
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.
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.
Hi Chris,
On 8 June 2016 at 10:39, Chris Redpath Chris.Redpath@arm.com wrote:
Hi Ryan,
The cgroup controller for sched-tune is logically distinct from the scheduler feature sched-tune :) so at least logically, it ought to be separately configurable. However, sched-tune on it's own is a rather crude tuning control as it operates globally without the cgroup controller. In terms of having an EAS configuration which makes sense, we should have both turned on, and that probably means we should auto-select cgroups if CGROUP_SCHEDTUNE is on.
So it sounds like I should have it, but not having it might not be a big deal for BusyBox, saying as it already has limited functionality. So long as it compiles.
I've been toying with the idea of having an EAS-Android.conf as well, which is where we could put these things which are probably necessary for Android builds but not necessarily for barebones - what do you think about having an additional config fragment?
In theory, android.conf should have everything Android needs; it has CGROUPS already. Then EAS.conf all the EAS specific stuff. Unless there are EAS things you want to turn on/off for Android and not for other distros?
Tixy would have a better view than me about how to split these, so it's best to work with him.
Whatever we do, we also should make sure that the code builds with sched-tune enabled but without the cgroup controller as this is supposed to be a valid configuration :)
For sure! :-)
Cheers, Ryan.
--Chris
From: Ryan Harkin ryan.harkin@linaro.org Sent: 08 June 2016 10:12 To: Chris Redpath Cc: Jon Medhurst (Tixy); eas-dev Subject: Re: [PATCH] sched/tune: Fix building when CGROUPS not enable
Hi Chris,
I noticed the compilation error because I build my BusyBox configuration without CGROUPS enabled, but with EAS.conf included.
Do we need CGROUPS and CGROUP_SCHEDTUNE to say that we've enabled EAS? Or do we only need CGROUP_SCHEDTUNE if CGROUPS is enabled?
I'm wondering if EAS.conf should enable CGROUPS, if Kconfig should select CGROUPS if CGROUP_SCHEDTUNE is selected or if it's OK as it is?
Cheers, Ryan.
On 7 June 2016 at 10:54, Chris Redpath Chris.Redpath@arm.com wrote:
Hi Tixy,
Let me check this out with Patrick - I think the cgroup controller is supposed to be separate from the actual schedtune feature, although that's the only way it is really used.
Best Regards,
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.
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.
On Wed, 2016-06-08 at 14:51 +0100, Ryan Harkin wrote:
On 8 June 2016 at 10:39, Chris Redpath Chris.Redpath@arm.com wrote:
[...]
I've been toying with the idea of having an EAS-Android.conf as well, which is where we could put these things which are probably necessary for Android builds but not necessarily for barebones - what do you think about having an additional config fragment?
In theory, android.conf should have everything Android needs; it has CGROUPS already. Then EAS.conf all the EAS specific stuff. Unless there are EAS things you want to turn on/off for Android and not for other distros?
Tixy would have a better view than me about how to split these, so it's best to work with him.
android.conf has the configs AOSP recommend, I don't want to modify it for EAS. So if there really is Android specific configuration for EAS then yes, we could have an extra config fragment for that. (Though it seems strange to me that EAS would be designed to be tuned by kernel configs rather than by system parameters determined at run time).
-- Tixy
On 08-Jun 15:26, Jon Medhurst (Tixy) wrote:
On Wed, 2016-06-08 at 14:51 +0100, Ryan Harkin wrote:
On 8 June 2016 at 10:39, Chris Redpath Chris.Redpath@arm.com wrote:
[...]
I've been toying with the idea of having an EAS-Android.conf as well, which is where we could put these things which are probably necessary for Android builds but not necessarily for barebones - what do you think about having an additional config fragment?
In theory, android.conf should have everything Android needs; it has CGROUPS already. Then EAS.conf all the EAS specific stuff. Unless there are EAS things you want to turn on/off for Android and not for other distros?
Tixy would have a better view than me about how to split these, so it's best to work with him.
android.conf has the configs AOSP recommend, I don't want to modify it for EAS. So if there really is Android specific configuration for EAS then yes, we could have an extra config fragment for that. (Though it seems strange to me that EAS would be designed to be tuned by kernel configs rather than by system parameters determined at run time).
Indeed, it is not. We are talking about a couple of configuration options which are related to SchedTune, which has two different working mode: global boosting vs per-task boosting (the second mode is an extension of the first one, with a slightly different userspace API).
The global boosting mode is an option provided just to allows SchedTune support on system compiled without CGroups support. Do they exists? Basically it provides the minimum functionalities for example to tune SchedFreq to be more like the ondemand or the performance governors.
The per-task boosting support is definitively the most interesting one, especially when it comes down to Android integration. Thus, IMO a default configuration for all systems in general should be SchedTune with per-task support, which requires CGroups enabled.
Cheers Patrick
-- Tixy
eas-dev mailing list eas-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/eas-dev
-- #include <best/regards.h>
Patrick Bellasi
On Wed, 2016-06-08 at 16:14 +0100, Patrick Bellasi wrote: [...]
We are talking about a couple of configuration options which are related to SchedTune, which has two different working mode: global boosting vs per-task boosting (the second mode is an extension of the first one, with a slightly different userspace API).
The global boosting mode is an option provided just to allows SchedTune support on system compiled without CGroups support. Do they exists?
Android makes heavy use of things like cgroups and standard distros seem to have it enabled too.
Basically it provides the minimum functionalities for example to tune SchedFreq to be more like the ondemand or the performance governors.
The per-task boosting support is definitively the most interesting one, especially when it comes down to Android integration. Thus, IMO a default configuration for all systems in general should be SchedTune with per-task support, which requires CGroups enabled.
Sounds like we want to enable CONFIG_CGROUP in EAS.conf [1] then.
Though it also sounds like CONFIG_CGROUP_SCHEDTUNE may be a somewhat redundant as a separate option and the code should for that could just always be included if we have CONFIG_SCHED_TUNE and CONFIG_CGROUPS ?
[1] http://git.linaro.org/arm/eas/kernel.git/blob/8768dc2c9fbadbdeec47a3ba61d241...
-- Tixy
On 08-Jun 16:39, Jon Medhurst (Tixy) wrote:
On Wed, 2016-06-08 at 16:14 +0100, Patrick Bellasi wrote: [...]
We are talking about a couple of configuration options which are related to SchedTune, which has two different working mode: global boosting vs per-task boosting (the second mode is an extension of the first one, with a slightly different userspace API).
The global boosting mode is an option provided just to allows SchedTune support on system compiled without CGroups support. Do they exists?
Android makes heavy use of things like cgroups and standard distros seem to have it enabled too.
Basically it provides the minimum functionalities for example to tune SchedFreq to be more like the ondemand or the performance governors.
The per-task boosting support is definitively the most interesting one, especially when it comes down to Android integration. Thus, IMO a default configuration for all systems in general should be SchedTune with per-task support, which requires CGroups enabled.
Sounds like we want to enable CONFIG_CGROUP in EAS.conf [1] then.
IMHO, that's a reasonable defconfig.
Though it also sounds like CONFIG_CGROUP_SCHEDTUNE may be a somewhat redundant as a separate option and the code should for that could just always be included if we have CONFIG_SCHED_TUNE and CONFIG_CGROUPS ?
While, I would suggest to still keep to option to disable per-task boosting. At least for testing and comparisons, some partners may be intrested in using global boosting mode.
[1] http://git.linaro.org/arm/eas/kernel.git/blob/8768dc2c9fbadbdeec47a3ba61d241...
-- Tixy
-- #include <best/regards.h>
Patrick Bellasi
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.
On Wed, 2016-06-08 at 11:29 +0000, Chris Redpath wrote:
So there are some differences between the EAS code we have in LSK and the latest stuff internally.
In our internal version:
- 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?
Release schedule is determined by ARM, we can release anything at any time but ARM have this testing process and seem to want to religiously keep to monthly schedules. Ryan knows more about that, so I'll let him answer as to what the deadlines might be.
One factor that might be a consideration is that I'm on holiday the week starting the 27th.
-- Tixy
Hi Chris,
On 8 June 2016 at 13:03, Jon Medhurst (Tixy) tixy@linaro.org wrote:
On Wed, 2016-06-08 at 11:29 +0000, Chris Redpath wrote:
So there are some differences between the EAS code we have in LSK and the latest stuff internally.
In our internal version:
- 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?
Release schedule is determined by ARM, we can release anything at any time but ARM have this testing process and seem to want to religiously keep to monthly schedules. Ryan knows more about that, so I'll let him answer as to what the deadlines might be.
One factor that might be a consideration is that I'm on holiday the week starting the 27th.
So long as Tixy has everything integrated and working by the time he goes on holiday, we'll be good for the LT release. It depends on how much churn you're hoping to push and how many problems Tixy finds.
Finger in the air, if we don't have it by Monday 20th, it's looking like a problem for us.
We need a working EAS kernel for the LMG folks too. We have one today, so if that's good enough, we needn't panic. If you want any changes to go into the LMG team's releases, we'll need to push our kernel by Thurs 16th at the latest, which means getting stuff from you earlier than that.
I guess it's best to start sending patches to Tixy sooner rather than later, to make sure he has time to get it in to his trees.
Cheers, Ryan.
-
Chris Redpath -
Jon Medhurst (Tixy) -
Patrick Bellasi -
Ryan Harkin