- eas-dev - lists.linaro.org

[Integration Branch] Update 23-November-2018

by Douglas Raillard

Hi, A new EAS integration branch created for November 23th 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, 6 months

1
0
0 0

[Integration Branch] Update 09-November-2018

by Douglas Raillard

Hi, A new EAS integration branch created for November 9th 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, 6 months

1
0
0 0

LISA and tracing EAS over usb-eth on HiKey960 board

by Lukasz Luba

Hi ARM folks, Does the branch 'eas/next/integration_20181109_0000', which has hikey topic, support USB gadget Ethernet connection? I found some issues while running Debian with sshd on Hikey960. I have been trying to connect LISA over usb eth gadget on ssh and I noticed that USB gadget is disabled by Valentin's patch: http://linux-arm.org/git?p=linux-power.git;a=commitdiff;h=81f0a7cdd7171dbf3… I have tried to configure the kernel with this gadget again, but it does not appear as eth device. Dmesg shows some warnings: [ 11.592012] dwc3_otg_work: dwc3 is not otg mode! How do you connect this board to LISA? Regards, Lukasz

7 years, 6 months

3
5
0 0

[Integration Branch] Update 26-October-2018

by Douglas Raillard

Hi, A new EAS integration branch created for October 26th 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, 7 months

1
0
0 0

eas-dev 您好！请问您那边需要开票给您客户么？需要可以找我代开

by 客服：小彬

2018/11/29:58 价格优美   价格实惠值班电话：1565-2790-356  有需求咨询客服微信：1565-2790-356   eas-dev

7 years, 7 months

1
0
0 0

[Integration Branch] Update 12-October-2018

by Dietmar Eggemann

Hi, A new EAS integration branch created for September 28th 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, Dietmar

7 years, 7 months

1
1
0 0

[Integration Branch] Update 28-September-2018

by Douglas Raillard

Hi, A new EAS integration branch created for September 28th 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, 8 months

1
0
0 0

[RFC][PATCH 3/3] drivers: hackbench_speedup: remove locking

by Lukasz Luba

When there is no call to mutex_unlock(), there is not speed-up. Signed-off-by: Lukasz Luba <l.luba(a)partner.samsung.com> --- drivers/base/hackbench_speedup.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/base/hackbench_speedup.c b/drivers/base/hackbench_speedup.c index 952df47..f8b3c40 100644 --- a/drivers/base/hackbench_speedup.c +++ b/drivers/base/hackbench_speedup.c @@ -38,9 +38,9 @@ static int task_container_status(struct task_data *master) return -EINVAL; list_for_each_entry(td, &master->subtasks, subtasks) { - mutex_lock(&td->lock); + /* mutex_lock(&td->lock); */ /* get status */ - mutex_unlock(&td->lock); + /* mutex_unlock(&td->lock); */ } @@ -62,9 +62,9 @@ static void task_status_check(struct work_struct *work) if (!td->get_status) return; - mutex_lock(&td->lock); + /* mutex_lock(&td->lock); */ ret = td->get_status(td); - mutex_unlock(&td->lock); + /* mutex_unlock(&td->lock); */ mod_delayed_work(system_freezable_wq, &td->wq, msecs_to_jiffies(POLLING_DELAY)); -- 2.7.4

7 years, 8 months

1
0
0 0

[RFC][PATCH 2/3] drivers: base: add hackbench_speedup as a module

by Lukasz Luba

This patch is only for testing odd behavior of hackbench. Signed-off-by: Lukasz Luba <l.luba(a)partner.samsung.com> --- drivers/base/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/base/Makefile b/drivers/base/Makefile index e32a524..d25afa5 100644 --- a/drivers/base/Makefile +++ b/drivers/base/Makefile @@ -30,3 +30,4 @@ obj-y += test/ ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG +obj-m += hackbench_speedup.o -- 2.7.4

7 years, 8 months

1
0
0 0

[RFC][PATCH 1/3] drivers: base: add test module hackbench speedup

by Lukasz Luba

