Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp682408ybl; Wed, 29 Jan 2020 07:51:58 -0800 (PST) X-Google-Smtp-Source: APXvYqwFN71VxXjWeRiQcgfTs1CVgZxsIKh2p+uJnckOYecE+5eFRDjhYL6W4GoaylSiZBjWmUXz X-Received: by 2002:aca:f507:: with SMTP id t7mr6870083oih.156.1580313118737; Wed, 29 Jan 2020 07:51:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580313118; cv=none; d=google.com; s=arc-20160816; b=UHISV4yqeWMAO6zGwemiGgnmb8Ce27tT9NshGtjTczPd8bGiLACst0GMgBrJMH4qtN +rQnMNbSHobdPDocdxc1y4W6GB+AueChdbGKfoG050UPh30aFkeUNNBzZXCGSPXZvi2c h072q9bRRzrqU/Hh3nFZ1JPqtaJl0T7VruYEZILGixvpy3oTP9GhX7TSSm/LnCfkiNvf So+CdPCNNuAJk2jY3rDtCoIG7BLbGXNkM0uGFJus3e8/yJIPgGOU3ntThJ6GTHlUpMpU GRHr1ifjxrmYxuzuAti2My0nHELWXSTKdD7lGTtVvKD9wBLvFWt7Pp742bkT/KW0yLl5 Wsrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=fHjrFIlDfzba+ZttAUDX0qz7e+Mgb7If81blkhKuWt4=; b=wSBBfPGV3Kuyn5g9K2+1eetgCW/aF4GsreOVQvDrzxhB5pcJqEu4bXK5Ds6eW0pDP3 zUSzbxvfhRnfF2a6AQC4uRCOflPwgOXRVLUYkHF4Lyb2B9UxFRUBHs7UzAe9BSNsNQtx mnBQWNvcHZ5pN0fdduW6fhJPdqYS+r3PcAg1PUnFR7jEH6wx4gh/5YuWoRZxpeFUq66F gs3mckTDr1cn3BWQW5TyltBx5WzAshMtGDUwq+5kZe0u2FB3piThnzR8flyh8sIUsXJA isAY3hCR1gUebXhCSpF/B3kfOPnLf9tgA8pcroApKo8lSpzZaIsQNcputE9hrBsF9xKE 5dVA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i6si1310107otp.5.2020.01.29.07.51.46; Wed, 29 Jan 2020 07:51:58 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726760AbgA2PlM (ORCPT + 99 others); Wed, 29 Jan 2020 10:41:12 -0500 Received: from foss.arm.com ([217.140.110.172]:42814 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726240AbgA2PlM (ORCPT ); Wed, 29 Jan 2020 10:41:12 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2D28931B; Wed, 29 Jan 2020 07:41:12 -0800 (PST) Received: from [192.168.0.7] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 41D623F52E; Wed, 29 Jan 2020 07:41:10 -0800 (PST) Subject: Re: [Patch v8 4/7] sched/fair: Enable periodic update of average thermal pressure To: Vincent Guittot Cc: Peter Zijlstra , Thara Gopinath , Ingo Molnar , Ionela Voinescu , Zhang Rui , Quentin Perret , Daniel Lezcano , viresh kumar , linux-kernel , Amit Kachhap , Javi Merino , Amit Kucheria References: <1579031859-18692-1-git-send-email-thara.gopinath@linaro.org> <1579031859-18692-5-git-send-email-thara.gopinath@linaro.org> <20200116151502.GQ2827@hirez.programming.kicks-ass.net> <20200117145544.GE14879@hirez.programming.kicks-ass.net> From: Dietmar Eggemann Message-ID: Date: Wed, 29 Jan 2020 16:41:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 27/01/2020 16:15, Vincent Guittot wrote: > On Mon, 27 Jan 2020 at 13:09, Dietmar Eggemann wrote: >> >> On 24/01/2020 16:45, Vincent Guittot wrote: >>> On Fri, 24 Jan 2020 at 16:37, Dietmar Eggemann wrote: >>>> >>>> On 17/01/2020 16:39, Vincent Guittot wrote: >>>>> On Fri, 17 Jan 2020 at 15:55, Peter Zijlstra wrote: >>>>>> >>>>>> On Fri, Jan 17, 2020 at 02:22:51PM +0100, Vincent Guittot wrote: >>>>>>> On Thu, 16 Jan 2020 at 16:15, Peter Zijlstra wrote: >> >> [...] >> >>>> The 'now' argument is one thing but why not: >>>> >>>> -int update_thermal_load_avg(u64 now, struct rq *rq, u64 capacity) >>>> +int update_thermal_load_avg(u64 now, struct rq *rq) >>>> { >>>> + u64 capacity = arch_cpu_thermal_pressure(cpu_of(rq)); >>>> + >>>> if (___update_load_sum(now, &rq->avg_thermal, >>>> >>>> This would make the call-sites __update_blocked_others() and >>>> task_tick(_fair)() cleaner. >>> >>> I prefer to keep the capacity as argument. This is more aligned with >>> others that provides the value of the signal to apply >>> >>>> >>>> I guess the argument is not to pollute pelt.c. But it already contains >>> >>> you've got it. I don't want to pollute the pelt.c file with things not >>> related to pelt but thermal as an example. >>> >>>> arch_scale_[freq|cpu]_capacity() for irq. >> >> But isn't arch_cpu_thermal_pressure() not exactly the same as >> arch_scale_cpu_capacity() and arch_scale_freq_capacity()? >> >> All of them are defined by default within the scheduler code >> [include/linux/sched/topology.h or kernel/sched/sched.h] and can be >> overwritten by arch code with a fast implementation (e.g. returning a >> per-cpu variable). >> >> So why is using arch_scale_freq_capacity() and arch_scale_cpu_capacity() >> in update_irq_load_avg [kernel/sched/pelt.c] and update_rq_clock_pelt() > > As explained previously, update_irq_load_avg is an exception and not > the example to follow. update_rt/dl_rq_load_avg are the example to > follow and fixing update_irq_load_avg exception is on my todo list There is already a v9 but I comment here so the thread stays intact. I guess this thread leads to nowhere. For me the question is do we review against existing code or some possible future changes? The arguments didn't convince me so far. But we're not talking functional issues here so I won't continue to push for change on this one here. >> [kernel/sched/pelt.h] OK but arch_cpu_thermal_pressure() in >> update_thermal_load_avg() [kernel/sched/pelt.c] not? >> >> Shouldn't arch_cpu_thermal_pressure() not be called >> arch_scale_thermal_capacity() to highlight the fact that those three > > Quoted from cover letter https://lkml.org/lkml/2020/1/14/1164: > " > v6->v7: > - ... > - Renamed arch_scale_thermal_capacity to arch_cpu_thermal_pressure > as per review comments from Peter, Dietmar and Ionela. > -... > > " I went back to the v6 review. Peter originally asked for a better name (or an additional comment) for arch_scale_thermal_capacity() because the return value is not capacity. So IMHO arch_scale_thermal_pressure() is a good name for keeping this aligned w/ the other arch_scale_* functions and to address this review comment. arch_scale_cpu_capacity() - scale capacity by cpu arch_scale_freq_capacity() - scale capacity by frequency arch_scale_thermal_pressure() - scale pressure (1 - capacity) by thermal [...]