Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp375413yba; Thu, 18 Apr 2019 02:50:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqxUpWJjjoKfUa3I97LsEzVW1TgqeRhbbFFFlGDHtNJlgm6RXSrIjUvypkiGVgZEOi7GZUgl X-Received: by 2002:a17:902:7c8a:: with SMTP id y10mr5173737pll.337.1555581008844; Thu, 18 Apr 2019 02:50:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555581008; cv=none; d=google.com; s=arc-20160816; b=VHvEwkEhnzj5TqDKotKMCoqrfHGBOTqd9bWAZ8Lu3xgZ965SMVFt5Pt2gedKcSh+av KJFFX6XWbE4Ms6x9SzhmS0C8D3sISQDgY6DZOBTUODGSpxt9wx1m5syWTs7p90/v6+Xy dXIzP8ZYHmnV5pQZHJAp2tBA7cbrpDf7Tc+iIGFie740TqlfwxL8/II0f0IvhG97MZ6j JcmZdg8uzNy3bHDjXDTMVPtmrdETJBHOGJ9Vi61RAIhoavtDDfUzUHIO0dquQKvsgTlP RhwrdOcRFm/mcQTn7Fpm00Zdv4CMhxND4D2rSGys+T9xoqfRehcWJGeYP6bd8W2XoULV eVDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=rhEp7dgHZ4AuL//vM7LG6tdR/0EV4DjFOAPhUEOr128=; b=IuBZsBbjtf3kyELpAvpveaLj2lPnFGkFvFvZS6NChp6YCrTi6A9HUXLv08PYICmbBy Wm45JOBXHi5PJIkncj1vD9Cfwa5xSjm8rXTTpDm1KnDhaWZOhqLzR5RBJpBL7ljvuORN ERlRg1lDjm7nw5NKmLsK3wVTa8g0ha9QBZXyvUwwiuoVOhDP6NLWHA/4u8ncLQux2hs7 0n6zHHU9C+WsNLPdXb7hK6JpqhdJe0xO+M5x/GBqPdvgRBgZ0Y8uJIZxHkHKHbZWg3my Eh9Q9BtrkBttJtKU0LnZxOPaHI/r5gKEoBQlMNA8oG2uzPgcl//Izcmc3p6gkcOinTEK N9aQ== 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 u5si1573214pgl.36.2019.04.18.02.49.53; Thu, 18 Apr 2019 02:50:08 -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; 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 S2388434AbfDRJsl (ORCPT + 99 others); Thu, 18 Apr 2019 05:48:41 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:58590 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733049AbfDRJsk (ORCPT ); Thu, 18 Apr 2019 05:48:40 -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 F237515AB; Thu, 18 Apr 2019 02:48:39 -0700 (PDT) Received: from queper01-lin (queper01-lin.cambridge.arm.com [10.1.195.48]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 862993F68F; Thu, 18 Apr 2019 02:48:37 -0700 (PDT) Date: Thu, 18 Apr 2019 10:48:35 +0100 From: Quentin Perret To: Thara Gopinath Cc: mingo@redhat.com, peterz@infradead.org, rui.zhang@intel.com, linux-kernel@vger.kernel.org, amit.kachhap@gmail.com, viresh.kumar@linaro.org, javi.merino@kernel.org, edubezval@gmail.com, daniel.lezcano@linaro.org, vincent.guittot@linaro.org, nicolas.dechesne@linaro.org, bjorn.andersson@linaro.org, dietmar.eggemann@arm.com Subject: Re: [PATCH V3 3/3] thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping Message-ID: <20190418094833.owlobrx6x5gclvhy@queper01-lin> References: <1555443521-579-1-git-send-email-thara.gopinath@linaro.org> <1555443521-579-4-git-send-email-thara.gopinath@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1555443521-579-4-git-send-email-thara.gopinath@linaro.org> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 16 Apr 2019 at 15:38:41 (-0400), Thara Gopinath wrote: > diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c > @@ -177,6 +178,9 @@ static int cpufreq_thermal_notifier(struct notifier_block *nb, > > if (policy->max > clipped_freq) > cpufreq_verify_within_limits(policy, 0, clipped_freq); > + > + sched_update_thermal_pressure(policy->cpus, > + policy->max, policy->cpuinfo.max_freq); Is this something we could do this CPUFreq ? Directly in cpufreq_verify_within_limits() perhaps ? That would re-define the 'thermal pressure' framework in a more abstract way and make the scheduler look at 'frequency capping' events, regardless of the reason for capping. That would reflect user-defined frequency constraint into cpu_capacity, in addition to the thermal stuff. I'm not sure if there is another use case for frequency capping ? Perhaps the Intel boost stuff could be factored in there ? That is, at times when the boost freq is not reachable capacity_of() would appear smaller ... Unless this wants to be reflected instantaneously ? Thoughts ? Quentin