This is an odd module which speeds up hackbench test. It tries to behave like /drivers/thermal subsystem with a container thermal zone looping over normal thermal zones. Test description: - run hackbench on ARM64 with big.LITTLE: $ ./hackbench 100 process 100 - then load this module $ insmod ./hackbench_speedup.ko - then run hackbench once again $ ./hackbench 100 process 100 - unload the module, you can run the hackbench after that and the result will be the same (shorter time) $ rmmod hackbench_speedup Some results captured on my ARM64 (4big + 4LITTLE) machine: root@draco:~# /root/devlib-target/hackbench 100 process 100 Running with 100*40 (== 4000) tasks. Time: 11.207 root@draco:~# /root/devlib-target/hackbench 100 process 100 Running with 100*40 (== 4000) tasks. Time: 11.029 root@draco:~# /root/devlib-target/hackbench 100 process 100 Running with 100*40 (== 4000) tasks. Time: 11.452 root@draco:~# /root/devlib-target/hackbench 100 process 100 Running with 100*40 (== 4000) tasks. Time: 10.522 root@draco:~# /root/devlib-target/hackbench 100 process 100 Running with 100*40 (== 4000) tasks. Time: 12.044 root@draco:~# /root/devlib-target/hackbench 100 process 100 Running with 100*40 (== 4000) tasks. Time: 11.532 root@draco:~# root@draco:~# insmod ./hackbench_speedup.ko root@draco:~# root@draco:~# /root/devlib-target/hackbench 100 process 100 Running with 100*40 (== 4000) tasks. Time: 6.474 root@draco:~# /root/devlib-target/hackbench 100 process 100 Running with 100*40 (== 4000) tasks. Time: 6.477 root@draco:~# /root/devlib-target/hackbench 100 process 100 Running with 100*40 (== 4000) tasks. Time: 6.294 root@draco:~# /root/devlib-target/hackbench 100 process 100 Running with 100*40 (== 4000) tasks. Time: 6.237 Signed-off-by: Lukasz Luba <l.luba(a)partner.samsung.com> --- drivers/base/hackbench_speedup.c | 148 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 148 insertions(+) create mode 100644 drivers/base/hackbench_speedup.c diff --git a/drivers/base/hackbench_speedup.c b/drivers/base/hackbench_speedup.c new file mode 100644 index 0000000..952df47 --- /dev/null +++ b/drivers/base/hackbench_speedup.c @@ -0,0 +1,148 @@ + + +#define pr_fmt(fmt) "HACKBENCH: " fmt + +#include <linux/jiffies.h> +#include <linux/module.h> +#include <linux/slab.h> +#include <linux/workqueue.h> + +#define POLLING_DELAY 1000 + +struct task_data { + int id; + struct delayed_work wq; + struct mutex lock; + int polling_delay; + struct list_head node; + struct list_head subtasks; + bool container; + int (*get_status)(struct task_data *td); +}; + + +static LIST_HEAD(tasks_list); +static DEFINE_MUTEX(tasks_list_lock); + + +static int task_container_status(struct task_data *master) +{ + struct task_data *td; + + pr_info("container task status\n"); + + if (!master || !master->container) + return -EINVAL; + + if (list_empty(&master->subtasks)) + return -EINVAL; + + list_for_each_entry(td, &master->subtasks, subtasks) { + mutex_lock(&td->lock); + /* get status */ + mutex_unlock(&td->lock); + } + + + return 0; +} + +static int task_status(struct task_data *td) +{ + pr_info("single task status\n"); + + return 0; +} + +static void task_status_check(struct work_struct *work) +{ + int ret; + struct task_data *td = container_of(work, struct task_data, wq.work); + + if (!td->get_status) + return; + + mutex_lock(&td->lock); + ret = td->get_status(td); + mutex_unlock(&td->lock); + + mod_delayed_work(system_freezable_wq, &td->wq, + msecs_to_jiffies(POLLING_DELAY)); +} + +static int __init task_status_init(void) +{ + int i; + struct task_data *task; + struct task_data *master; + int total_tasks = 4; + + task = kzalloc(sizeof(struct task_data), GFP_KERNEL); + if (!task) + return -ENOMEM; + + INIT_LIST_HEAD(&task->subtasks); + task->container = true; + + mutex_lock(&tasks_list_lock); + list_add_tail(&task->node, &tasks_list); + mutex_unlock(&tasks_list_lock); + + INIT_DELAYED_WORK(&task->wq, task_status_check); + + master = task; + master->get_status = task_container_status; + + for (i = 1; i < total_tasks; i++) { + + task = kzalloc(sizeof(struct task_data), GFP_KERNEL); + if (!task) + goto clean; + + mutex_lock(&tasks_list_lock); + list_add_tail(&task->node, &tasks_list); + mutex_unlock(&tasks_list_lock); + + INIT_DELAYED_WORK(&task->wq, task_status_check); + + list_add_tail(&task->subtasks, &master->subtasks); + + task->get_status = task_status; + + mod_delayed_work(system_freezable_wq, &task->wq, + msecs_to_jiffies(POLLING_DELAY)); + } + + mod_delayed_work(system_freezable_wq, &master->wq, + msecs_to_jiffies(POLLING_DELAY)); + + return 0; + +clean: + return -ENOMEM; +} + + +static void __exit task_exit(void) +{ + struct task_data *td, *tmp; + + list_for_each_entry_safe(td, tmp, &tasks_list, node) { + mutex_lock(&td->lock); + cancel_delayed_work(&td->wq); + mutex_unlock(&td->lock); + + list_del(&td->node); + kfree(td); + } + + mutex_destroy(&tasks_list_lock); +} + +module_init(task_status_init); +module_exit(task_exit); + +MODULE_AUTHOR("Lukasz Luba <l.luba(a)partner.samsung.com>"); +MODULE_DESCRIPTION("Test module which shows speed up in hackbench"); +MODULE_VERSION("1.0"); +MODULE_LICENSE("GPL"); -- 2.7.4

