eas-dev September 2018

eas-dev@lists.linaro.org

4 participants
8 discussions

[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

5 years, 7 months

[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

5 years, 7 months

[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

5 years, 7 months

[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

5 years, 7 months

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

5 years, 7 months

[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

5 years, 7 months

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

5 years, 7 months

[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

5 years, 7 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

eas-dev September 2018