From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 224A4C46475 for ; Thu, 25 Oct 2018 11:08:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D65C22075D for ; Thu, 25 Oct 2018 11:08:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D65C22075D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727458AbeJYTlH (ORCPT ); Thu, 25 Oct 2018 15:41:07 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:55170 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727398AbeJYTlH (ORCPT ); Thu, 25 Oct 2018 15:41:07 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 371D9A78; Thu, 25 Oct 2018 04:08:50 -0700 (PDT) Received: from [0.0.0.0] (e107985-lin.cambridge.arm.com [10.1.194.38]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 027893F627; Thu, 25 Oct 2018 04:08:47 -0700 (PDT) Subject: Re: [PATCH v4 2/2] sched/fair: update scale invariance of PELT To: Vincent Guittot Cc: Peter Zijlstra , Ingo Molnar , linux-kernel , "Rafael J. Wysocki" , Morten Rasmussen , Patrick Bellasi , Paul Turner , Ben Segall , Thara Gopinath References: <1539965871-22410-1-git-send-email-vincent.guittot@linaro.org> <1539965871-22410-3-git-send-email-vincent.guittot@linaro.org> <43b126ab-403b-3fb3-5951-45a107e4a14b@arm.com> From: Dietmar Eggemann Message-ID: <395c9d6d-e717-69a5-f54c-5b3c3845f0ef@arm.com> Date: Thu, 25 Oct 2018 13:08:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/25/18 12:43 PM, Vincent Guittot wrote: > On Thu, 25 Oct 2018 at 12:36, Dietmar Eggemann wrote: [...] >> I have a couple of questions related to the tests you ran. >> >>> On a hikey (octo ARM platform). >>> Performance cpufreq governor and only shallowest c-state to remove variance >>> generated by those power features so we only track the impact of pelt algo. >> >> So you disabled c-state 'cpu-sleep' and 'cluster-sleep'? > > yes > >> >> I get 'hisi_thermal f7030700.tsensor: THERMAL ALARM: 66385 > 65000' on >> my hikey620. Did you change the thermal configuration? Not sure if there >> are any actions attached to this warning though. > > I have a fan to ensure that no thermal mitigation will bias the measurement. Great, with a fan they disappear here as well. >>> each test runs 16 times >>> >>> ./perf bench sched pipe >>> (higher is better) >>> kernel tip/sched/core + patch >>> ops/seconds ops/seconds diff >>> cgroup >>> root 59648(+/- 0.13%) 59785(+/- 0.24%) +0.23% >>> level1 55570(+/- 0.21%) 56003(+/- 0.24%) +0.78% >>> level2 52100(+/- 0.20%) 52788(+/- 0.22%) +1.32% >>> >>> hackbench -l 1000 >> >> Shouldn't this be '-l 100'? > > I have re checked and it's -l 1000 Strange, when I run hackbench on this board (performance governor) I get values like: root@h620:/# hackbench -l 100 Running in process mode with 10 groups using 40 file descriptors each (== 400 tasks) Each sender will pass 100 messages of 100 bytes Time: 4.023 root@h620:/# hackbench -l 1000 Running in process mode with 10 groups using 40 file descriptors each (== 400 tasks) Each sender will pass 1000 messages of 100 bytes Time: 37.883 Since you have values in the range of 4-6 secs in your hackbench table? Maybe different hackbench versions? >>> (lower is better) >>> kernel tip/sched/core + patch >>> duration(sec) duration(sec) diff >>> cgroup >>> root 4.472(+/- 1.86%) 4.346(+/- 2.74%) -2.80% >>> level1 5.039(+/- 11.05%) 4.662(+/- 7.57%) -7.47% >>> level2 5.195(+/- 10.66%) 4.877(+/- 8.90%) -6.12% >>> >>> The responsivness of PELT is improved when CPU is not running at max >>> capacity with this new algorithm. I have put below some examples of >>> duration to reach some typical load values according to the capacity of the >>> CPU with current implementation and with this patch. >>> >>> Util (%) max capacity half capacity(mainline) half capacity(w/ patch) >>> 972 (95%) 138ms not reachable 276ms >>> 486 (47.5%) 30ms 138ms 60ms >>> 256 (25%) 13ms 32ms 26ms >> >> Could you describe these testcases in more detail? > > You don't need to run test case. These numbers are computed based on > geometric series and half period value Ah, ok, maybe you can mention this explicitly. [...] >> What's the initial utilization value of t1? I assume t1 starts with >> utilization=512 (post_init_entity_util_avg()). OK, then it's starts at 0. >>> On my hikey (octo ARM platform) with schedutil governor, the time to reach >>> max OPP when starting from a null utilization, decreases from 223ms with >>> current scale invariance down to 121ms with the new algorithm. For this >>> test, I have enable arch_scale_freq for arm64. >> >> Isn't the arch-specific arch_scale_freq_capacity() enabled by default on >> arm64 with cpufreq support? > > Yes. that's a remain of previous version when arch_scale_freq was not yet merged OK. [...]