7 years, 8 months

1
0
0 0

[RFC][PATCH 0/3] Strange hackbench speed-up

by Lukasz Luba

Hi, I have noticed an odd behavior in hackbench test, when developing some enhancements for thermal subsystem. It is present on ARM64 big.LITTLE (4b+4l) SoC. When hackbench runs normally after system reboot, it takes ~11sec to finish. When the module (which has locking present) is loaded and unloaded, time-to-finish is around ~6sec. The module tries to mimic the thermal framework, so everyone can experiment on local system without the need of thermal configuration. The test scenario and results are described in patch 1/3. Patch 3/3 is to narrow down the issue - mutex_unlock() call. Please apply only patch 1 and 2 and give it a try. You should see the speed-up 11s -> 6s. Then apply patch 3, rebuild the module, reboot the system, load the module, and run the test again (there should not be any improvements 11s -> 11s). I have noticed that the sequence: load the module, unload, run the test, also gives the speed-up. So there is no need to constantly touch the mutexes in the background. Any comments are welcome, esspecially for Will or Mark who where implementing low-level atomic stuff for mutexes. Tested on a few kernels (tag 4.18-rc6, EAS-next-integration_20180817_0000, some stable 4.14.x) and all are affected. Ypu can experiment with this kernel: EAS kernel branch: eas/next/integration_20180817_0000 also check tag: v4.18-rc6 url: http://linux-arm.org/git?p=linux-power.git;a=shortlog;h=refs/heads/eas/next… Regards, Lukasz Luba Lukasz Luba (3): drivers: base: add test module hackbench speedup drivers: base: add hackbench_speedup as a module drivers: hackbench_speedup: remove locking drivers/base/Makefile | 1 + drivers/base/hackbench_speedup.c | 148 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 149 insertions(+) create mode 100644 drivers/base/hackbench_speedup.c -- 2.7.4

7 years, 8 months

1
0
0 0

Arm TechCon 2018 Attendees contact list

by Maria Garcia

Hello, Hope you are doing well! I'm trying to figure out if you are interested in procuring an Attendees contact list of " Arm TechCon 2018" and there will be a cost associated with the list. Attendees: . ASIC/FPGA Engineers . Chief Hacker/Wizard . Chip Architects & Designers . CIO/CTO/CSO/CISO . IT Directors and Managers . Manager of E-Business/E-Commerce . Design & Development Engineers . Embedded Software Engineers . Hardware Engineers . OEM System Designer . Operator/Carrier . Software Architects Developers & Engineers . App and Game Developers . System Design and Processor Design Engineers . System Architect, Systems Analyst . VP/Director of Hardware Engineering . VP/Director of Software Engineering This list comes with full contact details like: Contact Name, Title, Company Name, Size, Physical Address, Opt-In Email address, Phone & Fax numbers and etc. Please let me know your interest to send you the number of attendees and cost for your review. Looking forward for your response. Thanks & Regards, Maria.garcia If you wish to not to receive further emails, change the subject line to Unsubscribe

7 years, 8 months

1
0
0 0

