From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753917AbbIBJvp (ORCPT ); Wed, 2 Sep 2015 05:51:45 -0400 Received: from eu-smtp-delivery-143.mimecast.com ([207.82.80.143]:44661 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750971AbbIBJvn convert rfc822-to-8bit (ORCPT ); Wed, 2 Sep 2015 05:51:43 -0400 Subject: Re: [PATCH 0/6] sched/fair: Compute capacity invariant load/utilization tracking To: Peter Zijlstra , Morten Rasmussen References: <1439569394-11974-1-git-send-email-morten.rasmussen@arm.com> <20150831092449.GJ19282@twins.programming.kicks-ass.net> Cc: "mingo@redhat.com" , "vincent.guittot@linaro.org" , "daniel.lezcano@linaro.org" , "yuyang.du@intel.com" , "mturquette@baylibre.com" , "rjw@rjwysocki.net" , Juri Lelli , "sgurrappadi@nvidia.com" , "pang.xunlei@zte.com.cn" , "linux-kernel@vger.kernel.org" From: Dietmar Eggemann Message-ID: <55E6C6A8.2060809@arm.com> Date: Wed, 2 Sep 2015 11:51:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150831092449.GJ19282@twins.programming.kicks-ass.net> X-OriginalArrivalTime: 02 Sep 2015 09:51:37.0534 (UTC) FILETIME=[F5B255E0:01D0E564] X-MC-Unique: XQuxFSUTT-aYQOnduWjHCw-1 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.