- eas-dev - lists.linaro.org

[Integration Branch] Update 22-June-2018

by Douglas Raillard

Hi, A new EAS integration branch created on June 22nd is available on branch eas/next/integration here: http://linux-arm.org/git?p=linux-power.git For further information about main features, test coverage and work items for next integration please have a look at: https://developer.arm.com/open-source/energy-aware-scheduling/eas-mainline-… Best Regards, Douglas

7 years, 10 months

1
0
0 0

[RFC eas-dev] sched/fair: Skip pelt update if preempted by RT

by Joel Fernandes

From: "Joel Fernandes (Google)" <joel(a)joelfernandes.org> Here's a very rough patch just to discuss prevention of decay of CPU/task's util_avg signal incase its preempted by RT or DL. Its likely not correct and needs more work but it solves the issue I see with my synthetic test. To reproduce the issue, I wrote a synthetic rt-app test with RT task preempting a 100% CFS task for 300ms. https://pastebin.com/raw/rXNmRUZY I have seen in traces that the util_avg decays quickly even before the RT task sleeps. The idea is to mark the CFS class from put_prev_task_fair if the task was running while the put_prev_task() happened and unmark it from pick_next_task_fair. This approach also keeps the solution of this within CFS without modification to other classes. What do you think? Note: - Just for demo/trial, I took a full int from sched_avg. I am open to any ideas on a flag we can set, all that's needed is 1 bit. - The current UTIL_EST design cannot prevent this issue because it relies on task's sleeping and infact could be affect by this issue itself incase task's util-est EWMA hasn't built up. - Vincent's patches for PELT in DL/RT are still needed for correct OPP selection and estimation of capacity_of etc. This patch solves a different issue. CC: "eas-dev" <eas-dev(a)lists.linaro.org> CC: vincent.guittot(a)linaro.org CC: patrick.bellasi(a)arm.com CC: dietmar.eggemann(a)arm.com CC: chris.redpath(a)arm.com CC: juri.lelli(a)redhat.com CC: tkjos(a)google.com Signed-off-by: Joel Fernandes (Google) <joel(a)joelfernandes.org> --- include/linux/sched.h | 1 + kernel/sched/fair.c | 23 +++++++++++++++++++++++ 2 files changed, 24 insertions(+) diff --git a/include/linux/sched.h b/include/linux/sched.h index ca3f3eae8980..46b686192641 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -404,6 +404,7 @@ struct sched_avg { unsigned long runnable_load_avg; unsigned long util_avg; struct util_est util_est; + int freeze_updates; } ____cacheline_aligned; struct sched_statistics { diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 09b7eb69802c..521656b05b22 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -3103,6 +3103,13 @@ accumulate_sum(u64 delta, int cpu, struct sched_avg *sa, u32 contrib = (u32)delta; /* p == 0 -> delta < 1024 */ u64 periods; + /* + * If an update is supposed to be skipped, then do nothing. + * sa->last_update_time should still moves forward. + */ + if (sa->freeze_updates) + return 0; + scale_freq = arch_scale_freq_capacity(cpu); scale_cpu = arch_scale_cpu_capacity(NULL, cpu); @@ -6963,6 +6970,7 @@ pick_next_task_fair(struct rq *rq, struct task_struct *prev, struct rq_flags *rf p = task_of(se); done: __maybe_unused; + #ifdef CONFIG_SMP /* * Move the next running task to the front of @@ -6975,6 +6983,8 @@ done: __maybe_unused; if (hrtick_enabled(rq)) hrtick_start_fair(rq, p); + rq->cfs.avg.freeze_updates = 0; + p->se.avg.freeze_updates = 0; return p; idle: @@ -6991,6 +7001,7 @@ done: __maybe_unused; if (new_tasks > 0) goto again; + rq->cfs.avg.freeze_updates = 0; return NULL; } @@ -7006,6 +7017,18 @@ static void put_prev_task_fair(struct rq *rq, struct task_struct *prev) cfs_rq = cfs_rq_of(se); put_prev_entity(cfs_rq, se); } + + /* + * Task is being put because of preemption either by CFS or by a higher + * class. Make sure no util updates happen. + */ + if (!prev->state) { /* Task is put while running */ + rq->cfs.avg.freeze_updates = 1; + prev->se.avg.freeze_updates = 1; + } else { + rq->cfs.avg.freeze_updates = 0; + prev->se.avg.freeze_updates = 0; + } } /* -- 2.18.0.rc1.242.g61856ae69a-goog

7 years, 11 months

7
11
0 0

[Integration Branch] Update 8-June-2018

by Douglas Raillard

Hi, A new EAS integration branch created on June 8th is available on branch eas/next/integration here: http://linux-arm.org/git?p=linux-power.git For further information about main features, test coverage and work items for next integration please have a look at: https://developer.arm.com/open-source/energy-aware-scheduling/eas-mainline-… Best Regards, Douglas

7 years, 11 months

1
0
0 0

prefer_idle behavior in android-4.14

by Chris Redpath

