Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1216122 > unrolled thread
| Started by | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| First post | 2015-08-31 11:30 +0200 |
| Last post | 2015-09-02 12:00 +0200 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH 0/6] sched/fair: Compute capacity invariant load/utilization tracking Peter Zijlstra <peterz@infradead.org> - 2015-08-31 11:30 +0200
Re: [PATCH 0/6] sched/fair: Compute capacity invariant load/utilization tracking Dietmar Eggemann <dietmar.eggemann@arm.com> - 2015-09-02 12:00 +0200
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2015-08-31 11:30 +0200 |
| Subject | Re: [PATCH 0/6] sched/fair: Compute capacity invariant load/utilization tracking |
| Message-ID | <q3tzz-3A1-1@gated-at.bofh.it> |
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% > A quick run here gives: IVB-EP (2*20*2): perf stat --null --repeat 10 -- perf bench sched messaging -g 50 -l 5000 Before: After: 5.484170711 ( +- 0.74% ) 5.590001145 ( +- 0.45% ) Which is an almost 2% slowdown :/ I've yet to look at what happens. -- 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 | Dietmar Eggemann <dietmar.eggemann@arm.com> |
|---|---|
| Date | 2015-09-02 12:00 +0200 |
| Message-ID | <q4cZI-1tV-29@gated-at.bofh.it> |
| In reply to | #1216122 |
On 08/31/2015 11:24 AM, 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% >> > > A quick run here gives: > > IVB-EP (2*20*2): > > perf stat --null --repeat 10 -- perf bench sched messaging -g 50 -l 5000 > > Before: After: > 5.484170711 ( +- 0.74% ) 5.590001145 ( +- 0.45% ) > > Which is an almost 2% slowdown :/ > > I've yet to look at what happens. > I tested the patch-set on top of tip: ff277d4250fe - sched/deadline: Fix comment in enqueue_task_dl() on a 2 cluster IVB-EP (2 clusters * 10 cores * 2 HW threads) = 40 logical cpus w/ (SMT, MC, NUMA sd's). model name : Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz perf stat --null --repeat 10 -- perf bench sched messaging -g 50 -l 5000 Before: After: 5.049361160 ( +- 1.26% ) 5.014980654 ( +- 1.20% ) Even by running this test multiple times I never saw something like a 2% slowdown. It's a vanilla ubuntu 15.04 system which might explain the slightly higher stddev. We could optimize the changes we did in __update_load_avg() by only calculating the additional scaled values [scaled_delta_w, contrib, scaled_delta] in case the function is called w/ 'weight !=0 && running !=0'. This is also true for the initialization of scale_freq and scale_cpu. -- 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