We know the load_idx is a decay for cpu_load of rq. After added sched_avg, we has 2 kind decay for cpu_load. That is a kind of redundancy.
This patch remove the load_idx. There are 5 _idx in sched_domain, busy_idx and idle_idx are not zero usually, but newidle_idx, wake_idx and forkexec_idx are all zero on all arch. and this patch remove the only place using busy_idx/idle_idx.
Since arm system rarely has much tasks running in system. this removing should no harm. But it will be great, if someone can measure it with some performance benchmark.
Do we have some performance testing force in linaro or ARM?
---
From 6fd05051dbb5aaa28d3bfe11042cc9cbb147bf7c Mon Sep 17 00:00:00 2001
From: Alex Shi alex.shi@linaro.org Date: Tue, 19 Nov 2013 17:38:07 +0800 Subject: [PATCH] sched: remove load_idx effect
Shortcut to remove rq->cpu_load[load_idx] effect in scheduler. All other place rq->cpu_load used cpu_load[0].
Signed-off-by: Alex Shi alex.shi@linaro.org --- kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index e8b652e..ce683aa 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -5633,7 +5633,7 @@ static inline void update_sd_lb_stats(struct lb_env *env, struct sd_lb_stats *sd if (child && child->flags & SD_PREFER_SIBLING) prefer_sibling = 1;
- load_idx = get_sd_load_idx(env->sd, env->idle); + load_idx = 0;
do { struct sg_lb_stats *sgs = &tmp_sgs;
On Tue, Nov 19, 2013 at 11:46:19AM +0000, Alex Shi wrote:
We know the load_idx is a decay for cpu_load of rq. After added sched_avg, we has 2 kind decay for cpu_load. That is a kind of redundancy.
This patch remove the load_idx. There are 5 _idx in sched_domain, busy_idx and idle_idx are not zero usually, but newidle_idx, wake_idx and forkexec_idx are all zero on all arch. and this patch remove the only place using busy_idx/idle_idx.
Have you looked into the decay rates of cpu_load[busy_idx] and cpu_load[idle_idx] and compared them to the load in sched_avg?
I'm thinking that there must be a reason why they are not all using the same average cpu load.
Since arm system rarely has much tasks running in system. this removing
Could you elaborate on the effect of this change?
I don't think the assumption that ARM systems rarely have many tasks running is generally valid. Smartphones do occasionally use all available cpus and ARM systems are used in many other segments.
Also, this patch will affect all architectures, so we need to ensure that none of them are affected negatively.
should no harm. But it will be great, if someone can measure it with some performance benchmark.
I would suggest to do a comparison between the different cpu load averages first.
Morten
Do we have some performance testing force in linaro or ARM?
From 6fd05051dbb5aaa28d3bfe11042cc9cbb147bf7c Mon Sep 17 00:00:00 2001 From: Alex Shi alex.shi@linaro.org Date: Tue, 19 Nov 2013 17:38:07 +0800 Subject: [PATCH] sched: remove load_idx effect
Shortcut to remove rq->cpu_load[load_idx] effect in scheduler. All other place rq->cpu_load used cpu_load[0].
Signed-off-by: Alex Shi alex.shi@linaro.org
kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index e8b652e..ce683aa 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -5633,7 +5633,7 @@ static inline void update_sd_lb_stats(struct lb_env *env, struct sd_lb_stats *sd if (child && child->flags & SD_PREFER_SIBLING) prefer_sibling = 1;
- load_idx = get_sd_load_idx(env->sd, env->idle);
load_idx = 0;
do { struct sg_lb_stats *sgs = &tmp_sgs;
-- 1.8.1.2
-- Thanks Alex
On 11/19/2013 08:45 PM, Morten Rasmussen wrote:
On Tue, Nov 19, 2013 at 11:46:19AM +0000, Alex Shi wrote:
We know the load_idx is a decay for cpu_load of rq. After added sched_avg, we has 2 kind decay for cpu_load. That is a kind of redundancy.
This patch remove the load_idx. There are 5 _idx in sched_domain, busy_idx and idle_idx are not zero usually, but newidle_idx, wake_idx and forkexec_idx are all zero on all arch. and this patch remove the only place using busy_idx/idle_idx.
Have you looked into the decay rates of cpu_load[busy_idx] and cpu_load[idle_idx] and compared them to the load in sched_avg?
The sched_avg decay according to active task load history. The cpu_load decay on past cpu load: load = (2^idx - 1) / 2^idx * load + 1 / 2^idx * cur_load These 2 cpu load both decay on time. but sched_avg is a bit more precise.
I'm thinking that there must be a reason why they are not all using the same average cpu load.
I asked this for PeterZ. PeterZ had no clear answerer of cpu_load decay usage, and he also thought is these 2 decay have a bit redundance.
As to cpu_load decay, it only used in load_balance. to bias on source cpu or no bias.
Since arm system rarely has much tasks running in system. this removing
Could you elaborate on the effect of this change?
I don't think the assumption that ARM systems rarely have many tasks running is generally valid. Smartphones do occasionally use all available cpus and ARM systems are used in many other segments.
I only has a panda board in hands, and don't know which benchmark are good for the testing. The key of this patch effect is testing. Anyone like to give a hand on this?
AFAIK, there are no theory can prove which decay is better (but obviously, community prefer to sched_avg, since it was added when cpu_load already existed.)
Also, this patch will affect all architectures, so we need to ensure that none of them are affected negatively.
Yes, so however detailed we measured on ARM, there must are still much testing/comments on this in community. Anyway, I had tested this patch in Intel platforms, and in fengguang's 0day kernel testing. there are no clear regression, also no clear improvement.
should no harm. But it will be great, if someone can measure it with some performance benchmark.
I would suggest to do a comparison between the different cpu load averages first.
any detailed benchmarks?
Morten
Do we have some performance testing force in linaro or ARM?
From 6fd05051dbb5aaa28d3bfe11042cc9cbb147bf7c Mon Sep 17 00:00:00 2001 From: Alex Shi alex.shi@linaro.org Date: Tue, 19 Nov 2013 17:38:07 +0800 Subject: [PATCH] sched: remove load_idx effect
Shortcut to remove rq->cpu_load[load_idx] effect in scheduler. All other place rq->cpu_load used cpu_load[0].
Signed-off-by: Alex Shi alex.shi@linaro.org
kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index e8b652e..ce683aa 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -5633,7 +5633,7 @@ static inline void update_sd_lb_stats(struct lb_env *env, struct sd_lb_stats *sd if (child && child->flags & SD_PREFER_SIBLING) prefer_sibling = 1;
- load_idx = get_sd_load_idx(env->sd, env->idle);
load_idx = 0;
do { struct sg_lb_stats *sgs = &tmp_sgs;
-- 1.8.1.2
-- Thanks Alex
On 19 November 2013 14:19, Alex Shi alex.shi@linaro.org wrote:
On 11/19/2013 08:45 PM, Morten Rasmussen wrote:
On Tue, Nov 19, 2013 at 11:46:19AM +0000, Alex Shi wrote:
We know the load_idx is a decay for cpu_load of rq. After added sched_avg, we has 2 kind decay for cpu_load. That is a kind of redundancy.
This patch remove the load_idx. There are 5 _idx in sched_domain, busy_idx and idle_idx are not zero usually, but newidle_idx, wake_idx and forkexec_idx are all zero on all arch. and this patch remove the only place using busy_idx/idle_idx.
Have you looked into the decay rates of cpu_load[busy_idx] and cpu_load[idle_idx] and compared them to the load in sched_avg?
The sched_avg decay according to active task load history. The cpu_load decay on past cpu load: load = (2^idx - 1) / 2^idx * load + 1 / 2^idx * cur_load These 2 cpu load both decay on time. but sched_avg is a bit more precise.
I'm thinking that there must be a reason why they are not all using the same average cpu load.
I asked this for PeterZ. PeterZ had no clear answerer of cpu_load decay usage, and he also thought is these 2 decay have a bit redundance.
I agree too
As to cpu_load decay, it only used in load_balance. to bias on source cpu or no bias.
Since arm system rarely has much tasks running in system. this removing
Could you elaborate on the effect of this change?
I don't think the assumption that ARM systems rarely have many tasks running is generally valid. Smartphones do occasionally use all available cpus and ARM systems are used in many other segments.
I only has a panda board in hands, and don't know which benchmark are good for the testing. The key of this patch effect is testing. Anyone like to give a hand on this?
AFAIK, there are no theory can prove which decay is better (but obviously, community prefer to sched_avg, since it was added when cpu_load already existed.)
sched_avg is better because it can't miss any load whereas cpu_load average can miss tasks that don't wakeup synchronously to tick
Also, this patch will affect all architectures, so we need to ensure that none of them are affected negatively.
Yes, so however detailed we measured on ARM, there must are still much testing/comments on this in community. Anyway, I had tested this patch in Intel platforms, and in fengguang's 0day kernel testing. there are no clear regression, also no clear improvement.
should no harm. But it will be great, if someone can measure it with some performance benchmark.
I would suggest to do a comparison between the different cpu load averages first.
any detailed benchmarks?
Morten
Do we have some performance testing force in linaro or ARM?
From 6fd05051dbb5aaa28d3bfe11042cc9cbb147bf7c Mon Sep 17 00:00:00 2001 From: Alex Shi alex.shi@linaro.org Date: Tue, 19 Nov 2013 17:38:07 +0800 Subject: [PATCH] sched: remove load_idx effect
Shortcut to remove rq->cpu_load[load_idx] effect in scheduler. All other place rq->cpu_load used cpu_load[0].
Signed-off-by: Alex Shi alex.shi@linaro.org
kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index e8b652e..ce683aa 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -5633,7 +5633,7 @@ static inline void update_sd_lb_stats(struct lb_env *env, struct sd_lb_stats *sd if (child && child->flags & SD_PREFER_SIBLING) prefer_sibling = 1;
- load_idx = get_sd_load_idx(env->sd, env->idle);
load_idx = 0;
do { struct sg_lb_stats *sgs = &tmp_sgs;
-- 1.8.1.2
-- Thanks Alex
-- Thanks Alex
On Tue, Nov 19, 2013 at 01:27:14PM +0000, Vincent Guittot wrote:
On 19 November 2013 14:19, Alex Shi alex.shi@linaro.org wrote:
On 11/19/2013 08:45 PM, Morten Rasmussen wrote:
On Tue, Nov 19, 2013 at 11:46:19AM +0000, Alex Shi wrote:
Since arm system rarely has much tasks running in system. this removing
Could you elaborate on the effect of this change?
I don't think the assumption that ARM systems rarely have many tasks running is generally valid. Smartphones do occasionally use all available cpus and ARM systems are used in many other segments.
I only has a panda board in hands, and don't know which benchmark are good for the testing. The key of this patch effect is testing. Anyone like to give a hand on this?
AFAIK, there are no theory can prove which decay is better (but obviously, community prefer to sched_avg, since it was added when cpu_load already existed.)
sched_avg is better because it can't miss any load whereas cpu_load average can miss tasks that don't wakeup synchronously to tick
But cpu_load[] is already based on the sched_avg load?
Morten
On 19 November 2013 15:11, Morten Rasmussen morten.rasmussen@arm.com wrote:
On Tue, Nov 19, 2013 at 01:27:14PM +0000, Vincent Guittot wrote:
On 19 November 2013 14:19, Alex Shi alex.shi@linaro.org wrote:
On 11/19/2013 08:45 PM, Morten Rasmussen wrote:
On Tue, Nov 19, 2013 at 11:46:19AM +0000, Alex Shi wrote:
Since arm system rarely has much tasks running in system. this removing
Could you elaborate on the effect of this change?
I don't think the assumption that ARM systems rarely have many tasks running is generally valid. Smartphones do occasionally use all available cpus and ARM systems are used in many other segments.
I only has a panda board in hands, and don't know which benchmark are good for the testing. The key of this patch effect is testing. Anyone like to give a hand on this?
AFAIK, there are no theory can prove which decay is better (but obviously, community prefer to sched_avg, since it was added when cpu_load already existed.)
sched_avg is better because it can't miss any load whereas cpu_load average can miss tasks that don't wakeup synchronously to tick
But cpu_load[] is already based on the sched_avg load?
Ah you're right that we have mode the cpu_load on load_avg. Nevertheless, the cpu_load is based on the instant value of the load_avg at the tick and not the integration of the value between tick which still make it possible to miss some activity
Vincent
Morten
On 11/19/2013 10:21 PM, Vincent Guittot wrote:
sched_avg is better because it can't miss any load whereas cpu_load average can miss tasks that don't wakeup synchronously to tick
But cpu_load[] is already based on the sched_avg load?
Ah you're right that we have mode the cpu_load on load_avg. Nevertheless, the cpu_load is based on the instant value of the load_avg at the tick and not the integration of the value between tick which still make it possible to miss some activity
Thanks a lot for the question and explanations! Just it is too late in China to join your discussion more. Sorry.
On Tue, Nov 19, 2013 at 02:21:31PM +0000, Vincent Guittot wrote:
On 19 November 2013 15:11, Morten Rasmussen morten.rasmussen@arm.com wrote:
On Tue, Nov 19, 2013 at 01:27:14PM +0000, Vincent Guittot wrote:
On 19 November 2013 14:19, Alex Shi alex.shi@linaro.org wrote:
On 11/19/2013 08:45 PM, Morten Rasmussen wrote:
On Tue, Nov 19, 2013 at 11:46:19AM +0000, Alex Shi wrote:
Since arm system rarely has much tasks running in system. this removing
Could you elaborate on the effect of this change?
I don't think the assumption that ARM systems rarely have many tasks running is generally valid. Smartphones do occasionally use all available cpus and ARM systems are used in many other segments.
I only has a panda board in hands, and don't know which benchmark are good for the testing. The key of this patch effect is testing. Anyone like to give a hand on this?
AFAIK, there are no theory can prove which decay is better (but obviously, community prefer to sched_avg, since it was added when cpu_load already existed.)
sched_avg is better because it can't miss any load whereas cpu_load average can miss tasks that don't wakeup synchronously to tick
But cpu_load[] is already based on the sched_avg load?
Ah you're right that we have mode the cpu_load on load_avg. Nevertheless, the cpu_load is based on the instant value of the load_avg at the tick and not the integration of the value between tick which still make it possible to miss some activity
True, but the sched_avg load of a rq changes fairly slowly, so the effect is probably not significant. But I agree, there is no need for sampling the cpu load at the sched_tick when we can use it directly. We can also get rid of a lot of code in proc.c if testing shows no negative impact.
Morten
The benefit we can guarantee now is, the decay removing can save much of kernel time in sched_tick. :)
On 11/19/2013 09:19 PM, Alex Shi wrote:
On 11/19/2013 08:45 PM, Morten Rasmussen wrote:
On Tue, Nov 19, 2013 at 11:46:19AM +0000, Alex Shi wrote:
We know the load_idx is a decay for cpu_load of rq. After added sched_avg, we has 2 kind decay for cpu_load. That is a kind of redundancy.
This patch remove the load_idx. There are 5 _idx in sched_domain, busy_idx and idle_idx are not zero usually, but newidle_idx, wake_idx and forkexec_idx are all zero on all arch. and this patch remove the only place using busy_idx/idle_idx.
Have you looked into the decay rates of cpu_load[busy_idx] and cpu_load[idle_idx] and compared them to the load in sched_avg?
The sched_avg decay according to active task load history. The cpu_load decay on past cpu load: load = (2^idx - 1) / 2^idx * load + 1 / 2^idx * cur_load These 2 cpu load both decay on time. but sched_avg is a bit more precise.
I'm thinking that there must be a reason why they are not all using the same average cpu load.
I asked this for PeterZ. PeterZ had no clear answerer of cpu_load decay usage, and he also thought is these 2 decay have a bit redundance.
As to cpu_load decay, it only used in load_balance. to bias on source cpu or no bias.
Since arm system rarely has much tasks running in system. this removing
Could you elaborate on the effect of this change?
I don't think the assumption that ARM systems rarely have many tasks running is generally valid. Smartphones do occasionally use all available cpus and ARM systems are used in many other segments.
I only has a panda board in hands, and don't know which benchmark are good for the testing. The key of this patch effect is testing. Anyone like to give a hand on this?
AFAIK, there are no theory can prove which decay is better (but obviously, community prefer to sched_avg, since it was added when cpu_load already existed.)
Also, this patch will affect all architectures, so we need to ensure that none of them are affected negatively.
Yes, so however detailed we measured on ARM, there must are still much testing/comments on this in community. Anyway, I had tested this patch in Intel platforms, and in fengguang's 0day kernel testing. there are no clear regression, also no clear improvement.
should no harm. But it will be great, if someone can measure it with some performance benchmark.
I would suggest to do a comparison between the different cpu load averages first.
any detailed benchmarks?
Morten
Do we have some performance testing force in linaro or ARM?
From 6fd05051dbb5aaa28d3bfe11042cc9cbb147bf7c Mon Sep 17 00:00:00 2001 From: Alex Shi alex.shi@linaro.org Date: Tue, 19 Nov 2013 17:38:07 +0800 Subject: [PATCH] sched: remove load_idx effect
Shortcut to remove rq->cpu_load[load_idx] effect in scheduler. All other place rq->cpu_load used cpu_load[0].
Signed-off-by: Alex Shi alex.shi@linaro.org
kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index e8b652e..ce683aa 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -5633,7 +5633,7 @@ static inline void update_sd_lb_stats(struct lb_env *env, struct sd_lb_stats *sd if (child && child->flags & SD_PREFER_SIBLING) prefer_sibling = 1;
- load_idx = get_sd_load_idx(env->sd, env->idle);
load_idx = 0;
do { struct sg_lb_stats *sgs = &tmp_sgs;
-- 1.8.1.2
-- Thanks Alex
On 11/19/2013 02:19 PM, Alex Shi wrote:
[ ...]
I don't think the assumption that ARM systems rarely have many tasks running is generally valid. Smartphones do occasionally use all available cpus and ARM systems are used in many other segments.
I only has a panda board in hands, and don't know which benchmark are good for the testing. The key of this patch effect is testing. Anyone like to give a hand on this?
Hi Alex,
I have some hardware here: * 2 x E5345 (bi xeon quad core) * tc2 vexpress * i5
I can give you a hand for testing but as I am very busy on some other stuff, I will let you define the tests to run and the scenario if it is ok for you.
-- Daniel
On 11/19/2013 09:29 PM, Daniel Lezcano wrote:
On 11/19/2013 02:19 PM, Alex Shi wrote:
[ ...]
I don't think the assumption that ARM systems rarely have many tasks running is generally valid. Smartphones do occasionally use all available cpus and ARM systems are used in many other segments.
I only has a panda board in hands, and don't know which benchmark are good for the testing. The key of this patch effect is testing. Anyone like to give a hand on this?
Hi Alex,
I have some hardware here:
- 2 x E5345 (bi xeon quad core)
- tc2 vexpress
- i5
I can give you a hand for testing but as I am very busy on some other stuff, I will let you define the tests to run and the scenario if it is ok for you.
Daniel, Thank you so much for generous help!
I upload my patchset: a78df1a sched: clean up source_load function 0c6f389 sched: remove rq->cpu_load[load_idx] 95da4d4 sched: remove load_idx effect 948aaec sched: remove unused variable in sched_domain
on git@github.com:alexshi/power-scheduling.git no-load-idx This tree also added into intel's 0day kernel testing. so we don't need care the x86 now. Intel will do testing for the tree.
I am going to test hackbench,sysbench, tbench/dbench on my ubuntu-panda. What you prefer benchmarks?
On 11/19/2013 10:11 PM, Alex Shi wrote:
I can give you a hand for testing but as I am very busy on some other stuff, I will let you define the tests to run and the scenario if it is ok for you.
Daniel, Thank you so much for generous help!
I upload my patchset: a78df1a sched: clean up source_load function 0c6f389 sched: remove rq->cpu_load[load_idx] 95da4d4 sched: remove load_idx effect 948aaec sched: remove unused variable in sched_domain
on git@github.com:alexshi/power-scheduling.git no-load-idx This tree also added into intel's 0day kernel testing. so we don't need care the x86 now. Intel will do testing for the tree.
I am going to test hackbench,sysbench, tbench/dbench on my ubuntu-panda. What you prefer benchmarks?
I will setup and do testing tomorrow then give you mine detailed testing steps and ENV. :)
On 11/19/2013 03:21 PM, Alex Shi wrote:
On 11/19/2013 10:11 PM, Alex Shi wrote:
I can give you a hand for testing but as I am very busy on some other stuff, I will let you define the tests to run and the scenario if it is ok for you.
Daniel, Thank you so much for generous help!
I upload my patchset: a78df1a sched: clean up source_load function 0c6f389 sched: remove rq->cpu_load[load_idx] 95da4d4 sched: remove load_idx effect 948aaec sched: remove unused variable in sched_domain
on git@github.com:alexshi/power-scheduling.git no-load-idx This tree also added into intel's 0day kernel testing. so we don't need care the x86 now. Intel will do testing for the tree.
I am going to test hackbench,sysbench, tbench/dbench on my ubuntu-panda. What you prefer benchmarks?
I will setup and do testing tomorrow then give you mine detailed testing steps and ENV. :)
Ok, cool.
On Tue, Nov 19, 2013 at 01:19:51PM +0000, Alex Shi wrote:
On 11/19/2013 08:45 PM, Morten Rasmussen wrote:
On Tue, Nov 19, 2013 at 11:46:19AM +0000, Alex Shi wrote:
We know the load_idx is a decay for cpu_load of rq. After added sched_avg, we has 2 kind decay for cpu_load. That is a kind of redundancy.
This patch remove the load_idx. There are 5 _idx in sched_domain, busy_idx and idle_idx are not zero usually, but newidle_idx, wake_idx and forkexec_idx are all zero on all arch. and this patch remove the only place using busy_idx/idle_idx.
Have you looked into the decay rates of cpu_load[busy_idx] and cpu_load[idle_idx] and compared them to the load in sched_avg?
The sched_avg decay according to active task load history. The cpu_load decay on past cpu load: load = (2^idx - 1) / 2^idx * load + 1 / 2^idx * cur_load These 2 cpu load both decay on time. but sched_avg is a bit more precise.
If I understand the code correctly, idx=0 is the unmodified cpu load from sched_avg. idx=1 is slightly slower reacting (longer decay), but still based on the cpu_load from sched_avg. idx=2 is even slower and so on.
I'm thinking that there must be a reason why they are not all using the same average cpu load.
I asked this for PeterZ. PeterZ had no clear answerer of cpu_load decay usage, and he also thought is these 2 decay have a bit redundance.
As to cpu_load decay, it only used in load_balance. to bias on source cpu or no bias.
Yes. Changing it to use idx=0 (sched_avg cpu_load) probably doesn't change things significantly. I may cause load-balance to become a bit more responsive, which can be both good and bad depending on the workload.
Since arm system rarely has much tasks running in system. this removing
Could you elaborate on the effect of this change?
I don't think the assumption that ARM systems rarely have many tasks running is generally valid. Smartphones do occasionally use all available cpus and ARM systems are used in many other segments.
I only has a panda board in hands, and don't know which benchmark are good for the testing. The key of this patch effect is testing. Anyone like to give a hand on this?
AFAIK, there are no theory can prove which decay is better (but obviously, community prefer to sched_avg, since it was added when cpu_load already existed.)
cpu_load is already based on sched_avg either directly (idx=0) or derrived from it. Essentially, this is all about whether we can get rid of the derrived cpu loads.
Also, this patch will affect all architectures, so we need to ensure that none of them are affected negatively.
Yes, so however detailed we measured on ARM, there must are still much testing/comments on this in community. Anyway, I had tested this patch in Intel platforms, and in fengguang's 0day kernel testing. there are no clear regression, also no clear improvement.
OK. I would not expect to see much difference either. Maybe for workloads that vary in load over time and use many tasks. Some Android workloads, like bbench, have this behaviour.
Morten
OK. I would not expect to see much difference either. Maybe for workloads that vary in load over time and use many tasks. Some Android workloads, like bbench, have this behaviour.
Can bbench be used on ubuntu? google force change my search to 'bench ubuntu' :(
Morten
On Fri, Nov 22, 2013 at 2:25 PM, Alex Shi alex.shi@linaro.org wrote:
OK. I would not expect to see much difference either. Maybe for workloads that vary in load over time and use many tasks. Some Android workloads, like bbench, have this behaviour.
Can bbench be used on ubuntu? google force change my search to 'bench ubuntu' :(
Yes, it should work. Here is a link: http://bbench.eecs.umich.edu/about.html
On 11/22/2013 05:07 PM, Amit Kucheria wrote:
On Fri, Nov 22, 2013 at 2:25 PM, Alex Shi alex.shi@linaro.org wrote:
OK. I would not expect to see much difference either. Maybe for workloads that vary in load over time and use many tasks. Some Android workloads, like bbench, have this behaviour.
Can bbench be used on ubuntu? google force change my search to 'bench ubuntu' :(
Yes, it should work. Here is a link: http://bbench.eecs.umich.edu/about.html
Got it!
linaro-kernel@lists.linaro.org
-
Alex Shi -
Amit Kucheria -
Daniel Lezcano -
Morten Rasmussen -
Vincent Guittot