Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1207610 > unrolled thread
| Started by | Morten Rasmussen <morten.rasmussen@arm.com> |
|---|---|
| First post | 2015-08-14 18:30 +0200 |
| Last post | 2015-08-17 13:50 +0200 |
| Articles | 8 — 3 participants |
Back to article view | Back to linux.kernel
[PATCH 0/6] sched/fair: Compute capacity invariant load/utilization tracking Morten Rasmussen <morten.rasmussen@arm.com> - 2015-08-14 18:30 +0200
[PATCH 4/6] sched/fair: Name utilization related data and functions consistently Morten Rasmussen <morten.rasmussen@arm.com> - 2015-08-14 18:30 +0200
[PATCH 6/6] sched/fair: Initialize task load and utilization before placing task on rq Morten Rasmussen <morten.rasmussen@arm.com> - 2015-08-14 18:30 +0200
[PATCH 3/6] sched/fair: Make utilization tracking cpu scale-invariant Morten Rasmussen <morten.rasmussen@arm.com> - 2015-08-14 18:30 +0200
Re: [PATCH 3/6] sched/fair: Make utilization tracking cpu scale-invariant Dietmar Eggemann <dietmar.eggemann@arm.com> - 2015-08-15 01:10 +0200
Re: [PATCH 0/6] sched/fair: Compute capacity invariant load/utilization tracking Peter Zijlstra <peterz@infradead.org> - 2015-08-17 00:10 +0200
Re: [PATCH 0/6] sched/fair: Compute capacity invariant load/utilization tracking Morten Rasmussen <morten.rasmussen@arm.com> - 2015-08-17 13:30 +0200
Re: [PATCH 0/6] sched/fair: Compute capacity invariant load/utilization tracking Peter Zijlstra <peterz@infradead.org> - 2015-08-17 13:50 +0200
| From | Morten Rasmussen <morten.rasmussen@arm.com> |
|---|---|
| Date | 2015-08-14 18:30 +0200 |
| Subject | [PATCH 0/6] sched/fair: Compute capacity invariant load/utilization tracking |
| Message-ID | <pXq1H-7le-7@gated-at.bofh.it> |
Per-entity load-tracking currently only compensates for frequency scaling for
utilization tracking. This patch set extends this compensation to load as well,
and adds compute capacity (different microarchitectures and/or max
frequency/P-state) invariance to utilization. The former prevents suboptimal
load-balancing decisions when cpus run at different frequencies, while the
latter ensures that utilization (sched_avg.util_avg) can be compared across
cpus and that utilization can be compared directly to cpu capacity to determine
if the cpu is overloaded.
Note that this patch only contains the scheduler patches, the architecture
specific implementations of arch_scale_{freq, cpu}_capacity() will be posted
separately later.
The patches have posted several times before. Most recently as part of the
energy-model driven scheduling RFCv5 patch set [1] (patch #2,4,6,8-12). That
RFC also contains patches for the architecture specific side. In this posting
the commit messages have been updated and the patches have been rebased on a
more recent tip/sched/core that includes Yuyang's rewrite which made some of
the previously posted patches redundant.
Target: ARM TC2 A7-only (x3)
Test: hackbench -g 25 --threads -l 10000
Before After
315.545 313.408 -0.68%
Target: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz
Test: hackbench -g 25 --threads -l 1000 (avg of 10)
Before After
6.4643 6.395 -1.07%
[1] http://www.kernelhub.org/?p=2&msg=787634
Dietmar Eggemann (4):
sched/fair: Make load tracking frequency scale-invariant
sched/fair: Make utilization tracking cpu scale-invariant
sched/fair: Name utilization related data and functions consistently
sched/fair: Get rid of scaling utilization by capacity_orig
Morten Rasmussen (2):
sched/fair: Convert arch_scale_cpu_capacity() from weak function to
#define
sched/fair: Initialize task load and utilization before placing task
on rq
include/linux/sched.h | 8 ++--
kernel/sched/core.c | 4 +-
kernel/sched/fair.c | 109 +++++++++++++++++++++++-------------------------
kernel/sched/features.h | 5 ---
kernel/sched/sched.h | 11 +++++
5 files changed, 69 insertions(+), 68 deletions(-)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Morten Rasmussen <morten.rasmussen@arm.com> |
|---|---|
| Date | 2015-08-14 18:30 +0200 |
| Subject | [PATCH 4/6] sched/fair: Name utilization related data and functions consistently |
| Message-ID | <pXq1H-7le-17@gated-at.bofh.it> |
| In reply to | #1207610 |
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
Use the advent of the per-entity load tracking rewrite to streamline the
naming of utilization related data and functions by using
{prefix_}util{_suffix} consistently. Moreover call both signals
({se,cfs}.avg.util_avg) utilization.
Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com>
---
kernel/sched/fair.c | 37 +++++++++++++++++++------------------
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 63be5a5..4cc3050 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4825,31 +4825,32 @@ static int select_idle_sibling(struct task_struct *p, int target)
return target;
}
/*
- * get_cpu_usage returns the amount of capacity of a CPU that is used by CFS
+ * cpu_util returns the amount of capacity of a CPU that is used by CFS
* tasks. The unit of the return value must be the one of capacity so we can
- * compare the usage with the capacity of the CPU that is available for CFS
- * task (ie cpu_capacity).
+ * compare the utilization with the capacity of the CPU that is available for
+ * CFS task (ie cpu_capacity).
* cfs.avg.util_avg is the sum of running time of runnable tasks on a
* CPU. It represents the amount of utilization of a CPU in the range
- * [0..SCHED_LOAD_SCALE]. The usage of a CPU can't be higher than the full
- * capacity of the CPU because it's about the running time on this CPU.
+ * [0..SCHED_LOAD_SCALE]. The utilization of a CPU can't be higher than the
+ * full capacity of the CPU because it's about the running time on this CPU.
* Nevertheless, cfs.avg.util_avg can be higher than SCHED_LOAD_SCALE
* because of unfortunate rounding in util_avg or just
* after migrating tasks until the average stabilizes with the new running
- * time. So we need to check that the usage stays into the range
+ * time. So we need to check that the utilization stays into the range
* [0..cpu_capacity_orig] and cap if necessary.
- * Without capping the usage, a group could be seen as overloaded (CPU0 usage
- * at 121% + CPU1 usage at 80%) whereas CPU1 has 20% of available capacity
+ * Without capping the utilization, a group could be seen as overloaded (CPU0
+ * utilization at 121% + CPU1 utilization at 80%) whereas CPU1 has 20% of
+ * available capacity.
*/
-static int get_cpu_usage(int cpu)
+static int cpu_util(int cpu)
{
- unsigned long usage = cpu_rq(cpu)->cfs.avg.util_avg;
+ unsigned long util = cpu_rq(cpu)->cfs.avg.util_avg;
unsigned long capacity = capacity_orig_of(cpu);
- if (usage >= SCHED_LOAD_SCALE)
+ if (util >= SCHED_LOAD_SCALE)
return capacity;
- return (usage * capacity) >> SCHED_LOAD_SHIFT;
+ return (util * capacity) >> SCHED_LOAD_SHIFT;
}
/*
@@ -5941,7 +5942,7 @@ struct sg_lb_stats {
unsigned long sum_weighted_load; /* Weighted load of group's tasks */
unsigned long load_per_task;
unsigned long group_capacity;
- unsigned long group_usage; /* Total usage of the group */
+ unsigned long group_util; /* Total utilization of the group */
unsigned int sum_nr_running; /* Nr tasks running in the group */
unsigned int idle_cpus;
unsigned int group_weight;
@@ -6174,8 +6175,8 @@ static inline int sg_imbalanced(struct sched_group *group)
* group_has_capacity returns true if the group has spare capacity that could
* be used by some tasks.
* We consider that a group has spare capacity if the * number of task is
- * smaller than the number of CPUs or if the usage is lower than the available
- * capacity for CFS tasks.
+ * smaller than the number of CPUs or if the utilization is lower than the
+ * available capacity for CFS tasks.
* For the latter, we use a threshold to stabilize the state, to take into
* account the variance of the tasks' load and to return true if the available
* capacity in meaningful for the load balancer.
@@ -6189,7 +6190,7 @@ group_has_capacity(struct lb_env *env, struct sg_lb_stats *sgs)
return true;
if ((sgs->group_capacity * 100) >
- (sgs->group_usage * env->sd->imbalance_pct))
+ (sgs->group_util * env->sd->imbalance_pct))
return true;
return false;
@@ -6210,7 +6211,7 @@ group_is_overloaded(struct lb_env *env, struct sg_lb_stats *sgs)
return false;
if ((sgs->group_capacity * 100) <
- (sgs->group_usage * env->sd->imbalance_pct))
+ (sgs->group_util * env->sd->imbalance_pct))
return true;
return false;
@@ -6258,7 +6259,7 @@ static inline void update_sg_lb_stats(struct lb_env *env,
load = source_load(i, load_idx);
sgs->group_load += load;
- sgs->group_usage += get_cpu_usage(i);
+ sgs->group_util += cpu_util(i);
sgs->sum_nr_running += rq->cfs.h_nr_running;
if (rq->nr_running > 1)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Morten Rasmussen <morten.rasmussen@arm.com> |
|---|---|
| Date | 2015-08-14 18:30 +0200 |
| Subject | [PATCH 6/6] sched/fair: Initialize task load and utilization before placing task on rq |
| Message-ID | <pXq1H-7le-15@gated-at.bofh.it> |
| In reply to | #1207610 |
Task load or utilization is not currently considered in select_task_rq_fair(), but if we want that in the future we should make sure it is not zero for new tasks. cc: Ingo Molnar <mingo@redhat.com> cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com> --- kernel/sched/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index b11f624..ae9fca32 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -2294,6 +2294,8 @@ void wake_up_new_task(struct task_struct *p) struct rq *rq; raw_spin_lock_irqsave(&p->pi_lock, flags); + /* Initialize new task's runnable average */ + init_entity_runnable_average(&p->se); #ifdef CONFIG_SMP /* * Fork balancing, do it here and not earlier because: @@ -2303,8 +2305,6 @@ void wake_up_new_task(struct task_struct *p) set_task_cpu(p, select_task_rq(p, task_cpu(p), SD_BALANCE_FORK, 0)); #endif - /* Initialize new task's runnable average */ - init_entity_runnable_average(&p->se); rq = __task_rq_lock(p); activate_task(rq, p, 0); p->on_rq = TASK_ON_RQ_QUEUED; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Morten Rasmussen <morten.rasmussen@arm.com> |
|---|---|
| Date | 2015-08-14 18:30 +0200 |
| Subject | [PATCH 3/6] sched/fair: Make utilization tracking cpu scale-invariant |
| Message-ID | <pXq1I-7le-19@gated-at.bofh.it> |
| In reply to | #1207610 |
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
Besides the existing frequency scale-invariance correction factor, apply
cpu scale-invariance correction factor to utilization tracking to
compensate for any differences in compute capacity. This could be due to
micro-architectural differences (i.e. instructions per seconds) between
cpus in HMP systems (e.g. big.LITTLE), and/or differences in the current
maximum frequency supported by individual cpus in SMP systems. In the
existing implementation utilization isn't comparable between cpus as it
is relative to the capacity of each individual cpu.
Each segment of the sched_avg.util_sum geometric series is now scaled
by the cpu performance factor too so the sched_avg.util_avg of each
sched entity will be invariant from the particular cpu of the HMP/SMP
system on which the sched entity is scheduled.
With this patch, the utilization of a cpu stays relative to the max cpu
performance of the fastest cpu in the system.
In contrast to utilization (sched_avg.util_sum), load
(sched_avg.load_sum) should not be scaled by compute capacity. The
utilization metric is based on running time which only makes sense when
cpus are _not_ fully utilized (utilization cannot go beyond 100% even if
more tasks are added), where load is runnable time which isn't limited
by the capacity of the cpu and therefore is a better metric for
overloaded scenarios. If we run two nice-0 busy loops on two cpus with
different compute capacity their load should be similar since their
compute demands are the same. We have to assume that the compute demand
of any task running on a fully utilized cpu (no spare cycles = 100%
utilization) is high and the same no matter of the compute capacity of
its current cpu, hence we shouldn't scale load by cpu capacity.
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com>
---
include/linux/sched.h | 2 +-
kernel/sched/fair.c | 7 ++++---
kernel/sched/sched.h | 2 +-
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index a153051..78a93d7 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1180,7 +1180,7 @@ struct load_weight {
* 1) load_avg factors frequency scaling into the amount of time that a
* sched_entity is runnable on a rq into its weight. For cfs_rq, it is the
* aggregated such weights of all runnable and blocked sched_entities.
- * 2) util_avg factors frequency scaling into the amount of time
+ * 2) util_avg factors frequency and cpu scaling into the amount of time
* that a sched_entity is running on a CPU, in the range [0..SCHED_LOAD_SCALE].
* For cfs_rq, it is the aggregated such times of all runnable and
* blocked sched_entities.
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index c72223a..63be5a5 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2553,6 +2553,7 @@ __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
u32 contrib;
int delta_w, scaled_delta_w, decayed = 0;
unsigned long scale_freq = arch_scale_freq_capacity(NULL, cpu);
+ unsigned long scale_cpu = arch_scale_cpu_capacity(NULL, cpu);
delta = now - sa->last_update_time;
/*
@@ -2596,7 +2597,7 @@ __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
}
}
if (running)
- sa->util_sum += scaled_delta_w;
+ sa->util_sum = scale(scaled_delta_w, scale_cpu);
delta -= delta_w;
@@ -2620,7 +2621,7 @@ __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
cfs_rq->runnable_load_sum += weight * contrib;
}
if (running)
- sa->util_sum += contrib;
+ sa->util_sum += scale(contrib, scale_cpu);
}
/* Remainder of delta accrued against u_0` */
@@ -2631,7 +2632,7 @@ __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
cfs_rq->runnable_load_sum += weight * scaled_delta;
}
if (running)
- sa->util_sum += scaled_delta;
+ sa->util_sum += scale(scaled_delta, scale_cpu);
sa->period_contrib += delta;
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 7e6f250..50836a9 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1406,7 +1406,7 @@ unsigned long arch_scale_freq_capacity(struct sched_domain *sd, int cpu)
static __always_inline
unsigned long arch_scale_cpu_capacity(struct sched_domain *sd, int cpu)
{
- if ((sd->flags & SD_SHARE_CPUCAPACITY) && (sd->span_weight > 1))
+ if (sd && (sd->flags & SD_SHARE_CPUCAPACITY) && (sd->span_weight > 1))
return sd->smt_gain / sd->span_weight;
return SCHED_CAPACITY_SCALE;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Dietmar Eggemann <dietmar.eggemann@arm.com> |
|---|---|
| Date | 2015-08-15 01:10 +0200 |
| Subject | Re: [PATCH 3/6] sched/fair: Make utilization tracking cpu scale-invariant |
| Message-ID | <pXwgN-7Yv-7@gated-at.bofh.it> |
| In reply to | #1207614 |
On 14/08/15 17:23, Morten Rasmussen wrote:
> From: Dietmar Eggemann <dietmar.eggemann@arm.com>
[...]
> @@ -2596,7 +2597,7 @@ __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
> }
> }
> if (running)
> - sa->util_sum += scaled_delta_w;
> + sa->util_sum = scale(scaled_delta_w, scale_cpu);
There is a small issue (using = instead of +=) with fatal consequences
for the utilization signal.
-- >8 --
Subject: [PATCH] sched/fair: Make utilization tracking cpu scale-invariant
Besides the existing frequency scale-invariance correction factor, apply
cpu scale-invariance correction factor to utilization tracking to
compensate for any differences in compute capacity. This could be due to
micro-architectural differences (i.e. instructions per seconds) between
cpus in HMP systems (e.g. big.LITTLE), and/or differences in the current
maximum frequency supported by individual cpus in SMP systems. In the
existing implementation utilization isn't comparable between cpus as it
is relative to the capacity of each individual cpu.
Each segment of the sched_avg.util_sum geometric series is now scaled
by the cpu performance factor too so the sched_avg.util_avg of each
sched entity will be invariant from the particular cpu of the HMP/SMP
system on which the sched entity is scheduled.
With this patch, the utilization of a cpu stays relative to the max cpu
performance of the fastest cpu in the system.
In contrast to utilization (sched_avg.util_sum), load
(sched_avg.load_sum) should not be scaled by compute capacity. The
utilization metric is based on running time which only makes sense when
cpus are _not_ fully utilized (utilization cannot go beyond 100% even if
more tasks are added), where load is runnable time which isn't limited
by the capacity of the cpu and therefore is a better metric for
overloaded scenarios. If we run two nice-0 busy loops on two cpus with
different compute capacity their load should be similar since their
compute demands are the same. We have to assume that the compute demand
of any task running on a fully utilized cpu (no spare cycles = 100%
utilization) is high and the same no matter of the compute capacity of
its current cpu, hence we shouldn't scale load by cpu capacity.
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com>
---
include/linux/sched.h | 2 +-
kernel/sched/fair.c | 7 ++++---
kernel/sched/sched.h | 2 +-
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index a15305117ace..78a93d716fcb 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1180,7 +1180,7 @@ struct load_weight {
* 1) load_avg factors frequency scaling into the amount of time that a
* sched_entity is runnable on a rq into its weight. For cfs_rq, it is the
* aggregated such weights of all runnable and blocked sched_entities.
- * 2) util_avg factors frequency scaling into the amount of time
+ * 2) util_avg factors frequency and cpu scaling into the amount of time
* that a sched_entity is running on a CPU, in the range [0..SCHED_LOAD_SCALE].
* For cfs_rq, it is the aggregated such times of all runnable and
* blocked sched_entities.
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index c72223a299a8..3321eb13e422 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2553,6 +2553,7 @@ __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
u32 contrib;
int delta_w, scaled_delta_w, decayed = 0;
unsigned long scale_freq = arch_scale_freq_capacity(NULL, cpu);
+ unsigned long scale_cpu = arch_scale_cpu_capacity(NULL, cpu);
delta = now - sa->last_update_time;
/*
@@ -2596,7 +2597,7 @@ __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
}
}
if (running)
- sa->util_sum += scaled_delta_w;
+ sa->util_sum += scale(scaled_delta_w, scale_cpu);
delta -= delta_w;
@@ -2620,7 +2621,7 @@ __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
cfs_rq->runnable_load_sum += weight * contrib;
}
if (running)
- sa->util_sum += contrib;
+ sa->util_sum += scale(contrib, scale_cpu);
}
/* Remainder of delta accrued against u_0` */
@@ -2631,7 +2632,7 @@ __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
cfs_rq->runnable_load_sum += weight * scaled_delta;
}
if (running)
- sa->util_sum += scaled_delta;
+ sa->util_sum += scale(scaled_delta, scale_cpu);
sa->period_contrib += delta;
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 7e6f2506a402..50836a9301f9 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1406,7 +1406,7 @@ unsigned long arch_scale_freq_capacity(struct sched_domain *sd, int cpu)
static __always_inline
unsigned long arch_scale_cpu_capacity(struct sched_domain *sd, int cpu)
{
- if ((sd->flags & SD_SHARE_CPUCAPACITY) && (sd->span_weight > 1))
+ if (sd && (sd->flags & SD_SHARE_CPUCAPACITY) && (sd->span_weight > 1))
return sd->smt_gain / sd->span_weight;
return SCHED_CAPACITY_SCALE;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2015-08-17 00:10 +0200 |
| Subject | Re: [PATCH 0/6] sched/fair: Compute capacity invariant load/utilization tracking |
| Message-ID | <pYehP-4Ic-5@gated-at.bofh.it> |
| In reply to | #1207610 |
On Fri, Aug 14, 2015 at 05:23:08PM +0100, Morten Rasmussen wrote: > Target: ARM TC2 A7-only (x3) > Test: hackbench -g 25 --threads -l 10000 > > Before After > 315.545 313.408 -0.68% > > Target: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz > Test: hackbench -g 25 --threads -l 1000 (avg of 10) > > Before After > 6.4643 6.395 -1.07% Yeah, so that is a problem. I'm taking it some of the new scaling stuff doesn't compile away, can we look at fixing that? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Morten Rasmussen <morten.rasmussen@arm.com> |
|---|---|
| Date | 2015-08-17 13:30 +0200 |
| Subject | Re: [PATCH 0/6] sched/fair: Compute capacity invariant load/utilization tracking |
| Message-ID | <pYqM2-5T7-13@gated-at.bofh.it> |
| In reply to | #1208280 |
On Sun, Aug 16, 2015 at 10:46:05PM +0200, Peter Zijlstra wrote: > On Fri, Aug 14, 2015 at 05:23:08PM +0100, Morten Rasmussen wrote: > > Target: ARM TC2 A7-only (x3) > > Test: hackbench -g 25 --threads -l 10000 > > > > Before After > > 315.545 313.408 -0.68% > > > > Target: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz > > Test: hackbench -g 25 --threads -l 1000 (avg of 10) > > > > Before After > > 6.4643 6.395 -1.07% > > Yeah, so that is a problem. Maybe I'm totally wrong, but doesn't hackbench report execution so less is better? In that case -1.07% means we are doing better with the patches applied (after time < before time). In any case, I should have indicated whether the change is good or bad for performance. > I'm taking it some of the new scaling stuff doesn't compile away, can we > look at fixing that? I will double-check that the stuff goes away as expected. I'm pretty sure it does on ARM. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2015-08-17 13:50 +0200 |
| Subject | Re: [PATCH 0/6] sched/fair: Compute capacity invariant load/utilization tracking |
| Message-ID | <pYr5o-6fG-5@gated-at.bofh.it> |
| In reply to | #1208539 |
On Mon, Aug 17, 2015 at 12:29:51PM +0100, Morten Rasmussen wrote: > On Sun, Aug 16, 2015 at 10:46:05PM +0200, Peter Zijlstra wrote: > > On Fri, Aug 14, 2015 at 05:23:08PM +0100, Morten Rasmussen wrote: > > > Target: ARM TC2 A7-only (x3) > > > Test: hackbench -g 25 --threads -l 10000 > > > > > > Before After > > > 315.545 313.408 -0.68% > > > > > > Target: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz > > > Test: hackbench -g 25 --threads -l 1000 (avg of 10) > > > > > > Before After > > > 6.4643 6.395 -1.07% > > > > Yeah, so that is a problem. > > Maybe I'm totally wrong, but doesn't hackbench report execution so less > is better? In that case -1.07% means we are doing better with the > patches applied (after time < before time). In any case, I should have > indicated whether the change is good or bad for performance. > > > I'm taking it some of the new scaling stuff doesn't compile away, can we > > look at fixing that? > > I will double-check that the stuff goes away as expected. I'm pretty > sure it does on ARM. Ah, uhm.. you have a point there ;-) I'll run the numbers when I'm back home again. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web