Hi EAS-DEV,
We are fine tuning EAS and DVFS for our product, and use WA to do auto test.
In the presentation, http://connect.linaro.org.s3.amazonaws.com/hkg18/presentations/hkg18-210.pdf, it lists Test cases at Page 9 & 10.
Except Vellamo, can all the following test cases be verified via WA?
In addition, there are some questions to consult.
1) Temple run and Beach buggy blitz are games, how to evaluate the performance?
2) Is there any suitable benchmark for UIbench & Homescreen?
3) Currently, audio and video are real-time playback, how to check the improvement?
[cid:image001.png@01D3D58F.7F44EEE0]
[cid:image002.png@01D3D58F.7F44EEE0]
BR,
Erin
Hi,
Any updates to below emails,.?
Awaiting your kind response for regarding my previous email. If it makes
sense to talk, please let me know how your calendar looks.
I would appreciate if you could pass along my details to the appropriate
person if you don't handle this.
Do you have any other requirement kindly let me know your exact target
industry and target audience and target location, we will provide the exact
cost and counts with many more ....
Regards,
Chris
From: Chris Samuel [mailto:chris.samuel@lead-marketings.com]
Sent: Tuesday, April 03, 2018 4:28 PM
To: 'eas-dev(a)lists.linaro.org'
Subject: IBM lotus-accounts
Hi,
A quick check to see if you would you be interested to acquire updated
Slack, IBM Lotus Domino, IBM Lotus Notes, LogMeIn, Microsoft SharePoint,
Accounts with verified email and phone numbers.
kindly let me know your exact target industry and target audience and target
location, we will provide the exact database counts with cost and many
more....
Appreciate your time and look forward to your response.
Best Regards,
Chris,
Marketing Executive,
If you do not want to receive from us then reply back "Unsubscribe" as a
Subject Line.
Hi,
A quick check to see if you would you be interested to acquire updated
Slack, IBM Lotus Domino, IBM Lotus Notes, LogMeIn, Microsoft SharePoint,
Accounts with verified email and phone numbers.
kindly let me know your exact target industry and target audience and target
location, we will provide the exact database counts with cost and many
more....
Appreciate your time and look forward to your response.
Best Regards,
Chris,
Marketing Executive,
If you do not want to receive from us then reply back "Unsubscribe" as a
Subject Line.
Hi,
My first mail here, please tell me if this is not the right list for my queries. I have recently got myself a thundersoft s835 development kit and set it up for power measurement. I was looking at creating the energy model for this from scratch and measuring the impact. I stumbled across something which led me to write this mail. The eas integration document mentions no support currently exists for SMT. However, my kernel configuration for some reason has SCHED_SMT enabled. The s835 is not hyper-threaded and so I am thinking it's a mistake. My questions are:
1) Is disabling SCHED_SMT enough or are there any other configurations that need to be changed as well ?
2) I'd like to understand the technical difficulties with enabling SMT support since I have a mips device which has hyperthreading. Is it that the cpu-cluster energy model would not be enough to handle proper task placement when it comes to virtual cores ?
3) Is there any on-going work on adding SMT support or is it considered as not being worth the effort ?
Thanks for reading.
-Jason
This patch set is to optimize the energy computation on Android kernel
android-4.9-eas-dev branch [1];
Patches 0001-0012 are used to refactor the code and some minor optimization,
otherwise the task energy computation is hard to landed into current code;
Patch 0013 "sched/fair: Optimize energy computation with task oriented" is
the core patch in whole patch set, which is mainly used to implement energy
calculation for task. Patch 0014 is a sequential patch to use cached value
so we can get more benefit for performance by exchanging more memory.
Patch 0015 is a trival experiment patch to remove 'idle state estimation'.
The testing uses rt-app to generate synthetic workload, the workload duty
cycles are 1%/5%/10%/20%/30%/40%; the duration is measured interval for
func select_energy_cpu_idx(), which now is used to calculation three
candidates in single run. The result shows this patch set improve for
energy computation duration:
+----------------+-------+-------+-------+-------+-------+--------+
| workload | 1% | 5% | 10% | 20% | 30% | 40% |
+----------------+-------+-------+-------+-------+-------+--------+
| w/o patch set | 17267 | 21227 | 17019 | 13914 | 15002 | 23412 |
| w/t patch set | 10823 | 11924 | 10931 | 10785 | 11139 | 11223 |
+----------------+-------+-------+-------+-------+-------+--------+
| Opt percentage | 37% | 43% | 36% | 22% | 26% | 52% |
+----------------+-------+-------+-------+-------+-------+--------+
The detailed testing ipython notebook you could check [2][3].
[1] https://android.googlesource.com/kernel/common/+/android-4.9-eas-dev
[2] https://github.com/Leo-Yan/lisa/blob/2018_03_17_android_4.9_eas_dev_nrg_com…
[3] https://github.com/Leo-Yan/lisa/blob/2018_03_17_android_4.9_eas_dev_nrg_com…
Leo Yan (15):
sched/fair: Prepare energy env cpumask before energy calculation
sched/fair: Re-define return values for select_energy_cpu_idx()
sched/fair: Reduce indent in select_energy_cpu_brute()
sched/fair: Fix one minor typo
sched/fair: Use per cpu data to maintain energy environment
sched/fair: Use cpumask to track candidates for energy calculation
sched/fair: Lift CPU iteration out of calc_sg_energy()
sched/fair: Introduce new function compute_task_energy()
sched/fair: Decide 'eenv->sg_cap' ahead energy computation
sched/fair: Use eenv::sg_cap to select capacity index
sched/fair: Estimate capacity index ahead energy computation
sched/fair: Refactor compute_energy()
sched/fair: Optimize energy computation with task oriented
sched/fair: Optimize energy calculation with cached energy data
sched/fair: Remove idle state estimation
kernel/sched/fair.c | 542 +++++++++++++++++++++++++---------------------------
1 file changed, 256 insertions(+), 286 deletions(-)
--
1.9.1
hi Chris, Patrick, Quentin,
On android-4.9-eas-dev branch, after the commit of energy_diff
re-factor("sched/fair: re-factor energy_diff to use a single
(extensible) energy_env"), the calculation of group_idle_state for
previous cpu had changed.
Before the re-factor, for eenv_before, there is chance to continue
doing group_idle_state estimation(not "0goto end" directly);
After the re-factor, for cpu_idx=EAS_CPU_PRV, there is no chance to do
estimation("goto end" directly);
Is it deliberate for this change? If yes, do you have any test result for this?
-static int group_idle_state(struct energy_env *eenv, struct sched_group *sg)
+static int group_idle_state(struct energy_env *eenv, int cpu_idx)
{
+ struct sched_group *sg = eenv->sg;
int i, state = INT_MAX;
int src_in_grp, dst_in_grp;
long grp_util = 0;
@@ -5556,8 +5610,10 @@ static int group_idle_state(struct energy_env
*eenv, struct sched_group *sg)
/* Take non-cpuidle idling into account (active idle/arch_cpu_idle()) */
state++;
- src_in_grp = cpumask_test_cpu(eenv->src_cpu, sched_group_cpus(sg));
- dst_in_grp = cpumask_test_cpu(eenv->dst_cpu, sched_group_cpus(sg));
+ src_in_grp = cpumask_test_cpu(eenv->cpu[EAS_CPU_PRV].cpu_id,
+ sched_group_cpus(sg));
+ dst_in_grp = cpumask_test_cpu(eenv->cpu[cpu_idx].cpu_id,
+ sched_group_cpus(sg));
if (src_in_grp == dst_in_grp) {
/* both CPUs under consideration are in the same group or not in
* either group, migration should leave idle state the same.
@@ -5571,7 +5627,7 @@ static int group_idle_state(struct energy_env
*eenv, struct sched_group *sg)
*/
for_each_cpu(i, sched_group_cpus(sg)) {
grp_util += cpu_util_wake(i, eenv->p);
- if (unlikely(i == eenv->trg_cpu))
+ if (unlikely(i == eenv->cpu[cpu_idx].cpu_id))
grp_util += eenv->util_delta;
}
Thanks,
Ke Wang
