From patchwork Mon Sep 7 14:44:57 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dietmar Eggemann X-Patchwork-Id: 53243 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-wi0-f198.google.com (mail-wi0-f198.google.com [209.85.212.198]) by patches.linaro.org (Postfix) with ESMTPS id 7A06622B05 for ; Mon, 7 Sep 2015 14:45:12 +0000 (UTC) Received: by wicuu12 with SMTP id uu12sf27146251wic.2 for ; Mon, 07 Sep 2015 07:45:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:subject:to:references:cc:from :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding:sender:precedence:list-id :x-original-sender:x-original-authentication-results:mailing-list :list-post:list-help:list-archive:list-unsubscribe; bh=TGkZKqFqRojEoSXqiEZemFTJdDX4070QWaDJLY74jt8=; b=a0O0B+Zwm/mWD0Ma77+z5KIUlRWU6gbjrfm6gBQGMreiGghfqO8nW4hdhuxpF6wAFi YVb6H0U4DMrIWQtSXDHaB2q4hm9qtIHwcZ5XEoyiWWe0VTlzLh5E8/KK9o4P7SiKH8KR 119oBG7xVufklzOFfAcdF1hRoVS8M/ekmNfyJwZlfj//zPsLfI/D43GFAsRTyARyQBj5 RWEoZVa+sY471V5pJHRGehAuFTUVQqC31NG+kEus1yA/xMFE/95rTmOVTVfJ6c5i92pg uNXflHsrYM3FjHso28bSQvbpKX5XhTuIxtJbARpFGAP12ZAbrBG9MKf1OdQG7yb8p5jl kBwQ== X-Gm-Message-State: ALoCoQmiduwUeeujIPPxFXhszX8QmpRodPYfLTVF+dxJO5uUnKCOeBkgYJbFvth+ZwqtEBuQ0IYm X-Received: by 10.152.21.233 with SMTP id y9mr5105792lae.5.1441637111791; Mon, 07 Sep 2015 07:45:11 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.152.4.71 with SMTP id i7ls211718lai.11.gmail; Mon, 07 Sep 2015 07:45:11 -0700 (PDT) X-Received: by 10.153.7.172 with SMTP id dd12mr17425874lad.25.1441637111503; Mon, 07 Sep 2015 07:45:11 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com. [209.85.215.51]) by mx.google.com with ESMTPS id an5si147585lac.166.2015.09.07.07.45.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Sep 2015 07:45:11 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.51 as permitted sender) client-ip=209.85.215.51; Received: by laeb10 with SMTP id b10so53733777lae.1 for ; Mon, 07 Sep 2015 07:45:11 -0700 (PDT) X-Received: by 10.112.77.10 with SMTP id o10mr17303285lbw.73.1441637111390; Mon, 07 Sep 2015 07:45:11 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.112.59.35 with SMTP id w3csp416513lbq; Mon, 7 Sep 2015 07:45:10 -0700 (PDT) X-Received: by 10.66.193.230 with SMTP id hr6mr46619289pac.39.1441637110168; Mon, 07 Sep 2015 07:45:10 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id li9si86020pbc.131.2015.09.07.07.45.09; Mon, 07 Sep 2015 07:45:10 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752732AbbIGOpH (ORCPT + 28 others); Mon, 7 Sep 2015 10:45:07 -0400 Received: from eu-smtp-delivery-143.mimecast.com ([146.101.78.143]:11420 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750898AbbIGOpB convert rfc822-to-8bit (ORCPT ); Mon, 7 Sep 2015 10:45:01 -0400 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-15-kiCQrlj7SNGBVXz_54xaCQ-1; Mon, 07 Sep 2015 15:44:58 +0100 Received: from [10.2.131.51] ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2015 15:44:58 +0100 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> <20150907124220.GT18673@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: <55EDA2E9.8040900@arm.com> Date: Mon, 7 Sep 2015 15:44:57 +0100 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: <20150907124220.GT18673@twins.programming.kicks-ass.net> X-OriginalArrivalTime: 07 Sep 2015 14:44:58.0570 (UTC) FILETIME=[C4CC0AA0:01D0E97B] X-MC-Unique: kiCQrlj7SNGBVXz_54xaCQ-1 Sender: linux-kernel-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: dietmar.eggemann@arm.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.51 as permitted sender) smtp.mailfrom=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , On 07/09/15 13:42, Peter Zijlstra wrote: > On Mon, Aug 31, 2015 at 11:24:49AM +0200, Peter Zijlstra wrote: > >> A quick run here gives: >> >> IVB-EP (2*20*2): > > As noted by someone; that should be 2*10*2, for a total of 40 cpus in > this machine. > >> >> 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. > > OK, so it appears this is link order nonsense. When I compared profiles > between the series, the one function that had significant change was > skb_release_data(), which doesn't make much sense. > > If I do a 'make clean' in front of each build, I get a repeatable > improvement with this patch set (although how much of that is due to the > patches itself or just because of code movement is as yet undetermined). > > I'm of a mind to apply these patches; with two patches on top, which > I'll post shortly. > -- >8 -- From: Dietmar Eggemann Date: Mon, 7 Sep 2015 14:57:22 +0100 Subject: [PATCH] sched/fair: Defer calling scaling functions Do not call the scaling functions in case time goes backwards or the last update of the sched_avg structure has happened less than 1024ns ago. Signed-off-by: Dietmar Eggemann --- kernel/sched/fair.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index d6ca8d987a63..3445d2fb38f4 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -2552,8 +2552,7 @@ __update_load_avg(u64 now, int cpu, struct sched_avg *sa, u64 delta, scaled_delta, periods; u32 contrib; unsigned 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); + unsigned long scale_freq, scale_cpu; delta = now - sa->last_update_time; /* @@ -2574,6 +2573,9 @@ __update_load_avg(u64 now, int cpu, struct sched_avg *sa, return 0; sa->last_update_time = now; + scale_freq = arch_scale_freq_capacity(NULL, cpu); + scale_cpu = arch_scale_cpu_capacity(NULL, cpu); + /* delta_w is the amount already accumulated against our next period */ delta_w = sa->period_contrib; if (delta + delta_w >= 1024) {