Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp718365ybx; Thu, 7 Nov 2019 01:33:48 -0800 (PST) X-Google-Smtp-Source: APXvYqyrO8/+GFGlp2yjhRUA21F/L7ggLm4+1tkGRtm7CiAQjLamZh/NM5M5MT3mEwroWckIgBCO X-Received: by 2002:a50:aad2:: with SMTP id r18mr2485180edc.44.1573119228322; Thu, 07 Nov 2019 01:33:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573119228; cv=none; d=google.com; s=arc-20160816; b=EI+57u6Upqh7IWWWMq+StVTZaugMzrf9Dr1rW/WJepoc32NqbC+rGwGI3fzOUzF2UB dGL4McjA/M8V6N5LD1pMHa1e49aAw5oLrMReTEKHP63++YnR8pe6nFlTp9WVRtzGeWNz FEMCrO3gCdPDV3d+U35nI88qu3Mz7WVThptSG212dLBX6YdicMVxLDA8+hkOSRReG8XS 3Ta8iadbnpVK3RQn+SaliBWwBOR22Yd5k0i2hRjNFq+vRdUBSTI0peINCel/3zHAqU4T cIZkwcbIK1vRnLysIjIRZD2/WD7ppx26cGqIelAoWmDRXTwIe2uPqaA98q24SBIOmKFl AbpA== 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=TJ+Q//c08uWPUGykEwCsLYEaIyZv0tpm3tni7KkpFhs=; b=TDUDyDaQDx3g8JMGDGDWMr4+yk0e/GRXUcVE2P50KW2X0vR7R/MHrP+3P57jZMCY6f xO73BsFsyGxlkUWVzFCi5Wzsz4Mb7tU7SYwmVm7g8/udnx6ZJ4vNPoLJWUH/b5+eJcwF g/RuLVNRk/MXLYgB5TdH35eli6eQsiKkJ8IFIlf78O57AWRHHJdqi2HHg5OYuaa00U/O 4CK5C62empwuG8ftsJsk3ME/ylbUI3AOffX8i+uRhvyoKYWNrKMID29iwd+jjHmS5pzN gJXufIIeAYTJqeepA7mrTPWcZwiltOjIKVuMlv9f0IPP3PQ/t/5QjBb6VZPu2dMWiuej 5xwg== 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 m16si1128875ejd.306.2019.11.07.01.33.25; Thu, 07 Nov 2019 01:33:48 -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 S1727926AbfKGJcg (ORCPT + 99 others); Thu, 7 Nov 2019 04:32:36 -0500 Received: from foss.arm.com ([217.140.110.172]:52634 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727278AbfKGJcf (ORCPT ); Thu, 7 Nov 2019 04:32:35 -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 CEC6F46A; Thu, 7 Nov 2019 01:32:34 -0800 (PST) Received: from [192.168.0.9] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0CBDE3F71A; Thu, 7 Nov 2019 01:32:32 -0800 (PST) Subject: Re: [Patch v5 2/6] sched/fair: Add infrastructure to store and update instantaneous thermal pressure To: Thara Gopinath , Ionela Voinescu Cc: mingo@redhat.com, peterz@infradead.org, vincent.guittot@linaro.org, rui.zhang@intel.com, edubezval@gmail.com, qperret@google.com, linux-kernel@vger.kernel.org, amit.kachhap@gmail.com, javi.merino@kernel.org, daniel.lezcano@linaro.org References: <1572979786-20361-1-git-send-email-thara.gopinath@linaro.org> <1572979786-20361-3-git-send-email-thara.gopinath@linaro.org> <20191105202037.GA17494@e108754-lin> <5DC1E348.2090104@linaro.org> <20191105211446.GA25349@e108754-lin> <5DC1E9BC.1010001@linaro.org> <20191105215233.GA6450@e108754-lin> <436ad772-c727-127e-1469-d99549db03fc@arm.com> <5DC3088B.8070401@linaro.org> From: Dietmar Eggemann Message-ID: <943a8368-1f19-d981-7583-0db4e32895af@arm.com> Date: Thu, 7 Nov 2019 10:32:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <5DC3088B.8070401@linaro.org> 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 06/11/2019 18:53, Thara Gopinath wrote: > On 11/06/2019 07:50 AM, Dietmar Eggemann wrote: >> On 05/11/2019 22:53, Ionela Voinescu wrote: >>> On Tuesday 05 Nov 2019 at 16:29:32 (-0500), Thara Gopinath wrote: >>>> On 11/05/2019 04:15 PM, Ionela Voinescu wrote: >>>>> On Tuesday 05 Nov 2019 at 16:02:00 (-0500), Thara Gopinath wrote: >>>>>> On 11/05/2019 03:21 PM, Ionela Voinescu wrote: >>>>>>> Hi Thara, >>>>>>> >>>>>>> On Tuesday 05 Nov 2019 at 13:49:42 (-0500), Thara Gopinath wrote: >>>>>>> [...] >>>>>>>> +static void trigger_thermal_pressure_average(struct rq *rq) >>>>>>>> +{ >>>>>>>> +#ifdef CONFIG_SMP >>>>>>>> + update_thermal_load_avg(rq_clock_task(rq), rq, >>>>>>>> + per_cpu(thermal_pressure, cpu_of(rq))); >>>>>>>> +#endif >>>>>>>> +} >>>>>>> >>>>>>> Why did you decide to keep trigger_thermal_pressure_average and not >>>>>>> call update_thermal_load_avg directly? >>>>>>> >>>>>>> For !CONFIG_SMP you already have an update_thermal_load_avg function >>>>>>> that does nothing, in kernel/sched/pelt.h, so you don't need that >>>>>>> ifdef. >>>>>> Hi, >>>>>> >>>>>> Yes you are right. But later with the shift option added, I shift >>>>>> rq_clock_task(rq) by the shift. I thought it is better to contain it in >>>>>> a function that replicate it in three different places. I can remove the >>>>>> CONFIG_SMP in the next version. >>>>> >>>>> You could still keep that in one place if you shift the now argument of >>>>> ___update_load_sum instead. >>>> >>>> No. I cannot do this. The authors of the pelt framework prefers not to >>>> include a shift parameter there. I had discussed this with Vincent earlier. >>>> >>> >>> Right! I missed Vincent's last comment on this in v4. >>> >>> I would argue that it's more of a PELT parameter than a CFS parameter >>> :), where it's currently being used. I would also argue that's more of a >>> PELT parameter than a thermal parameter. It controls the PELT time >>> progression for the thermal signal, but it seems more to configure the >>> PELT algorithm, rather than directly characterize thermals. >>> >>> In any case, it only seemed to me that adding a wrapper function for >>> this purpose only was not worth doing. >> >> Coming back to the v4 discussion >> https://lore.kernel.org/r/379d23e5-79a5-9d90-0fb6-125d9be85e99@arm.com >> >> There is no API between pelt.c and other parts of the scheduler/kernel >> so why should we keep an unnecessary parameter and wrapper functions? >> >> There is also no abstraction, update_thermal_load_avg() in pelt.c even >> carries '_thermal_' in its name. >> >> So why not define this shift value '[sched_|pelt_]thermal_decay_shift' >> there as well? It belongs to update_thermal_load_avg(). >> >> All call sites of update_thermal_load_avg() use 'rq_clock_task(rq) >> >> sched_thermal_decay_shift' so I don't see the need to pass it in. >> >> IMHO, preparing for eventual code changes (e.g. parsing different now >> values) is not a good practice in the kernel. Keeping the code small and >> tidy is. > > I think we are going in circles on this one. I acknowledge you have an > issue. That being said, I also understand the need to keep the pelt > framework code tight. Also Ionela pointed out that there could be a need > for a faster decay in which case it could mean a left shift leading to > further complications if defined in pelt.c (I am not saying that I will > implement a faster decay in this patch set but it is more of a future > extension if needed!) The issue still exists so why not discussing it here? Placing thermal related time shift operations in a update_*thermal*_load_avg() PELT function look perfectly fine to me. > I can make trigger_thermal_pressure_average inline if that will > alleviate some of the concerns. That's not the issue here. The issue is the extra shim layer which is unnecessary in the current implementation. update_blocked_averages() { ... update_rt_rq_load_avg() update_dl_rq_load_avg() update_irq_load_avg() trigger_thermal_pressure_average() <--- ? ... } Wouldn't a direct call to update_thermal_load_avg() here make things so much more clear? And I'm not talking about today and about people involved in this review. > I would also urge you to reconsider the merits of arguing this point > back and forth. I just did. [...]