[Integration Branch] Update 14-September-2018

by Douglas Raillard

Hi, A new EAS integration branch created for September 14th 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, 8 months

1
0
0 0

EAS behavior and lack of idle states in SoC

by Lukasz Luba

Hi ARM folks! I have some work to do with EAS + IPA. I have a platform with arm64 4 big + 4 LITTLE that will hopefully get EAS and IPA (when I solve some thermal issues). Unfortunately, in this SoC and code we don't have idle states (new SoCs will just get normal psci support). I run different kernel versions, also your latest integration-next (after dropping whole /drivers/usb because the changes in that branch broke it). Have you ever tried to evaluate EAS on a platform which has only WFI idle? Do you know what could be the impact on the EAS? I have some other thought and issues to discuss regarding EAS (migrations, load balancing, etc) but this question regarding idle is probably fundamental. Cheers, Lukasz Luba

7 years, 9 months

2
2
0 0

[Integration Branch] Update 31-August-2018

by Douglas Raillard

Hi, A new EAS integration branch created for August 31st 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, 9 months

1
0
0 0

[Integration Branch] Update 17-August-2018

by Douglas Raillard

Hi, A new EAS integration branch created for August 17th 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, 9 months

1
0
0 0

4.18 update to experimental/eas-dev for Android development

by Quentin Perret

Hi all, The 'experimental/eas-dev' branch (which holds the candidate EAS patches for the next Android Kernel version) has been updated to Linux 4.18: https://android.googlesource.com/kernel/common exprimental/eas-dev All the EAS patches are also available as part of the Android stack maintained by Amit Pundir in the 'android-mainline-tracking' branch available on AOSP. If you wish to contribute patches to EAS that you think are Android-specific, please do so by posting them to AOSP Gerrit against the 'experimental/eas-dev' branch. The branch will be rebased and force-pushed at each kernel release (e.g. 4.18, 4.19), hence maintaining a clean stack of patches that will be used during the creation of the next Android Common Kernel. For more details about the contribution process to EAS, please refer to the Arm developer website [1]. Cheers, Quentin [1] https://developer.arm.com/open-source/energy-aware-scheduling/contributing-…

7 years, 9 months

1
0
0 0

[Integration Branch] Update 03-August-2018

by Douglas Raillard

Hi, A new EAS integration branch created for August 3rd 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

Computing the dynamic-power-coefficient on Exynos5422

by Oliver Effland

Hi, First of all: thanks for all the valuable input! @(Russell, Dietmar & Steven) On 07/23/2018 08:51 AM, Steven Miao wrote: > Hi Oliver, > > Generally these dynamic co-efficiency and static leakage power comes > from hardware design team by running power estimation tool, however > you can tun these co-efficiency and parameters for better performance. > > How did you get A7 or A15 power? Get Soc power or there's separate > sensor for A7/A15? Yes indeed, there are 2 seperate sensors for the A7 and A15. > If you want to create cpu busy power model manually, you can: > 1 leave 1 A7 + 1 A15 core online, keep other cores offline, disable > thermal zone, disable idle state for all cores > 2 set A7 frequency to 200Mhz, move all the task to A15, run cpu > intensive task on A7(dhrystone, sysbench cpu test), read sensor to get > 1 A7 power P1(read from A7 cluster sensor) > 3 online 2 A7 core, run dhrystone on each core, and get power P2 > > we can get 1 A7 core power@200Mhz ~= P2 - P1 (A7 power X 2 + static > power - A7 power X 1 - static power I followed your manual steps (using a busy loop for 10s, instead of a benchmark) and corrected my calculations (with the static power in mind): A7: freq(MHz) voltage(mV) Power(mW) A7_Power(mW) Stat_Power(mW) DPC 200 918.750 34.768 12.203 10.362 72.283955 400 920.000 60.805 21.25 18.305 62.765831 600 968.750 98.046 35.084 27.878 62.306652 800 1042.500 148.095 52.285 43.525 60.136063 1000 1116.250 212.214 76.112 59.99 61.084382 1200 1190.000 288.958 99.993 88.972 58.842948 1400 1288.750 411.936 144.807 122.322 62.276495 mean: 62 A15: freq(MHz) voltage(mV) Power(mW) A15_Power(mW) Stat_Power(mW) DPC 200 916250 122.584 31.139 60.306 185.458477 500 916250 225.101 68.774 87.553 163.842401 800 942500 349.158 112.432 124.294 158.211202 1100 1016250 540.78 169.556 201.668 149.251725 1400 1078750 779.19 258.214 262.762 158.493016 1700 1180000 1179.344 392.107 395.13 165.650083 2000 1320000 1969.764 648.768 672.228 186.170798 mean: 164 The ratio between A15 and A7 is now 164/62 = 2.645 I hope the dynamic-power-coefficient's are more accurate now? > dynamic-power-coefficient ~= 400 - 500 is reasonable for big core > dynamic-power-coefficient ~= 100 is reasonable for LITTLE core. > For IPA it can work effectively with a poor power model(not so > accurate), for EAS it just need power model of LITTLE core and big > core is proportional. I'm guessing my values differ from your suggested values, because it's 32bit ARM? Best regards, Oliver

