[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55E6C6A8.2060809@arm.com>
Date: Wed, 2 Sep 2015 11:51:36 +0200
From: Dietmar Eggemann <dietmar.eggemann@....com>
To: Peter Zijlstra <peterz@...radead.org>,
Morten Rasmussen <Morten.Rasmussen@....com>
Cc: "mingo@...hat.com" <mingo@...hat.com>,
"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
"daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>,
"yuyang.du@...el.com" <yuyang.du@...el.com>,
"mturquette@...libre.com" <mturquette@...libre.com>,
"rjw@...ysocki.net" <rjw@...ysocki.net>,
Juri Lelli <Juri.Lelli@....com>,
"sgurrappadi@...dia.com" <sgurrappadi@...dia.com>,
"pang.xunlei@....com.cn" <pang.xunlei@....com.cn>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/6] sched/fair: Compute capacity invariant
load/utilization tracking
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists