- 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, 5 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, 6 months

1
0
0 0

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

by 客服：小彬

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

7 years, 6 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, 6 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, 7 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, 7 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, 7 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, 7 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, 7 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, 8 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, 8 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, 9 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, 9 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, 9 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, 9 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, 9 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, 10 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, 10 months

2
2
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

eas-dev