7 years, 10 months

3
2
0 0

In my life there is no happiness, I want to find it!

by h-satsukakhnv＠cm.hitachi-hb.co.jp

Good day, dear sir. My name is Sevgi. I am a woman, who believe in a destiny with a cheerful future for myself and that you could become a part of it. I do want to be next to a loving man. I wish to find a man that can give me a real hope and love! Hope you're interested in becoming a part of my adventure and will reply back soon! If you are interested in getting to know me closer, please write to my personal e-mail - beautysevgi(a)fastmail.com Your true soul, Sevgi.

7 years, 10 months

1
0
0 0

Computing the dynamic-power-coefficient on Exynos5422

by Oliver Effland

Hello everyone, I hope this is the right place to ask, otherwise please just point me in the right direction. I'm currently testing the EAS patches [v4] on an ODROID-XU3 board, which has an Exynos5422 SoC. However, the corresponding DT is missing the "dynamic-power-coefficient" that is needed for an appropriate EM. So I'm trying to compute the dynamic-power-coefficient according to the formula: Pdyn = dynamic-power-coefficient * V^2 * f The frequency f is given by the DT.The actual Voltage and Power are determined by means of the on-chip sensors (returns the values for the specific cluster). When using the Voltage given in the DT, the differences for the d-p-coefficient are negligible. So I'm calculating the d-p-coefficient (mW/MHz/uV^2) by reading out the following SoC sensor values. For the little cluster (A7): frequency(MHz) Voltage(V) Power(mW) Dynamic-power-coefficient 200 0.9175 49.470 ~2.938*10^-13 400 0.9165 91.892 ~2.736*10^-13 600 0.9638 149.454 ~2.682*10^-13 800 1.0263 223.453 ~2.652*10^-13 1000 1.1000 327.707 ~2.708*10^-13 1200 1.1725 445.899 ~2.703*10^-13 1400 1.2713 627.010 ~2.771*10^-13 For the big cluster (A15): frequency(MHz) Voltage(V) Power(mW) Dynamic-power-coefficient 200 0.9162 159.676 ~9.510*10^-13 500 0.9138 325.480 ~7.797*10^-13 800 0.9288 511.360 ~7.410*10^-13 1100 1.0063 828.020 ~7.434*10^-13 1400 1.0713 1209.774 ~7.530*10^-13 1700 1.1750 1835.784 ~7.822*10^-13 2000 1.2700 2661.849 ~8.252*10^-13 But those values are way off for the DT, unless I multiply the d-p-coefficient with 10^15. Assuming the Power value needs to be subtracted by a static component (power usage when idle), the results change as follows: For the little cluster (A7): frequency(MHz) Voltage(V) P-dyn(mW) Dynamic-power-coefficient 200 0.9175 36,381 ~2,160*10^-13 400 0.9165 73,438 ~2,186*10^-13 600 0.9638 122,470 ~2,197*10^-13 800 1.0263 184,135 ~2,185*10^-13 1000 1.1000 270,425 ~2,234*10^-13 1200 1.1725 367,121 ~2,225*10^-13 1400 1.2713 513,989 ~2,271*10^-13 For the big cluster (A15): frequency(MHz) Voltage(V) P-dyn(mW) Dynamic-power-coefficient 200 0.9162 99,834 ~5,945*10^-13 500 0.9138 244,651 ~5,860*10^-13 800 0.9288 401,986 ~5,825*10^-13 1100 1.0063 664,565 ~5,966*10^-13 1400 1.0713 985,268 ~6,132*10^-13 1700 1.1750 1494,173 ~6,366*10^-13 2000 1.2700 2086,273 ~6,467*10^-13 While looking for examples in the kernel that calculate the dynamic-power-coefficient, I found this patch [1] by Caesar Wang that introduced this value for the rk3399 big cluster. Unfortunately, I'm unable to reproduce the same results for the coefficient with the given values. My results are also with a 10^-13 factor and even when I scale them with 10^15, my results have a certain margin of error: > frequency(MHz) Voltage(V) Current(mA) Dynamic-power-coefficient (My) d-p-coefficient > 24 0.8 15 > 48 0.8 23 ~417 ~598 > 96 0.8 40 ~443 ~520 > 216 0.8 82 ~438 ~474 > 312 0.8 115 ~430 ~460 > 408 0.8 150 ~455 ~459 Is this the right approach, or am I missing something? Hope someone can help me out. Thanks in advance, Oliver Effland [1] https://patchwork.kernel.org/patch/9861505/

7 years, 10 months

5
4
0 0

[Integration Branch] Update 20-July-2018

by Dietmar Eggemann

Hi, A new EAS integration branch created on July 20 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, -- Dietmar

7 years, 10 months

1
0
0 0

[Integration Branch] Update 06-July-2018

by Dietmar Eggemann

Hi, A new EAS integration branch created on July 6nd 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, Dietmar

7 years, 10 months

1
0
0 0

WELDED and SEAMLESS STEEL PIPES and stainless steel pipe with more than 25 Years exporting experience.

by Sera_threewaysteel

Dear Manager, Wish your business booming all the time. Here Greetings from Sera of Threeway Steel Co., Ltd. Glad to know you are in business of steel pipes from your website. We are a leading professional manufacturer and trader of carbon steel pipe(WELDED STEEL PIPES, HOLLOW SECTION and SEAMLESS STEEL PIPES) and stainless steel pipe with more than 25 Years exporting experience. * Best delivery time, Competitive price, Favorable payment terms(T/T, L/C,D/P,O/A) can be provided. * Pipe Standard: API 5L, API 5CT, ASTM A53, EN10217, EN10210, BS138785, Material: GR.B,X42,X46,X52,X60,S355,ST37,ST52 * Surface: Lightly oiled,Hot dip galvanized,Electro galvanized,Black Bare,Varnish coating/Antu rust oil,Protective Coatings * Packing: Bare of Bundled or pvc packing ect. * Test: Chemical Component Analysis,Mechanical Properties and other inspection,Third Inspection:BV,SGS,LIoyds ect. If you have inquiry about steel pipes, please do not hesitate to contact us, best offer will be sent asap. Hope we could be good partners. Sera Ma Oversea sales specialist ---------------------------------------- Tel : +86 731 8872 7983 | Email:sales28@srtsteelpipe.com Mob/whatsapp: +86 18620133787 | Skype: serama2016 Threeway Steel Co., Ltd | Web: www.srtsteelpipe.com Add.:Hunan Steel Industrial Zone, No.9 Xiangfu Rd, Changsha, Hunan, China P I am sorry if it sent to the wrong person, pls let me know. It's highly appreciate if you transfer to the people who need it

7 years, 11 months

1
0
0 0

"WALT wallclock appears to have gone backwards or reset" warring question. Thanks!

by Wu Gang(吴刚)