Hi, Joel was looking at something else in android-4.14 wakeup path and he noticed that we have a difference in behavior for prefer_idle tasks when we're using find_best_target, so he asked if we could discuss that here. Behavior in android-4.9 and earlier ----------------------------------- When we find an idle CPU for a task which has the prefer_idle attribute, we immediately return that CPU from the energy-based wakeup CPU selection. This happens in slightly different places over the EAS and android versions but it is always true that we take the recommended idle CPU for tasks in this class. How that changed in android-4.14 -------------------------------- android-4.14 has two different wakeup paths, selected with a sched_feature FIND_BEST_TARGET. This defaults to true with the intent of preserving the previous behavior. Both paths are different, so I'll describe them below separately. The two paths however share some common code - the way we integrated EAS with the regular wakeup code is different in android-4.14. There were two reasons for doing this. 1. minimize the differences in select_task_rq_fair wrt mainline code 2. make better use of the per-sd overutilization flags Since we have per-sd overutilised flags, we attempt to perform an EAS wakeup at the highest non-overutilised sched_domain - meaning that we can still perform an energy-aware wakeup for small tasks inside a non-overutilized group of small CPUs while potentially other groups of CPUs are overutilized. The decision about attempting to use energy awareness is taken in wake_energy function at the top of strf - all the cases where we can't use energy-awareness are ruled out, and the decision about using find_idlest_cpu/EAS for prefer_idle tasks is also done here. If we are using energy aware wakeups, then we will find the highest non-overutilised SD to wake in. In all cases where we do an energy aware wakeup but don't find any suitable candidate CPUs we will go on to use find_idlest_cpu. android-4.14 sched_feat(FIND_BEST_TARGET) true wakeup path ---------------------------------------------------------- When FIND_BEST_TARGET sched feature is on (the default), we call find_best_target to populate the energy_env structure. This takes note of the prefer_idle flag and the task boost to change which task placement strategy will be used - the algorithm is the same as in previous versions of android. However in android-4.14 (unintentionally) the prefer_idle task placement is not immediately acted upon - when a prefer_idle task is placed, we will select the first idle CPU we see *but* this will become the target CPU and we will still perform an energy diff and select between prev/target based upon energy requirement. The open question is - now that we have realized that there is a different strategy in place, should we change it to be the same as the old version? I think that we should - it will be a simple change to use the idle cpu selected immediately without the energy diff. All we would need is to add something like this: --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7383,7 +7383,7 @@ static int find_energy_efficient_cpu(struct sched_domain *sd, } } else { int boosted = (schedtune_task_boost(p) > 0); - int prefer_idle; + int prefer_idle, target_cpu; /* * give compiler a hint that if sched_features @@ -7396,10 +7396,18 @@ static int find_energy_efficient_cpu(struct sched_domain *sd, eenv->max_cpu_count = EAS_CPU_BKP + 1; /* Find a cpu with sufficient capacity */ - eenv->cpu[EAS_CPU_NXT].cpu_id = find_best_target(p, + target_cpu = find_best_target(p, &eenv->cpu[EAS_CPU_BKP].cpu_id, boosted, prefer_idle); + /* immediately select idle CPUs for prefer-idle tasks */ + if (prefer_idle && target_cpu >= 0 && + idle_cpu(target_cpu))) + return target_cpu; + + /* place target into NEXT slot */ + eenv->cpu[EAS_CPU_NXT].cpu_id = target_cpu; + /* take note if no backup was found */ if (eenv->cpu[EAS_CPU_BKP].cpu_id < 0) eenv->max_cpu_count = EAS_CPU_BKP; It could be the case that there are energy advantages to performing an energy diff for prefer_idle tasks, we've tried a few times to come up with a way to use lower-energy CPUs for these tasks where possible (for cases like full-screen video playback or screen-off audio playback) without harming the interactive response, but we haven't managed to come up with anything which doesn't need per-platform tuning which isn't really suitable. The underlying requirement for these prefer_idle tasks is that they should ideally not be preempted as they are likely to be part of the critical frame drawing path. We should also note that the EAS_PREFER_IDLE sched_feature potentially also has an effect on this - if we are using find_best_target and we do not have EAS_PREFER_IDLE set to true (true is the default), then we don't pass the prefer_idle status of the task to find_best_target - however if EAS_PREFER_IDLE is not true, we should have avoided entering find_energy_efficient_cpu in the first place. To be complete, there is also a further sched_feat for task placement which controls how we evaluate the energy requirement for a task. If FBT_STRICT_ORDER is on (the default), we will select the first CPU we find which saves energy compared to the prev_cpu. This matches previous versions of android. We have been experimenting with selecting the most efficient out of the target/backup CPUs provided by find_best_target, if FBT_STRICT_ORDER is false this is what the scheduler will do. In testing there isn't really a clear winner out of these options, so I added the sched feature so users could play with the options easily on their platforms without code changes. android-4.14 sched_feat(FIND_BEST_TARGET) false wakeup path ----------------------------------------------------------- This uses the brute-force placement strategy from the pre-simplified-EM mainline EAS patch set, inside the android energy diff algorithm. In android, we collect all the potential CPU placement options in a data structure, and then evaluate the energy for all of them at each sched_domain traversal level. This is done to avoid visiting each domain & group more than once. Other than the switch to the new energy calculation method, the energy required is still calculated for every allowable CPU and then the option which has the lowest overall consumption is selected. When it comes to dealing with prefer_idle tasks, there is another optional behaviour in this mode. If you have sched_feat(EAS_PREFER_IDLE) set to true (the default), then prefer_idle tasks have no special treatment in the energy-aware wakeup path. This means they will get the lowest-energy option with no regard to idleness. However, if EAS_PREFER_IDLE is false (i.e. don't use EAS for prefer-idle tasks) then we route these tasks through the slow path wakeup code - the decision is made inside wake_energy, which propagates through to calling find_idlest_cpu instead of find_energy_efficient_cpu. If the find_best_target feature FBT_STRICT_ORDER is true (the default) then the first CPU which saves energy compared to default will be selected rather than the most efficient. When combined with the brute force selection algorithm, this will result in the lowest-numbered cpu which saves energy over the prev_cpu being selected. This is not the way that the brute force (mainline-alike) placement is intended to work, so when using brute force (FIND_BEST_TARGET=false) one should also turn off strict ordering (FBT_STRICT_ORDER=false) *and* opt out of using EAS for prefer_idle tasks (EAS_PREFER_IDLE=false). --Chris

7 years, 11 months

5
8
0 0

Android kernel 4.14: warning in walt_fixup_busy_time()

by Leo Yan

Hi all, I can reproduce the warning from WALT function walt_fixup_busy_time() in Android kernel 4.14 on Hikey960 board. The detailed log is as below. To trigger this issue, I usually reboot the board for multiple times: 'while true; do adb reboot; sleep 30; done' and at the boot time this issue can be reproduced. Before dig into this, I share the log to check in case we have the fixing yet for it. Thanks, Leo Yan --- log --- console:/ $ [ 9.260172] read descriptors [ 9.263096] read strings [ 9.267978] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11) [ 9.272518] wlcore: loaded [ 9.348146] random: crng init done [ 9.351604] random: 7 urandom warning(s) missed due to ratelimiting [ 10.079584] configfs-gadget gadget: high-speed config #1: b [ 10.189563] ------------[ cut here ]------------ [ 10.194275] WARNING: CPU: 0 PID: 0 at kernel/sched/walt.c:888 walt_fixup_busy_time+0x3a4/0x418 [ 10.202976] Modules linked in: [ 10.206069] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G S 4.14.41-01140-gd1e4c9f #199 [ 10.214856] Hardware name: HiKey960 (DT) [ 10.218816] task: ffffff8009829700 task.stack: ffffff8009810000 [ 10.224798] PC is at walt_fixup_busy_time+0x3a4/0x418 [ 10.229912] LR is at walt_fixup_busy_time+0x108/0x418 [ 10.235031] pc : [<ffffff8008141844>] lr : [<ffffff80081415a8>] pstate: 004001c5 [ 10.242516] sp : ffffff80080039c0 [ 10.245871] x29: ffffff80080039c0 x28: 000000025f283b70 [ 10.251260] x27: ffffff8009426000 x26: 000000025f2896fe [ 10.256648] x25: ffffff800981a0ec x24: ffffff800981a0ec [ 10.262037] x23: ffffff800981ae08 x22: ffffff8009426880 [ 10.267425] x21: ffffffc21ff23880 x20: ffffffc21ff4f880 [ 10.272811] x19: ffffffc211a58080 x18: 0000000000000000 [ 10.278198] x17: 000000743dc998e0 x16: ffffff80082ba168 [ 10.283586] x15: 0000000000000000 x14: 0000000200000000 [ 10.288973] x13: 0000000000000013 x12: 0000000000000688 [ 10.294361] x11: 0000000000000040 x10: ffffffc211c00268 [ 10.299749] x9 : ffffffc211c00458 x8 : ffffffc210347800 [ 10.305136] x7 : ffffffc209978c00 x6 : 0000000001ac37ab [ 10.310523] x5 : 0000000000000000 x4 : ffffffc212221080 [ 10.315911] x3 : 0000000000000000 x2 : ffffff800981a0ec [ 10.321298] x1 : 0000000000568aff x0 : ffffffffffff1f1d [ 10.326689] [ 10.326689] X0: 0xffffffffffff1e9d: [ 10.331715] 1e9c [ 10.331730] ******** [ 10.333681] ******** [ 10.335983] ******** [ 10.338284] ******** [ 10.340586] ******** [ 10.342888] ******** [ 10.345190] ******** [ 10.347491] ******** [ 10.349791] [ 10.353593] 1ebc [ 10.353601] ******** [ 10.355551] ******** [ 10.357852] ******** [ 10.360154] ******** [ 10.362456] ******** [ 10.364759] ******** [ 10.367060] ******** [ 10.369361] ******** [ 10.371661] [ 10.375463] 1edc [ 10.375471] ******** [ 10.377422] ******** [ 10.379722] ******** [ 10.382025] ******** [ 10.384327] ******** [ 10.386628] ******** [ 10.388930] ******** [ 10.391231] ******** [ 10.393531] [ 10.397333] 1efc [ 10.397341] ******** [ 10.399291] ******** [ 10.401592] ******** [ 10.403894] ******** [ 10.406195] ******** [ 10.408496] ******** [ 10.410797] ******** [ 10.413098] ******** [ 10.415398] [ 10.419200] 1f1c [ 10.419208] ******** [ 10.421158] ******** [ 10.423459] ******** [ 10.425761] ******** [ 10.428064] ******** [ 10.430365] ******** [ 10.432666] ******** [ 10.434968] ******** [ 10.437267] [ 10.441069] 1f3c [ 10.441077] ******** [ 10.443027] ******** [ 10.445329] ******** [ 10.447631] ******** [ 10.449932] ******** [ 10.452234] ******** [ 10.454535] ******** [ 10.456838] ******** [ 10.459138] [ 10.462939] 1f5c [ 10.462948] ******** [ 10.464898] ******** [ 10.467200] ******** [ 10.469501] ******** [ 10.471802] ******** [ 10.474104] ******** [ 10.476406] ******** [ 10.478707] ******** [ 10.481007] [ 10.484808] 1f7c [ 10.484816] ******** [ 10.486766] ******** [ 10.489068] ******** [ 10.491370] ******** [ 10.493671] ******** [ 10.495972] ******** [ 10.498275] ******** [ 10.500576] ******** [ 10.502876] [ 10.506677] 1f9c [ 10.506685] ******** [ 10.508635] ******** [ 10.510937] ******** [ 10.513238] ******** [ 10.515540] ******** [ 10.517841] ******** [ 10.520143] ******** [ 10.522444] ******** [ 10.524744] [ 10.528550] [ 10.528550] X4: 0xffffffc212221000: [ 10.533575] 1000 [ 10.533583] ffffffff [ 10.535533] ffffefff [ 10.537834] ffdfffff [ 10.540135] ffff7dff [ 10.542436] ffffffff [ 10.544738] ffffffff [ 10.547038] f7ffdfff [ 10.549339] f7ffffff [ 10.551639] [ 10.555441] 1020 [ 10.555448] ffffffff [ 10.557397] ffffffff [ 10.559698] ffffffff [ 10.561998] ffffffff [ 10.564300] ffffffff [ 10.566601] fffdffff [ 10.568901] fff7dfff [ 10.571203] ffffffdf [ 10.573502] [ 10.577303] 1040 [ 10.577311] ffffffff [ 10.579260] f7ffffff [ 10.581561] ffffffff [ 10.583863] ffffffff [ 10.586164] fffbffff [ 10.588465] ffffffef [ 10.590766] dfffffff [ 10.593067] ffffffff [ 10.595366] [ 10.599167] 1060 [ 10.599175] ffdffffe [ 10.601123] dfffffdf [ 10.603424] ffffffff [ 10.605725] ffffffff [ 10.608025] ffffffff [ 10.610326] ffffffff [ 10.612627] ffffffff [ 10.614928] fffeffff [ 10.617228] [ 10.621030] 1080 [ 10.621037] 00000020 [ 10.622987] 00000000 [ 10.625288] ffffffff [ 10.627588] 0000007f [ 10.629889] 019b3000 [ 10.632189] 00000000 [ 10.634490] 00010002 [ 10.636791] 00000000 [ 10.639091] [ 10.642892] 10a0 [ 10.642899] 00000000 [ 10.644849] 00000000 [ 10.647150] 09ad0000 [ 10.649452] ffffff80 [ 10.651753] 00000002 [ 10.654054] 00200042 [ 10.656354] 00000000 [ 10.658655] 00000000 [ 10.660954] [ 10.664757] 10c0 [ 10.664765] 00000000 [ 10.666714] 00000000 [ 10.669016] 00000001 [ 10.671317] 00000002 [ 10.673618] 00000003 [ 10.675920] 00000000 [ 10.678220] fffee3fd [ 10.680521] 00000000 [ 10.682820] [ 10.686622] 10e0 [ 10.686630] 048ff000 [ 10.688579] ffffffc2 [ 10.690880] 00000002 [ 10.693180] 00000001 [ 10.695480] 00000078 [ 10.697781] 00000078 [ 10.700082] 00000078 [ 10.702383] 00000000 [ 10.704682] [ 10.708489] [ 10.708489] X7: 0xffffffc209978b80: [ 10.713515] 8b80 [ 10.713522] 00000000 [ 10.715472] 00000000 [ 10.717773] 00000000 [ 10.720074] 00000000 [ 10.722375] 00000000 [ 10.724675] 00000000 [ 10.726976] 00000000 [ 10.729276] 00000000 [ 10.731575] [ 10.735376] 8ba0 [ 10.735383] 00000000 [ 10.737332] 00000000 [ 10.739632] 00000000 [ 10.741934] 00000000 [ 10.744233] 00000000 [ 10.746534] 00000000 [ 10.748834] 00000000 [ 10.751135] 00000000 [ 10.753434] [ 10.757236] 8bc0 [ 10.757244] 00000000 [ 10.759193] 00000000 [ 10.761494] 00000000 [ 10.763794] 00000000 [ 10.766095] 00000000 [ 10.768396] 00000000 [ 10.770696] 00000000 [ 10.772997] 00000000 [ 10.775296] [ 10.779096] 8be0 [ 10.779104] 00000000 [ 10.781054] 00000000 [ 10.783354] 00000000 [ 10.785655] 00000000 [ 10.787956] 00000000 [ 10.790256] 00000000 [ 10.792556] 00000000 [ 10.794857] 00000000 [ 10.797157] [ 10.800957] 8c00 [ 10.800965] 087290c0 [ 10.802915] ffffffbf [ 10.805216] 00001000 [ 10.807517] 00000000 [ 10.809818] 08729080 [ 10.812119] ffffffbf [ 10.814420] 00001000 [ 10.816720] 00000000 [ 10.819020] [ 10.822822] 8c20 [ 10.822829] 08729040 [ 10.824779] ffffffbf [ 10.827079] 00001000 [ 10.829380] 00000000 [ 10.831681] 08729000 [ 10.833981] ffffffbf [ 10.836282] 00001000 [ 10.838583] 00000000 [ 10.840882] [ 10.844683] 8c40 [ 10.844691] 08728fc0 [ 10.846640] ffffffbf [ 10.848941] 00001000 [ 10.851242] 00000000 [ 10.853542] 08728f80 [ 10.855844] ffffffbf [ 10.858144] 00001000 [ 10.860445] 00000000 [ 10.862744] [ 10.866545] 8c60 [ 10.866553] 08728f40 [ 10.868503] ffffffbf [ 10.870804] 00001000 [ 10.873105] 00000000 [ 10.875406] 08728f00 [ 10.877707] ffffffbf [ 10.880007] 00001000 [ 10.882308] 00000000 [ 10.884608] [ 10.888413] [ 10.888413] X8: 0xffffffc210347780: [ 10.893439] 7780 [ 10.893446] 00000000 [ 10.895396] 00000000 [ 10.897696] 00000000 [ 10.899997] 00000000 [ 10.902298] 00000000 [ 10.904598] 00000000 [ 10.906900] 00000000 [ 10.909200] 00000000 [ 10.911499] [ 10.915301] 77a0 [ 10.915308] 00000000 [ 10.917257] 00000000 [ 10.919557] 00000000 [ 10.921859] 00000000 [ 10.924160] 00000000 [ 10.926460] 00000000 [ 10.928761] 00000000 [ 10.931061] 00000000 [ 10.933361] [ 10.937163] 77c0 [ 10.937170] 00000000 [ 10.939120] 00000000 [ 10.941421] 00000000 [ 10.943722] 00000000 [ 10.946022] 00000000 [ 10.948323] 00000000 [ 10.950623] 00000000 [ 10.952923] 00000000 [ 10.955223] [ 10.959025] 77e0 [ 10.959032] 00000000 [ 10.960982] 00000000 [ 10.963282] 00000000 [ 10.965583] 00000000 [ 10.967883] 00000000 [ 10.970183] 00000000 [ 10.972484] 00000000 [ 10.974785] 00000000 [ 10.977084] [ 10.980884] 7800 [ 10.980892] 10341800 [ 10.982841] ffffffc2 [ 10.985142] 11522800 [ 10.987443] ffffffc2 [ 10.989743] 10340d00 [ 10.992044] ffffffc2 [ 10.994345] 00000008 [ 10.996646] 00000000 [ 10.998945] [ 11.002746] 7820 [ 11.002754] 00000010 [ 11.004703] 00000000 [ 11.007004] 00000020 [ 11.009305] 0000007d [ 11.011606] 00000001 [ 11.013907] 00000002 [ 11.016207] 00000001 [ 11.018508] 00000000 [ 11.020807] [ 11.024608] 7840 [ 11.024616] 00000000 [ 11.026566] 00000000 [ 11.028866] 00000000 [ 11.031167] 00000000 [ 11.033468] 0000107f [ 11.035769] 00000001 [ 11.038069] fffee4fa [ 11.040371] 00000000 [ 11.042671] [ 11.046473] 7860 [ 11.046481] 00000010 [ 11.048430] 00000000 [ 11.050730] 000086b6 [ 11.053031] 00000000 [ 11.055331] fffee5b6 [ 11.057632] 00000000 [ 11.059932] 00000000 [ 11.062233] 00000000 [ 11.064533] [ 11.068336] [ 11.068336] X9: 0xffffffc211c003d8: [ 11.073361] 03d8 [ 11.073370] 114cec00 [ 11.075319] ffffffc2 [ 11.077620] 114cea00 [ 11.079920] ffffffc2 [ 11.082221] 114ce800 [ 11.084522] ffffffc2 [ 11.086823] 114ce600 [ 11.089124] ffffffc2 [ 11.091423] [ 11.095225] 03f8 [ 11.095232] 114ce400 [ 11.097181] ffffffc2 [ 11.099482] 114ce200 [ 11.101783] ffffffc2 [ 11.104084] 114ce000 [ 11.106385] ffffffc2 [ 11.108686] 11514e00 [ 11.110987] ffffffc2 [ 11.113288] [ 11.117088] 0418 [ 11.117095] 11514c00 [ 11.119044] ffffffc2 [ 11.121346] 11514a00 [ 11.123647] ffffffc2 [ 11.125948] 11514600 [ 11.128250] ffffffc2 [ 11.130551] 11514400 [ 11.132852] ffffffc2 [ 11.135151] [ 11.138953] 0438 [ 11.138960] 11514200 [ 11.140910] ffffffc2 [ 11.143211] 11514000 [ 11.145513] ffffffc2 [ 11.147814] 11547e00 [ 11.150115] ffffffc2 [ 11.152415] 11547c00 [ 11.154716] ffffffc2 [ 11.157016] [ 11.160817] 0458 [ 11.160825] 11547a00 [ 11.162773] ffffffc2 [ 11.165075] 11547800 [ 11.167375] ffffffc2 [ 11.169676] 00000000 [ 11.171976] 00000000 [ 11.174277] 00000000 [ 11.176577] 00000000 [ 11.178877] [ 11.182679] 0478 [ 11.182686] 00000000 [ 11.184636] 00000000 [ 11.186936] 00000000 [ 11.189238] 00000000 [ 11.191539] 11c006c0 [ 11.193839] ffffffc2 [ 11.196142] 00000000 [ 11.198442] 00000000 [ 11.200741] [ 11.204543] 0498 [ 11.204550] 11c00498 [ 11.206501] ffffffc2 [ 11.208801] 11c00498 [ 11.211102] ffffffc2 [ 11.213402] 00000000 [ 11.215703] 00000000 [ 11.218003] 00000000 [ 11.220304] 00000000 [ 11.222603] [ 11.226405] 04b8 [ 11.226412] 00000000 [ 11.228361] 00000000 [ 11.230662] 00000000 [ 11.232964] 00000000 [ 11.235264] 00000000 [ 11.237565] 00000000 [ 11.239865] 00000000 [ 11.242166] 00000000 [ 11.244465] [ 11.248269] [ 11.248269] X10: 0xffffffc211c001e8: [ 11.253381] 01e8 [ 11.253389] 00000000 [ 11.255340] 00000000 [ 11.257640] 00000000 [ 11.259941] 00000000 [ 11.262242] 00000000 [ 11.264542] 00000000 [ 11.266843] 00000000 [ 11.269144] 00000000 [ 11.271444] [ 11.275245] 0208 [ 11.275252] 00000000 [ 11.277202] 00000000 [ 11.279502] 00000000 [ 11.281803] 00000000 [ 11.284104] 00000000 [ 11.286405] 00000000 [ 11.288705] 00000000 [ 11.291006] 00000000 [ 11.293305] [ 11.297106] 0228 [ 11.297114] fffc0000 [ 11.299063] ffffffff [ 11.301364] 00000000 [ 11.303665] 00000000 [ 11.305966] 00000000 [ 11.308267] 00000000 [ 11.310567] 003f0000 [ 11.312869] 00000000 [ 11.315168] [ 11.318969] 0248 [ 11.318977] 11c18240 [ 11.320926] ffffffc2 [ 11.323227] 0984b500 [ 11.325528] ffffff80 [ 11.327829] 11c00258 [ 11.330130] ffffffc2 [ 11.332430] 11c00258 [ 11.334731] ffffffc2 [ 11.337031] [ 11.340832] 0268 [ 11.340839] 00000000 [ 11.342789] 00000000 [ 11.345089] 12117200 [ 11.347390] ffffffc2 [ 11.349690] 12117400 [ 11.351991] ffffffc2 [ 11.354293] 12117600 [ 11.356594] ffffffc2 [ 11.358893] [ 11.362694] 0288 [ 11.362702] 12117800 [ 11.364651] ffffffc2 [ 11.366952] 12117a00 [ 11.369252] ffffffc2 [ 11.371554] 12117c00 [ 11.373854] ffffffc2 [ 11.376156] 11a4cc00 [ 11.378456] ffffffc2 [ 11.380755] [ 11.384556] 02a8 [ 11.384563] 11a4ca00 [ 11.386513] ffffffc2 [ 11.388813] 11a4c800 [ 11.391113] ffffffc2 [ 11.393415] 11a4c600 [ 11.395716] ffffffc2 [ 11.398018] 11a4c400 [ 11.400319] ffffffc2 [ 11.402618] [ 11.406420] 02c8 [ 11.406427] 11a4c200 [ 11.408377] ffffffc2 [ 11.410677] 11a4c000 [ 11.412978] ffffffc2 [ 11.415279] 11a4fe00 [ 11.417579] ffffffc2 [ 11.419880] 11a4fc00 [ 11.422181] ffffffc2 [ 11.424481] [ 11.428291] [ 11.428291] X19: 0xffffffc211a58000: [ 11.433403] 8000 [ 11.433410] ffffffff [ 11.435360] fdffffff [ 11.437660] ffffffff [ 11.439961] ffffffff [ 11.442262] efffffff [ 11.444562] fffffff9 [ 11.446863] ffffffff [ 11.449164] fffffdff [ 11.451463] [ 11.455264] 8020 [ 11.455271] ffffffff [ 11.457221] ffffffff [ 11.459521] ffffdfff [ 11.461822] ffffffff [ 11.464122] ffffffff [ 11.466422] fffffbff [ 11.468723] effffffe [ 11.471023] fffffeff [ 11.473323] [ 11.477125] 8040 [ 11.477133] ffffffff [ 11.479082] 7fffffff [ 11.481383] fff7ffff [ 11.483684] ffffffef [ 11.485985] ffffffff [ 11.488286] ffffffff [ 11.490586] ffdff7ff [ 11.492886] ffffffff [ 11.495185] [ 11.498987] 8060 [ 11.498994] ffffffff [ 11.500944] ffffffff [ 11.503245] ffffffff [ 11.505546] ffffffff [ 11.507846] ffffffff [ 11.510147] ffffffff [ 11.512447] ffffffff [ 11.514747] dfffffff [ 11.517046] [ 11.520847] 8080 [ 11.520855] 00400000 [ 11.522804] 00000000 [ 11.525105] ffffffff [ 11.527406] 0000007f [ 11.529707] 0e2b5000 [ 11.532008] 00660002 [ 11.534308] 00000002 [ 11.536609] 00000000 [ 11.538909] [ 11.542710] 80a0 [ 11.542718] 00000200 [ 11.544667] 00000000 [ 11.546968] 0dc38000 [ 11.549269] ffffff80 [ 11.551570] 00000002 [ 11.553870] 00404100 [ 11.556171] 00000000 [ 11.558471] 00000000 [ 11.560770] [ 11.564572] 80c0 [ 11.564580] 00000000 [ 11.566529] 00000000 [ 11.568831] 00000000 [ 11.571132] 00000002 [ 11.573432] 00000031 [ 11.575732] 00000000 [ 11.578032] fffee4b8 [ 11.580334] 00000000 [ 11.582633] [ 11.586436] 80e0 [ 11.586444] 121fc000 [ 11.588393] ffffffc2 [ 11.590694] 00000002 [ 11.592993] 00000000 [ 11.595294] 00000064 [ 11.597594] 00000064 [ 11.599896] 00000064 [ 11.602196] 00000000 [ 11.604495] [ 11.608300] [ 11.608300] X20: 0xffffffc21ff4f800: [ 11.613411] f800 [ 11.613419] 00000000 [ 11.615368] 00000000 [ 11.617668] 00000000 [ 11.619969] 00000000 [ 11.622269] 00000000 [ 11.624569] 00000000 [ 11.626869] 00000000 [ 11.629170] 00000000 [ 11.631469] [ 11.635270] f820 [ 11.635278] 00000000 [ 11.637227] 00000000 [ 11.639528] 00000000 [ 11.641828] 00000000 [ 11.644129] 00000000 [ 11.646429] 00000000 [ 11.648730] 00000000 [ 11.651030] 00000000 [ 11.653330] [ 11.657132] f840 [ 11.657139] 00000000 [ 11.659089] 00000000 [ 11.661390] 00000000 [ 11.663691] 00000000 [ 11.665991] 00000000 [ 11.668291] 00000000 [ 11.670592] 00000000 [ 11.672892] 00000000 [ 11.675191] [ 11.678992] f860 [ 11.678999] 00000000 [ 11.680948] 00000000 [ 11.683248] 00000000 [ 11.685549] 00000000 [ 11.687850] 00000000 [ 11.690150] 00000000 [ 11.692451] 00000000 [ 11.694751] 00000000 [ 11.697051] [ 11.700851] f880 [ 11.700858] 37883784 [ 11.702809] 00000000 [ 11.705109] 000006bf [ 11.707409] 00000000 [ 11.709709] 00001331 [ 11.712010] 00000000 [ 11.714311] 000022e4 [ 11.716612] 00000000 [ 11.718911] [ 11.722713] f8a0 [ 11.722720] 000022dd [ 11.724669] 00000000 [ 11.726970] 00002332 [ 11.729271] 00000000 [ 11.731572] fffee4fb [ 11.733873] 00000000 [ 11.736174] fffee4fb [ 11.738474] 00000000 [ 11.740773] [ 11.744574] f8c0 [ 11.744581] 00000000 [ 11.746531] 00000000 [ 11.748831] 00000000 [ 11.751132] 00000000 [ 11.753433] 00000000 [ 11.755734] 00000000 [ 11.758034] 0000067d [ 11.760335] 00000000 [ 11.762634] [ 11.766436] f8e0 [ 11.766443] 000010bb [ 11.768392] 00000000 [ 11.770692] 00000000 [ 11.772992] 00000000 [ 11.775292] 00000000 [ 11.777593] 00000000 [ 11.779893] 00000000 [ 11.782195] 00000000 [ 11.784494] [ 11.788298] [ 11.788298] X21: 0xffffffc21ff23800: [ 11.793411] 3800 [ 11.793419] 00000000 [ 11.795368] 00000000 [ 11.797668] 00000000 [ 11.799968] 00000000 [ 11.802269] 00000000 [ 11.804569] 00000000 [ 11.806870] 00000000 [ 11.809170] 00000000 [ 11.811470] [ 11.815270] 3820 [ 11.815278] 00000000 [ 11.817227] 00000000 [ 11.819527] 00000000 [ 11.821828] 00000000 [ 11.824129] 00000000 [ 11.826430] 00000000 [ 11.828730] 00000000 [ 11.831031] 00000000 [ 11.833330] [ 11.837131] 3840 [ 11.837139] 00000000 [ 11.839089] 00000000 [ 11.841389] 00000000 [ 11.843691] 00000000 [ 11.845991] 00000000 [ 11.848292] 00000000 [ 11.850592] 00000000 [ 11.852893] 00000000 [ 11.855192] [ 11.858994] 3860 [ 11.859001] 00000000 [ 11.860950] 00000000 [ 11.863251] 00000000 [ 11.865551] 00000000 [ 11.867852] 00000000 [ 11.870152] 00000000 [ 11.872453] 00000000 [ 11.874753] 00000000 [ 11.877053] [ 11.880854] 3880 [ 11.880861] 211d211a [ 11.882810] 00000000 [ 11.885111] 0000ac72 [ 11.887412] 00000000 [ 11.889713] 00008d85 [ 11.892014] 00000000 [ 11.894315] 0000767f [ 11.896616] 00000000 [ 11.898915] [ 11.902717] 38a0 [ 11.902723] 00006169 [ 11.904673] 00000000 [ 11.906973] 00004561 [ 11.909275] 00000000 [ 11.911576] fffee4fb [ 11.913876] 00000000 [ 11.916178] fffee4fa [ 11.918478] 00000000 [ 11.920777] [ 11.924579] 38c0 [ 11.924586] 00000000 [ 11.926535] 00000000 [ 11.928836] 00000000 [ 11.931136] 00000000 [ 11.933437] 00000000 [ 11.935738] 00000000 [ 11.938041] 00000610 [ 11.940341] 00000000 [ 11.942641] [ 11.946442] 38e0 [ 11.946450] 000007b0 [ 11.948400] 00000000 [ 11.950701] 00000000 [ 11.953002] 00000000 [ 11.955302] 00000000 [ 11.957603] 00000000 [ 11.959903] 00000000 [ 11.962203] 00000000 [ 11.964502] [ 11.968310] [ 11.969822] Call trace: [ 11.972303] Exception stack(0xffffff8008003880 to 0xffffff80080039c0) [ 11.978829] 3880: ffffffffffff1f1d 0000000000568aff ffffff800981a0ec 0000000000000000 [ 11.986758] 38a0: ffffffc212221080 0000000000000000 0000000001ac37ab ffffffc209978c00 [ 11.994688] 38c0: ffffffc210347800 ffffffc211c00458 ffffffc211c00268 0000000000000040 [ 12.002618] 38e0: 0000000000000688 0000000000000013 0000000200000000 0000000000000000 [ 12.010547] 3900: ffffff80082ba168 000000743dc998e0 0000000000000000 ffffffc211a58080 [ 12.018476] 3920: ffffffc21ff4f880 ffffffc21ff23880 ffffff8009426880 ffffff800981ae08 [ 12.026406] 3940: ffffff800981a0ec ffffff800981a0ec 000000025f2896fe ffffff8009426000 [ 12.034335] 3960: 000000025f283b70 ffffff80080039c0 ffffff80081415a8 ffffff80080039c0 [ 12.042266] 3980: ffffff8008141844 00000000004001c5 ffffff800981ae08 ffffff800981a0ec [ 12.050194] 39a0: 0000007fffffffff 000000025f2896fe ffffff80080039c0 ffffff8008141844 [ 12.058126] [<ffffff8008141844>] walt_fixup_busy_time+0x3a4/0x418 [ 12.064298] [<ffffff800811d868>] set_task_cpu+0xc0/0x1f8 [ 12.069678] [<ffffff800811e3e4>] try_to_wake_up+0x234/0x4e0 [ 12.075322] [<ffffff800811e7b8>] default_wake_function+0x38/0x48 [ 12.081407] [<ffffff800813c12c>] autoremove_wake_function+0x3c/0x68 [ 12.087757] [<ffffff8008212f94>] wake_page_function+0x9c/0xa8 [ 12.093578] [<ffffff800813b79c>] __wake_up_common+0xa4/0x148 [ 12.099311] [<ffffff800813ba44>] __wake_up_locked_key_bookmark+0x44/0x58 [ 12.106096] [<ffffff8008213698>] wake_up_page_bit+0xa0/0x148 [ 12.111829] [<ffffff800821378c>] unlock_page+0x4c/0x58 [ 12.117036] [<ffffff80083844b0>] mpage_end_io+0xa8/0x1b0 [ 12.122422] [<ffffff800857046c>] bio_endio+0x154/0x190 [ 12.127628] [<ffffff8008578b7c>] blk_update_request+0xac/0x378 [ 12.133540] [<ffffff80087d7da0>] scsi_end_request+0x48/0x1c8 [ 12.139271] [<ffffff80087d80bc>] scsi_io_completion+0x19c/0x5b0 [ 12.145270] [<ffffff80087cf640>] scsi_finish_command+0xd0/0x120 [ 12.151266] [<ffffff80087d7788>] scsi_softirq_done+0x158/0x168 [ 12.157177] [<ffffff8008581fd8>] blk_done_softirq+0xb0/0xe8 [ 12.162825] [<ffffff8008081dbc>] __do_softirq+0x16c/0x3a8 [ 12.168295] [<ffffff80080ec46c>] irq_exit+0xc4/0xd8 [ 12.173239] [<ffffff8008156388>] __handle_domain_irq+0x90/0x100 [ 12.179232] [<ffffff8008081a70>] gic_handle_irq+0x60/0xb8 [ 12.184700] Exception stack(0xffffff8009813d00 to 0xffffff8009813e40) [ 12.191224] 3d00: ffffff8009829700 0000000000000001 0000004216ad1000 0000000000000001 [ 12.199153] 3d20: 0000004216ad1000 00ffffffffffffff 000000000081dade 0000000000000025 [ 12.207082] 3d40: ffffffc21fef6928 0000000000000013 ffffffc21fef6908 071c71c71c71c71c [ 12.215011] 3d60: 0000000000000688 0000000000000013 0000000200000000 0000000000000000 [ 12.222940] 3d80: ffffff80082ba168 000000743dc998e0 0000000000000000 000000025f572113 [ 12.230872] 3da0: 0000000000000000 ffffffc2103f2600 0000000000000000 ffffffc21139b000 [ 12.238801] 3dc0: 0000000000000000 000000025f56887c 0000000000000000 00000000bf34d218 [ 12.246731] 3de0: 0000000001300018 ffffff8009813e40 ffffff8008a33e28 ffffff8009813e40 [ 12.254660] 3e00: ffffff8008a33e2c 0000000060400145 ffffffc2103f2600 0000000000000000 [ 12.262589] 3e20: ffffffffffffffff 0000000000000000 ffffff8009813e40 ffffff8008a33e2c [ 12.270517] [<ffffff80080833ac>] el1_irq+0xec/0x194 [ 12.275460] [<ffffff8008a33e2c>] cpuidle_enter_state+0xb4/0x3a0 [ 12.281455] [<ffffff8008a3419c>] cpuidle_enter+0x34/0x48 [ 12.286839] [<ffffff800813caa8>] call_cpuidle+0x40/0x70 [ 12.292131] [<ffffff800813ce44>] do_idle+0x21c/0x278 [ 12.297160] [<ffffff800813d09c>] cpu_startup_entry+0x2c/0x30 [ 12.302897] [<ffffff8008e41220>] rest_init+0xd0/0xe0 [ 12.307932] [<ffffff8009300d98>] start_kernel+0x3f4/0x420 [ 12.313397] ---[ end trace c685021f9195e3be ]---

7 years, 11 months

3
2
0 0

[Integration Branch] Update 25-May-2018

by Douglas Raillard

Hi, A new EAS integration branch created on May 25th is available on branch eas/next/integration here: http://linux-arm.org/git?p=linux-power.git For further information about main features, test coverage and work items for next integration please have a look at: https://developer.arm.com/open-source/energy-aware-scheduling/eas-mainline-… Best Regards, Douglas

7 years, 11 months

1
1
0 0

[Integration Branch] Update 11-May-2018

by Douglas Raillard

Hi, A new EAS integration branch created on May 11th is available on branch eas/next/integration here: http://linux-arm.org/git?p=linux-power.git For further information about main features, test coverage and work items for next integration please have a look at: https://developer.arm.com/open-source/energy-aware-scheduling/eas-mainline-… Best Regards, Douglas

8 years

1
0
0 0

Re: [Eas-dev] IBM lotus-accounts

by Chris Samuel

Hi, Any updates to below emails,.? Regards Chris From: Chris Samuel [mailto:chris.samuel@lead-marketings.com] Sent: Thursday, April 05, 2018 10:16 AM To: 'eas-dev(a)lists.linaro.org' Subject: RE: IBM lotus-accounts 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.

8 years

1
0
0 0

[Integration Branch] Update 27-Apr-2018

by Douglas Raillard

Hi, A new EAS integration branch created on April 27th is available on branch eas/next/integration here: http://linux-arm.org/git?p=linux-power.git For further information about main features, test coverage and work items for next integration please have a look at: https://developer.arm.com/open-source/energy-aware-scheduling/eas-mainline-… Best Regards, Douglas

8 years

1
0
0 0

[Integration Branch] Update 13-Apr-2018

by Douglas Raillard

Hi, A new EAS integration branch created on April 13th is available on branch eas/next/integration here: http://linux-arm.org/git?p=linux-power.git For further information about main features, test coverage and work items for next integration please have a look at: https://developer.arm.com/open-source/energy-aware-scheduling/eas-mainline-… Best Regards, Douglas

8 years, 1 month

1
0
0 0

Test cases for EAS

by Erin Yang (楊雅婷)

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

8 years, 1 month

3
2
0 0

[Integration Branch] Update 30-Mar-2018

by Douglas Raillard

Hi, A new EAS integration branch created on March 30th is available on branch eas/next/integration here: http://linux-arm.org/git?p=linux-power.git For further information about main features, test coverage and work items for next integration please have a look at: https://developer.arm.com/open-source/energy-aware-scheduling/eas-mainline-… Best Regards, Douglas

8 years, 1 month

1
0
0 0

Re: [Eas-dev] IBM lotus-accounts

by Chris Samuel

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.

8 years, 1 month

1
0
0 0

IBM lotus-accounts

by Chris Samuel

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.

8 years, 1 month

1
0
0 0

eas question

by Jason Cren

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

8 years, 1 month

3
3
0 0

[PATCH 00/15] Energy computation optimization on android-4.9-eas-dev

by Leo Yan

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

8 years, 1 month

3
39
0 0

[Integration Branch] Update 16-Mar-2018

by Douglas Raillard

Hi, A new EAS integration branch is available on branch eas/next/integration here: http://linux-arm.org/git?p=linux-power.git For further information about main features, test coverage and work items for next integration please have a look at: https://developer.arm.com/open-source/energy-aware-scheduling/eas-mainline-… Best Regards, Douglas

8 years, 2 months

1
0
0 0

About group_idle_state estimation after energy_diff re-factor

by Ke Wang

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

8 years, 2 months

2
5
0 0

[RFC] find_best_target refactor items

by Ionela Voinescu

Hi, In an attempt to clarify and simplify find_best_target I've identified four areas that I believe might benefit from simplifications/clarifications/fixing. Please consider the ideas below as proposals towards this purpose. Also, consider these listed from narrow scope to broader scope. 1. Do not consider boost for !prefer_idle tasks, but always try to minimize capacity_orig. This was more or less done already by not having boosted and not-prefer idle tasks in typical Android configurations, but was never enforced in find_best_target code. This was discussed on this list as well in the "sched/fair: Prefer low capacity idle-CPU for boosted non-prefer-idle tasks" thread. Leo, Viresh, I would encourage you to push your patch to Gerrit and continue the discussion there, as it is a valid point on its own, and less controversial than the broader scope patch at 2. 2. Do not consider boost for prefer_idle tasks, but always try to maximize capacity_orig. This is the discussion that the patch at https://android-review.googlesource.com/c/kernel/common/+/636583 is trying to trigger, although in scope it touches on the point above as well. 3. Make order of CPUs irrelevant for CPU selection in find_best_target. This is a patch I'll try to push to Gerrit tomorrow after I have more test results. This will not incorporate code for any of the points above and it will try to mimic the selection of a CPU that is done now in find_best target. But if the points above are proven on their own, this fact will simplify the code for this item and make the implementation of the item at 2. unnecessary. 4. Remove the prefer_idle case from find_best_target. https://android-review.googlesource.com/q/topic:%22strf-mainline%22+(status… This has the broadest scope but it is more difficult to validate. Although broader scope items would make some narrow scope items unnecessary, they have value on their own if the boarder scope items cannot be proven in a reasonable amount of time, as they will provide fixes and support earlier than it takes to make a full re-factor of code. - 1 will provide valuable fixes now. - 2 will simplify find_best_target decision logic to facilitate and simplify 3. - 3 will add support for tri-gear platforms for which the current order of CPUs will be incorrect in some cases. - 4 will bring us closer to the mainline behavior. I'm adding the present of pretty pictures from what I call "validation by storm": I've created some kernels with combinations of the above items and tested them on a Pixel 2 device, just to make sure there are no important regressions introduced by them. But I believe all of these need to be validated independently to make sure we don't miss important corner cases. Results at https://gist.github.com/ionela-voinescu/f89815591c7f50864188094bb8c53ec4. Given that it's difficult for all involved to keep up with discussions on both gerrit and eas-dev, I'd suggest to discuss design and direction ideas as part of this thread and push patches and individual test references to android-review directly. Let me know what you think. All comments are welcomed! Best regards, Ionela.

8 years, 2 months

2
3
0 0

[PATCH 0/4] Consider RT Pressure for Energy Saving

by Leo Yan

Currently energy calculation in EAS has missed to consider RT pressure, it's quite possible to select CPU for CFS tasks which has high RT pressure and finally accumulate total utilization; as result the other low RT pressure CPUs lose chance to run CFS tasks and reduce contention between CFS and RT tasks, from performance view this is not optimal; furthermore this also harms power data due pack RT task and CFS task on single one CPU is more easily to trigger CPU frequency increasing. We can measure the summed CPU utilization and calculate the CPU freqency standard deviation to get to if the tasks can be well spreading within the same cluster for middle workload case. So below is the comparison result for video playback on Hikey960 for before and after applied this patch set (Using schedutil CPUFreq governor): Without Patch Set: With Patch Set: CPU Min(Util) Mean(Util) Mean(Util) | Min(Util) Mean(Util) Mean(Util) 0 7 67 205 | 8 52 170 1 4 53 227 | 9 47 188 2 4 57 191 | 8 38 192 3 4 35 165 | 16 47 146 s.d. 1.5 13.3 25.9 | 3.9 5.83 20.9 4 0 35 160 | 10 34 129 5 0 24 129 | 0 30 115 6 0 18 123 | 0 18 95 7 0 12 84 | 0 21 73 s.d. 0 9.8 31.2 | 5 7.5 24.4 The standard diviation for CPU utilization mean value has been decreased after applying this patch set (Little cluster: 13.3 vs 5.83, big cluster: 9.8 vs 7.5). This also confirm from the average CPU frequency: Without Patch Set: With Patch Set: Average Frequency | Average Frequency LITTLT Cluster 737MHz | 646MHz big Cluster 916MHz | 922MHz Leo Yan (4): sched/fair: Select maximum spare capacity for idle candidate CPUs sched: Introduce cpu_util_sum()/__cpu_util_sum() functions sched/fair: Consider RT pressure for find_best_target() sched/fair: Consider RT/DL pressure for energy calculation kernel/sched/fair.c | 22 +++++++++++++++++++--- kernel/sched/sched.h | 29 +++++++++++++++++++++++++++++ 2 files changed, 48 insertions(+), 3 deletions(-) -- 1.9.1

8 years, 2 months

4
13
0 0

eas-4.9-dev: regard of schedTune PE filter

by Leo Yan

Hi Patrick, I am reading the code for eas-4.9-dev branch [1], and found schedtune_accept_deltas() has been removed from fair.c. I think this is not purposed and might be wrongly removed by some optimization patch and should add back? Not sure if there have following patch to fix this. FYI. [1] https://android.googlesource.com/kernel/common/+/android-4.9-eas-dev/kernel… Thanks, Leo Yan

8 years, 2 months

1
0
0 0

[RESEND PATCH] sched/fair: consider RT/IRQ pressure in select_idle_sibling

by Rohit Jain

Currently fast path in the scheduler looks for an idle CPU to schedule threads on. Capacity is taken into account in the function 'select_task_rq_fair' when it calls 'wake_cap', however it ignores the instantaneous capacity and looks at the original capacity. Furthermore select_idle_sibling path of the code, ignores the RT/IRQ threads which are also running on the CPUs it is looking to schedule fair threads on. We don't necessarily have to force the code to go to slow path (by modifying wake_cap), instead we could do a better selection of the CPU in the current domain itself (i.e. in the fast path). This patch makes the fast path aware of capacity, resulting in overall performance improvements as shown in the test results. 1) KVM Test: ----------------------------------------------------------------------- In this test KVM is configured with a ubuntu VM (unchanged kernel, used Ubuntu server 16.04) which is running ping workload in a taskset along with hackbench in a separate taskset. The VM is a virtio VM (which means the host is taking and processing the interrupts). In this case, we want to avoid scheduling vcpus on CPUs which are very busy processing interrupts if there is a better choice available. This machine is a 2 socket 40 CPU 20 core Intel x86 machine. lscpu output: CPU(s): 40 On-line CPU(s) list: 0-39 Thread(s) per core: 2 Core(s) per socket: 10 Socket(s): 2 NUMA node(s): 2 NUMA node0 CPUs: 0-9,20-29 NUMA node1 CPUs: 10-19,30-39 The setup is realistic enough to mirror realistic use cases. KVM is bound to a full NUMA node with CPUs bound to whole cores, i.e. CPU 0 and 1 are bound to core 0, CPU 2 and 3 to core 1 and so on. virsh vcpupin output: VCPU: CPU Affinity ---------------------------------- 0: 0,20 1: 0,20 2: 1,21 3: 1,21 4: 2,22 5: 2,22 6: 3,23 7: 3,23 8: 4,24 9: 4,24 10: 5,25 11: 5,25 12: 6,26 13: 6,26 14: 7,27 15: 7,27 16: 8,28 17: 8,28 18: 9,29 19: 9,29 Here are the results seen with ping and hackbench running inside the KVM. Note: hackbench was run for 10000 loops (lower is better) (Improvement is show in brackets +ve is good, -ve is bad) +-------------------+-----------------+---------------------------+ | | Without patch | With patch | +---+-------+-------+-------+---------+-----------------+---------+ |FD | Groups| Tasks | Mean | Std Dev | Mean | Std Dev | +---+-------+-------+-------+---------+-----------------+---------+ |4 | 1 | 4 | 0.059 | 0.021 | 0.034 (+42.37%) | 0.008 | |4 | 2 | 8 | 0.087 | 0.031 | 0.075 (+13.79%) | 0.021 | |4 | 4 | 16 | 0.124 | 0.022 | 0.089 (+28.23%) | 0.013 | |4 | 8 | 32 | 0.149 | 0.031 | 0.126 (+15.43%) | 0.022 | +---+-------+-------+-------+---------+-----------------+---------+ |8 | 1 | 8 | 0.212 | 0.025 | 0.211 (+0.47%) | 0.023 | |8 | 2 | 16 | 0.246 | 0.055 | 0.225 (+8.54%) | 0.024 | |8 | 4 | 32 | 0.298 | 0.047 | 0.294 (+1.34%) | 0.022 | |8 | 8 | 64 | 0.407 | 0.03 | 0.378 (+7.13%) | 0.032 | +---+-------+-------+-------+---------+-----------------+---------+ |40 | 1 | 40 | 1.703 | 0.133 | 1.451 (+14.80%) | 0.072 | |40 | 2 | 80 | 2.912 | 0.204 | 2.431 (+16.52%) | 0.075 | +---+-------+-------+-------+---------+-----------------+---------+ 2) ping + hackbench test on x86 machine: ----------------------------------------------------------------------- Here hackbench is running in threaded mode along with, running ping on CPU 0 and 1 as: 'ping -l 10000 -q -s 10 -f hostX' This test is running on 2 socket, 20 core and 40 threads Intel x86 machine: runtime is in seconds (Lower is better) +-----------------------------+----------------+---------------------------+ | | Without patch | With patch | +----------+----+------+------+-------+--------+----------------+----------+ |Loops | FD |Groups|Tasks | Mean | Std Dev|Mean | Std Dev | +----------+----+------+------+-------+--------+----------------+----------+ |1,000,000 | 4 |1 |4 | 2.375 | 0.818 |1.785 (+24.84%) | 0.21 | |1,000,000 | 4 |2 |8 | 2.748 | 0.694 |2.102 (+23.51%) | 0.239 | |1,000,000 | 4 |4 |16 | 3.237 | 0.256 |2.922 (+9.73%) | 0.169 | |1,000,000 | 4 |8 |32 | 3.786 | 0.185 |3.637 (+3.94%) | 0.471 | +----------+----+------+------+-------+--------+----------------+----------+ |1,000,000 | 8 |1 |8 | 7.287 | 1.03 |5.364 (+26.39%) | 1.085 | |1,000,000 | 8 |2 |16 | 7.963 | 0.951 |6.474 (+18.70%) | 0.397 | |1,000,000 | 8 |4 |32 | 8.991 | 0.618 |8.32 (+7.46%) | 0.69 | |1,000,000 | 8 |8 |64 | 13.868| 1.195 |12.881 (+7.12%) | 0.722 | +----------+----+------+------+-------+--------+----------------+----------+ |10,000 | 40 |1 |40 | 0.828 | 0.032 |0.784 (+5.31%) | 0.010 | |10,000 | 40 |2 |80 | 1.087 | 0.246 |0.980 (+9.84%) | 0.037 | |10,000 | 40 |4 |160 | 1.611 | 0.055 |1.591 (+1.24%) | 0.039 | |10,000 | 40 |8 |320 | 2.827 | 0.031 |2.817 (+0.35%) | 0.025 | |10,000 | 40 |16 |640 | 5.107 | 0.085 |5.087 (+0.39%) | 0.045 | |10,000 | 40 |25 |1000 | 7.503 | 0.143 |7.468 (+0.46%) | 0.045 | +----------+----+------+------+-------+--------+----------------+----------+ Sanity tests: ----------------------------------------------------------------------- schbench results on 2 socket, 44 core and 88 threads Intel x86 machine, with 2 message threads (lower is better): +----------+-------------+----------+------------------+ |Threads | Latency | Without | With Patch | | | percentiles | Patch | | | | | (usec) | (usec) | +----------+-------------+----------+------------------+ |16 | 50.0000th | 60 | 62 (-3.33%) | |16 | 75.0000th | 72 | 68 (+5.56%) | |16 | 90.0000th | 81 | 80 (+2.46%) | |16 | 95.0000th | 88 | 83 (+5.68%) | |16 | *99.0000th | 100 | 92 (+8.00%) | |16 | 99.5000th | 105 | 97 (+7.62%) | |16 | 99.9000th | 110 | 100 (+9.09%) | +----------+-------------+----------+------------------+ |32 | 50.0000th | 62 | 62 (0%) | |32 | 75.0000th | 80 | 81 (0%) | |32 | 90.0000th | 93 | 94 (-1.07%) | |32 | 95.0000th | 103 | 105 (-1.94%) | |32 | *99.0000th | 121 | 121 (0%) | |32 | 99.5000th | 127 | 125 (+1.57%) | |32 | 99.9000th | 143 | 135 (+5.59%) | +----------+-------------+----------+------------------+ |44 | 50.0000th | 79 | 79 (0%) | |44 | 75.0000th | 104 | 104 (0%) | |44 | 90.0000th | 126 | 125 (+0.79%) | |44 | 95.0000th | 138 | 137 (+0.72%) | |44 | *99.0000th | 163 | 163 (0%) | |44 | 99.5000th | 174 | 171 (+1.72%) | |44 | 99.9000th | 10832 | 11248 (-3.84%) | +----------+-------------+----------+------------------+ I also ran uperf and sysbench MySQL workloads but I see no statistically significant change. Signed-off-by: Rohit Jain <rohit.k.jain(a)oracle.com> --- kernel/sched/fair.c | 38 ++++++++++++++++++++++++++++---------- 1 file changed, 28 insertions(+), 10 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 26a71eb..ce5ccf8 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -5625,6 +5625,11 @@ static unsigned long capacity_orig_of(int cpu) return cpu_rq(cpu)->cpu_capacity_orig; } +static inline bool full_capacity(int cpu) +{ + return capacity_of(cpu) >= (capacity_orig_of(cpu)*3)/4; +} + static unsigned long cpu_avg_load_per_task(int cpu) { struct rq *rq = cpu_rq(cpu); @@ -6081,7 +6086,7 @@ static int select_idle_core(struct task_struct *p, struct sched_domain *sd, int for_each_cpu(cpu, cpu_smt_mask(core)) { cpumask_clear_cpu(cpu, cpus); - if (!idle_cpu(cpu)) + if (!idle_cpu(cpu) || !full_capacity(cpu)) idle = false; } @@ -6102,7 +6107,8 @@ static int select_idle_core(struct task_struct *p, struct sched_domain *sd, int */ static int select_idle_smt(struct task_struct *p, struct sched_domain *sd, int target) { - int cpu; + int cpu, rcpu = -1; + unsigned long max_cap = 0; if (!static_branch_likely(&sched_smt_present)) return -1; @@ -6110,11 +6116,13 @@ static int select_idle_smt(struct task_struct *p, struct sched_domain *sd, int t for_each_cpu(cpu, cpu_smt_mask(target)) { if (!cpumask_test_cpu(cpu, &p->cpus_allowed)) continue; - if (idle_cpu(cpu)) - return cpu; + if (idle_cpu(cpu) && (capacity_of(cpu) > max_cap)) { + max_cap = capacity_of(cpu); + rcpu = cpu; + } } - return -1; + return rcpu; } #else /* CONFIG_SCHED_SMT */ @@ -6143,6 +6151,8 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int t u64 time, cost; s64 delta; int cpu, nr = INT_MAX; + int best_cpu = -1; + unsigned int best_cap = 0; this_sd = rcu_dereference(*this_cpu_ptr(&sd_llc)); if (!this_sd) @@ -6173,8 +6183,15 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int t return -1; if (!cpumask_test_cpu(cpu, &p->cpus_allowed)) continue; - if (idle_cpu(cpu)) - break; + if (idle_cpu(cpu)) { + if (full_capacity(cpu)) { + best_cpu = cpu; + break; + } else if (capacity_of(cpu) > best_cap) { + best_cap = capacity_of(cpu); + best_cpu = cpu; + } + } } time = local_clock() - time; @@ -6182,7 +6199,7 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int t delta = (s64)(time - cost) / 8; this_sd->avg_scan_cost += delta; - return cpu; + return best_cpu; } /* @@ -6193,13 +6210,14 @@ static int select_idle_sibling(struct task_struct *p, int prev, int target) struct sched_domain *sd; int i; - if (idle_cpu(target)) + if (idle_cpu(target) && full_capacity(target)) return target; /* * If the previous cpu is cache affine and idle, don't be stupid. */ - if (prev != target && cpus_share_cache(prev, target) && idle_cpu(prev)) + if (prev != target && cpus_share_cache(prev, target) && idle_cpu(prev) && + full_capacity(prev)) return prev; sd = rcu_dereference(per_cpu(sd_llc, target)); -- 2.7.4

8 years, 2 months

4
17
0 0

[PATCH android-4.9] sched/fair: Prefer low capacity idle-CPU for boosted non-prefer-idle tasks

by Viresh Kumar

From: Leo Yan <leo.yan(a)linaro.org> The homescreen test-case shows unwanted disturbance on the big CPUs on the Hikey620 platform with Android 4.9. There are multiple reasons for that though. By default boost and prefer_idle are enabled for both top-app and foreground tasks and find_best_target() always (intentionally) prefers the big CPUs if prefer_idle is enabled. And some of the foreground tasks (like: DispSync, PowerManagerSer and PhotonicModulat) for the homescreen test-case get placed on the big CPUs eventually because of that. Even if prefer_idle is disabled for such foreground tasks, they don't end up on the little CPUs. The reason being that find_best_target() still prefers big CPUs if the task is boosted, though some of the comments in find_best_target() routine say the exact opposite of that. It eventually depends on the order in which CPUs are processed, which is from big to little for boosted tasks. This patch updates the find_best_target() routine to select low capacity idle-CPU if the task is boosted but doesn't have prefer_idle enabled. This would be the same for non-boosted tasks as well. Signed-off-by: Leo Yan <leo.yan(a)linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- kernel/sched/fair.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index e45047bdd245..4534d8620989 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -6998,8 +6998,11 @@ static inline int find_best_target(struct task_struct *p, int *backup_cpu, int idle_idx = idle_get_state_idx(cpu_rq(i)); /* Select idle CPU with lower cap_orig */ - if (capacity_orig > best_idle_min_cap_orig) + if (capacity_orig < best_idle_min_cap_orig) + goto found_best_idle_cpu; + else if (capacity_orig > best_idle_min_cap_orig) continue; + /* Favor CPUs that won't end up running at a * high OPP. */ @@ -7017,6 +7020,7 @@ static inline int find_best_target(struct task_struct *p, int *backup_cpu, best_idle_cstate <= idle_idx) continue; +found_best_idle_cpu: /* Keep track of best idle CPU */ best_idle_min_cap_orig = capacity_orig; target_idle_max_spare_cap = capacity_orig - -- 2.15.0.194.g9af6a3dea062

8 years, 2 months

7
34
0 0

[PATCH] sched/fair: Use task's boosted util while calculating new_util of CPU

by Viresh Kumar

find_best_target() tries to find the target CPU where the task should be placed, based on how much would be the utilization of the CPU after the task is placed on it. This is represented by 'new_util' in the routine. Currently it adds task_util(p) to the wake_util of the CPU to find that out, while it should really be adding the boosted task's util to wake_util, as that's how much the cpu utilization would be. This is how we used to do it before commit 3bfde3b4f848 ("ANDROID: sched/fair: Change cpu iteration order in find_best_target()"), was merged and the commit doesn't describe the rational behind this change. This patch reverts to the earlier formula to calculate the new_util. Fixes: 3bfde3b4f848 ("ANDROID: sched/fair: Change cpu iteration order in find_best_target()") Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- Just wanted to get some review done over the list before posting it to gerrit. Not sure if this commit is doing the right thing, but I couldn't understand why it should be done this way. This is for the Android 4.9 EAS dev kernel. kernel/sched/fair.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 88abd5de69ce..1c33a2ddd39c 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -6860,14 +6860,13 @@ static inline int find_best_target(struct task_struct *p, int *backup_cpu, * accounting. However, the blocked utilization may be zero. */ wake_util = cpu_util_wake(i, p); - new_util = wake_util + task_util(p); /* * Ensure minimum capacity to grant the required boost. * The target CPU can be already at a capacity level higher * than the one required to boost the task. */ - new_util = max(min_util, new_util); + new_util = wake_util + min_util; /* * Include minimum capacity constraint: -- 2.15.0.194.g9af6a3dea062

8 years, 2 months

4
6
0 0

[Integration Branch] Update 02-Mar-2018

by Douglas Raillard

Hi, A new EAS integration branch is available on branch eas/next/integration here: http://linux-arm.org/git?p=linux-power.git For further information about main features, test coverage and work items for next integration please have a look at: https://developer.arm.com/open-source/energy-aware-scheduling/eas-mainline-… Best Regards, Douglas

8 years, 2 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

eas-dev