Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp953403ybx; Fri, 1 Nov 2019 14:05:55 -0700 (PDT) X-Google-Smtp-Source: APXvYqxuRp1PJqFe34BUVyuFpju2OlpkmrNXCBqzb1VhF0e1ckvWRgnsu8OsEW+7NGZecKwVoM6g X-Received: by 2002:aa7:d552:: with SMTP id u18mr15234760edr.86.1572642355025; Fri, 01 Nov 2019 14:05:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572642355; cv=none; d=google.com; s=arc-20160816; b=jQ9jubbwBinZ37b0WLLjQctMSXnKF261nMTXebWtLZIDs1/XRLpDiwi3KhQ+bEe7y/ c6lYu79Cmcb8DEs0rrTd92HFFkkdc5dQSQ7Rov+gdVkhRiKZ9iBJcsVFlQ7baqJfEn6Q 4NPmKtTTf2mn9bkH2ivePFW23j5X/qqT11QIjgPKCN+ggo+tBRZ2jvfSwtOz8MGmV0JV Tbvjmd5H3gRwNz31j6epuWuXPbKD1Zk0V6ftXCxG4oMvUWiLjnywb1srM5AyARMlxQPl vgQGYbfz8XbkRii7Rm6doQ9Nbzb+8Tg1oWyfuGyoPDX7P7Do/SgMKykuB3ZGukWtOnH7 Rqyw== 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:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:dkim-signature; bh=rU5awjd7OsKi+MjPz5zkPNthALUjS34IGcuRf1byb3I=; b=NTofN0oowedohRyyrci+HJzeDL9xkt3U2HMf9RRv1Lx6/31U0XdRn9VFie2w3HfBys XuoTZNT9mnWOIzmh0jqpjHnzxxmtGZUS9rfjXlYNhQvvrU+zl8W26g3xBUWzT6KCA991 7gb2Vx9yDPf0+MDW1fuZHs4CCfbV4aLhTpafrXZiWlSoE3GRS3kHJ6vhxauPEctyvbub 1U4DRN0/YI5IClJnr9mJt8AIITWzfY/aoIULyzza6IjTaNjkCjntYf8+kASQ2CKbYJBp 4ZaZcWpP8lLHnmG5eItg3UFgKA7e/bqE6kx4v3EcswFacyPvDXnvupK+HhNsPQ0lWprP o85w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=MYCBpQ1y; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z3si6287818ejb.42.2019.11.01.14.05.30; Fri, 01 Nov 2019 14:05:55 -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; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=MYCBpQ1y; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726623AbfKAVEv (ORCPT + 99 others); Fri, 1 Nov 2019 17:04:51 -0400 Received: from mail-qt1-f194.google.com ([209.85.160.194]:45601 "EHLO mail-qt1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726229AbfKAVEu (ORCPT ); Fri, 1 Nov 2019 17:04:50 -0400 Received: by mail-qt1-f194.google.com with SMTP id x21so14697007qto.12 for ; Fri, 01 Nov 2019 14:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=rU5awjd7OsKi+MjPz5zkPNthALUjS34IGcuRf1byb3I=; b=MYCBpQ1yJWfqeAl1zazCgHUNVBCXOVbAupu9Tw5PyPCacB7oBlTchC+5QEcSDSlppj xU1s2TD9NiUvV0wRfn8w5/y8ORls+UnEa6UFaTeaYv5PxNRJGCBu0+zRHLTAB2Ki21kd F/CtsFIi+9D8qtT2ulNspJyKgFjpWUg7SF84r7Rm64mNPsNjUiCE0tY/DBjRsbaK5XOa qcxyoS0SN4+e6QCbAMpMhNXbhj88EYc9nE31tM4wQZ1DIdXJDAppjsd8z7eqmnHo9o5L pKxEZyvxuLSpd26KccAHKSd1dH3j68JElsuenkCbt+ZQuOj7o5G7MgwpJTRHIlIv1xJY kHYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=rU5awjd7OsKi+MjPz5zkPNthALUjS34IGcuRf1byb3I=; b=ERucYt7bCEHLcg/Dtj51PtBdFycP++uimixaNgbYS1u9sFd1dM7Mzh306ThRtaYX6t LHOfWXl06sM9WuvrAAboCDfiS7Fo+L9GU3ENGmK+9fXPtz47GVe+ieKrSqT2UfRJwDGx K7hGNzfDSRaHXNy7WfzPSNR8YlyRSrfceQea+233AsFcAGI3nbQ12tmpWs4V+jeTchE+ lEdIu/Zerm4Ygsg5X0J5v/vSfn+KQ85HApV4fQUcY87L/ByZMV5j3muT+KY1ZWMe6eOr m7L4Wo25Iif/nyNAyBM0nV1KOAXr9JKMuYeNVcndCPpxz0RO4eKVGNOeBuvRVpcvGlaT yDeQ== X-Gm-Message-State: APjAAAU2xheg9cOwqvHl/0VTpx+bh8z6V6lQRRwcd93Va6W4h8DLJdCX VIqOrwLU7oPZC+wuJX+MFvOnrQ== X-Received: by 2002:aed:2ec6:: with SMTP id k64mr1475272qtd.61.1572642289403; Fri, 01 Nov 2019 14:04:49 -0700 (PDT) Received: from [192.168.1.169] (pool-71-255-246-27.washdc.fios.verizon.net. [71.255.246.27]) by smtp.gmail.com with ESMTPSA id c17sm4165329qkm.37.2019.11.01.14.04.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Nov 2019 14:04:48 -0700 (PDT) Subject: Re: [Patch v4 5/6] thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping To: Ionela Voinescu , Vincent Guittot References: <1571776465-29763-1-git-send-email-thara.gopinath@linaro.org> <1571776465-29763-6-git-send-email-thara.gopinath@linaro.org> <2b19d7da-412c-932f-7251-110eadbef3e3@arm.com> <20191101154612.GA4884@e108754-lin> Cc: Dietmar Eggemann , Ingo Molnar , Peter Zijlstra , Zhang Rui , Eduardo Valentin , Quentin Perret , linux-kernel , Amit Kachhap , Javi Merino , Daniel Lezcano From: Thara Gopinath Message-ID: <5DBC9DEF.6030007@linaro.org> Date: Fri, 1 Nov 2019 17:04:47 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20191101154612.GA4884@e108754-lin> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/01/2019 11:47 AM, Ionela Voinescu wrote: > Hi guys, > > On Thursday 31 Oct 2019 at 17:38:25 (+0100), Vincent Guittot wrote: >> On Thu, 31 Oct 2019 at 17:29, Dietmar Eggemann wrote: >>> >>> On 22.10.19 22:34, Thara Gopinath wrote: >>>> Thermal governors can request for a cpu's maximum supported frequency >>>> to be capped in case of an overheat event. This in turn means that the >>>> maximum capacity available for tasks to run on the particular cpu is >>>> reduced. Delta between the original maximum capacity and capped >>>> maximum capacity is known as thermal pressure. Enable cpufreq cooling >>>> device to update the thermal pressure in event of a capped >>>> maximum frequency. >>>> >>>> Signed-off-by: Thara Gopinath >>>> --- >>>> drivers/thermal/cpu_cooling.c | 31 +++++++++++++++++++++++++++++-- >>>> 1 file changed, 29 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c >>>> index 391f397..2e6a979 100644 >>>> --- a/drivers/thermal/cpu_cooling.c >>>> +++ b/drivers/thermal/cpu_cooling.c >>>> @@ -218,6 +218,23 @@ static u32 cpu_power_to_freq(struct cpufreq_cooling_device *cpufreq_cdev, >>>> } >>>> >>>> /** >>>> + * update_sched_max_capacity - update scheduler about change in cpu >>>> + * max frequency. >>>> + * @policy - cpufreq policy whose max frequency is capped. >>>> + */ >>>> +static void update_sched_max_capacity(struct cpumask *cpus, >>>> + unsigned int cur_max_freq, >>>> + unsigned int max_freq) >>>> +{ >>>> + int cpu; >>>> + unsigned long capacity = (cur_max_freq << SCHED_CAPACITY_SHIFT) / >>>> + max_freq; >>>> + >>>> + for_each_cpu(cpu, cpus) >>>> + update_thermal_pressure(cpu, capacity); >>>> +} >>>> + >>>> +/** >>>> * get_load() - get load for a cpu since last updated >>>> * @cpufreq_cdev: &struct cpufreq_cooling_device for this cpu >>>> * @cpu: cpu number >>>> @@ -320,6 +337,7 @@ static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev, >>>> unsigned long state) >>>> { >>>> struct cpufreq_cooling_device *cpufreq_cdev = cdev->devdata; >>>> + int ret; >>>> >>>> /* Request state should be less than max_level */ >>>> if (WARN_ON(state > cpufreq_cdev->max_level)) >>>> @@ -331,8 +349,17 @@ static int cpufreq_set_cur_state(struct thermal_cooling_device *cdev, >>>> >>>> cpufreq_cdev->cpufreq_state = state; >>>> >>>> - return dev_pm_qos_update_request(&cpufreq_cdev->qos_req, >>>> - cpufreq_cdev->freq_table[state].frequency); >>>> + ret = dev_pm_qos_update_request >>>> + (&cpufreq_cdev->qos_req, >>>> + cpufreq_cdev->freq_table[state].frequency); >>>> + >>>> + if (ret > 0) >>>> + update_sched_max_capacity >>>> + (cpufreq_cdev->policy->cpus, >>>> + cpufreq_cdev->freq_table[state].frequency, >>>> + cpufreq_cdev->policy->cpuinfo.max_freq); >>>> + >>>> + return ret; >>>> } >>>> >>>> /** >>>> >>> >>> Why not getting rid of update_sched_max_capacity() entirely and call >>> update_thermal_pressure() in cpu_cooling.c directly? Saves one level in >>> the call chain and would mean less code for this feature. >> >> But you add complexity in update_thermal_pressure which now has to >> deal with a cpumask and to compute some frequency ratio >> IMHO, it's cleaner to keep update_thermal_pressure simple as it is now >> > > How about removing update_thermal_pressure altogether and doing all the > work in update_sched_max_capacity? That is, have > update_sched_max_capacity compute the capped_freq_ratio, do the > normalization, and set it per_cpu for all CPUs in the frequency domain. > You'll save some calculations that you're now doing in > update_thermal_pressure for each cpu and you avoid shifting back and > forth. Yes. I can pass the delta to update_thermal_pressure. I will still want to keep update_thermal_pressure and a per cpu variable in fair.c to store this. > > If you're doing so it would be worth renaming update_sched_max_capacity > to something like update_sched_thermal_pressure. Will do. -- Warm Regards Thara