Hi all, When using WALT for EAS scheduler( android common 4.4 code base with commit fe09418d6f88b55920c576166b6e6a5ad456920f ), I met “WALT wallclock appears to have gone backwards or reset” WARNING. This warring is very hard to duplicate, and I met two times totally (for one time: wallclock is 64090104834350 and rq->window_start is 64255280000001 , windown_start is wrong). I am wondering is there anyone else meet similar issue as me? Or is this one known issue ? Thanks very much! Gang 05-24 16:20:29.351 <4> [14863.154614] c4 15486 (stressapptest) WALT wallclock appears to have gone backwards or reset 05-24 16:20:29.351 <4> [14863.162970] c4 15486 (stressapptest) ------------[ cut here ]------------ 05-24 16:20:29.351 <4> [14863.169745] c4 15486 (stressapptest) WARNING: at /home/build/farmland/adroid8.1/kernel/linux/kernel/sched/walt.c:212 05-24 16:20:29.351 <4> [14863.180237] c4 15486 (stressapptest) Modules linked in: 05-24 16:20:29.351 <4> [14863.183289] c4 15486 (stressapptest) 05-24 16:20:29.351 <4> [14863.186942] c4 15486 (stressapptest) CPU: 4 PID: 15486 Comm: stressapptest Not tainted 4.4.114+ #1 05-24 16:20:29.351 <4> [14863.195884] c4 15486 (stressapptest) Hardware name: ASR AQUILAC EVB (DT) 05-24 16:20:29.351 <4> [14863.202563] c4 15486 (stressapptest) task: ffffffc07d19a880 task.stack: ffffffc064f88000 05-24 16:20:29.351 <4> [14863.210640] c4 15486 (stressapptest) PC is at walt_update_task_ravg+0x260/0x6ec 05-24 16:20:29.351 <4> [14863.217931] c4 15486 (stressapptest) LR is at walt_update_task_ravg+0x260/0x6ec 05-24 16:20:29.351 <4> [14863.225219] c4 15486 (stressapptest) pc : [<ffffff80080f89d8>] lr : [<ffffff80080f89d8>] pstate: 600001c5 05-24 16:20:29.351 <4> [14863.234759] c4 15486 (stressapptest) sp : ffffffc0bbf48d90 05-24 16:20:29.351 <4> [14863.240227] c4 15486 (stressapptest) x29: ffffffc0bbf48d90 x28: ffffffc07d19a880 05-24 16:20:29.351 <4> [14863.245530] c4 15486 (stressapptest) x27: 00000d84990dad13 x26: ffffff800966c000 05-24 16:20:29.351 <4> [14863.250842] c4 15486 (stressapptest) x25: ffffff800957f000 x24: 0000000000000000 05-24 16:20:29.351 <4> [14863.256128] c4 15486 (stressapptest) x23: 0000000000000004 x22: 00000d84990dad13 05-24 16:20:29.351 <4> [14863.261415] c4 15486 (stressapptest) x21: ffffffc07d19a880 x20: ffffffc0bbf4f600 05-24 16:20:29.351 <4> [14863.266712] c4 15486 (stressapptest) x19: 0000000000000000 x18: 0000000000000000 05-24 16:20:29.351 <4> [14863.272006] c4 15486 (stressapptest) x17: 0000000000000000 x16: 0000000000000000 05-24 16:20:29.351 <4> [14863.277301] c4 15486 (stressapptest) x15: 0000000000000000 x14: 7420737261657070 05-24 16:20:29.351 <4> [14863.282597] c4 15486 (stressapptest) x13: 61206b636f6c636c x12: 6c617720544c4157 05-24 16:20:29.351 <4> [14863.287893] c4 15486 (stressapptest) x11: 2029747365747070 x10: 6173736572747328 05-24 16:20:29.351 <4> [14863.293205] c4 15486 (stressapptest) x9 : 2036383435312034 x8 : ffffff80083317d4 05-24 16:20:29.351 <4> [14863.298501] c4 15486 (stressapptest) x7 : ffffff80095c5650 x6 : 000000000000005f 05-24 16:20:29.351 <4> [14863.303795] c4 15486 (stressapptest) x5 : 0000000000000000 x4 : 0000000000000000 05-24 16:20:29.351 <4> [14863.309091] c4 15486 (stressapptest) x3 : 0000000000000000 x2 : cb88537fdc8ba672 05-24 16:20:29.351 <4> [14863.314377] c4 15486 (stressapptest) x1 : cb88537fdc8ba672 x0 : 000000000000004f static void update_window_start(struct rq *rq, u64 wallclock) { s64 delta; int nr_windows; delta = wallclock - rq->window_start; /* If the MPM global timer is cleared, set delta as 0 to avoid kernel BUG happening */ if (delta < 0) { delta = 0; WARN_ONCE(1, "WALT wallclock appears to have gone backwards or reset\n"); } if (delta < walt_ravg_window) return; nr_windows = div64_u64(delta, walt_ravg_window); rq->window_start += (u64)nr_windows * (u64)walt_ravg_window; rq->cum_window_demand = rq->cumulative_runnable_avg; }

7 years, 11 months

2
2
0 0

[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, 11 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

8 years

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

8 years

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 ]---

8 years

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

8 years

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 month

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 month

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 3 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, 3 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, 3 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, 3 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

eas-dev