lkml.org 
[lkml]   [2015]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 0/6] sched/fair: Compute capacity invariant load/utilization tracking
From
Date
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.



\
 
 \ /
  Last update: 2015-09-02 12:21    [W:0.466 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site