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=-5.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 E3A48C2D0A3 for ; Fri, 6 Nov 2020 11:14:57 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 69F6F206C1 for ; Fri, 6 Nov 2020 11:14:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="TE/eaD9U" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 69F6F206C1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=hcxK9ZYTHtp2KH/RIkWF7njHa4XYTDeD8bi0Z2MFQq4=; b=TE/eaD9UgT5VS/HI0fYOu0WzE 1MQJfM1NxiDrZ1Ss3b4uuKJW6BePdEfNtrN8ukZe/ir2Ht3kYpV/TrsMkS4KBBVP/Qi0ruccFWk7v CpH7ITRB1gTcf9l1X1jXy3C/nXG3UQ4w7UWT6oXGlSRYcPxbrtc9+cXUf61ntsQFugz+HGecRa9BV bJlYm3hkEtLgy+FLSuzsvSroL4Y9nsV64hVO6U5nQXXOCJHc3OhrQXiip14AyUwYUn0/92xlSabpf etNADAq1oy22y4zywiT6eKh0MHZvZYo6PnMDOJ+IL/nF2bOVsTD4QDg4mCoHWsq7gmatuO/na5/rp bswoVw6Eg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kazhP-0000ti-FC; Fri, 06 Nov 2020 11:14:31 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kazhM-0000t8-Md for linux-arm-kernel@lists.infradead.org; Fri, 06 Nov 2020 11:14:29 +0000 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 A3D84147A; Fri, 6 Nov 2020 03:14:26 -0800 (PST) Received: from [10.57.14.85] (unknown [10.57.14.85]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 745553F719; Fri, 6 Nov 2020 03:14:23 -0800 (PST) Subject: Re: [PATCH v3 3/3] [RFC] CPUFreq: Add support for cpu-perf-dependencies To: Viresh Kumar References: <20201102120115.29993-1-nicola.mazzucato@arm.com> <20201102120115.29993-4-nicola.mazzucato@arm.com> <20201106092020.za3oxg7gutzc3y2b@vireshk-i7> <0a334a73-45ef-58ff-7dfd-9df6f4ff290a@arm.com> <20201106105514.bhtdklyhn7goml64@vireshk-i7> From: Lukasz Luba Message-ID: <7f73bcd6-0f06-4ef0-7f02-0751e6c4d94b@arm.com> Date: Fri, 6 Nov 2020 11:14:21 +0000 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: <20201106105514.bhtdklyhn7goml64@vireshk-i7> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201106_061428_827741_967C90C0 X-CRM114-Status: GOOD ( 24.70 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: nm@ti.com, devicetree@vger.kernel.org, linux-pm@vger.kernel.org, sboyd@kernel.org, vireshk@kernel.org, daniel.lezcano@linaro.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, robh+dt@kernel.org, Nicola Mazzucato , sudeep.holla@arm.com, chris.redpath@arm.com, morten.rasmussen@arm.com, linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 11/6/20 10:55 AM, Viresh Kumar wrote: > On 06-11-20, 10:37, Lukasz Luba wrote: >> Good question. >> >> How about a different interface for those cpufreq drivers? >> That new registration API would allow to specify the cpumask. >> Or rely on EM cpumask: em_span_cpus(em) >> >> Currently we have two ways to register cooling device: >> 1. when the cpufreq driver set a flag CPUFREQ_IS_COOLING_DEV, the core >> will register cooling device >> 2. cpufreq driver can explicitly call the registration function: >> cpufreq_cooling_register() with 'policy' as argument >> >> That would need substantial change to the cpufreq cooling code, from >> policy oriented to custom driver's cpumask (like EM registration). > > I am even wondering if we should really make that change. Why do we > need the combined load of the CPUs to be sent back to the IPA governor > ? Why shouldn't they all do that (they == cdev) ? > > This is a bit confusing to me, sorry about that. The cpufreq governors > take a look at all the CPUs utilization and set the frequency based on > the highest utilization (and not the total util). > > While in this case we present the total load of the CPUs to the IPA > (based on the current frequency of the CPUs), in response to which it > tells us the frequency at which all the CPUs of the policy can run at > (I am not even sure if it is the right thing to do as the CPUs have > different loads). And how do we fit this dependent_cpus thing into > this. > > Sorry, I am not sure what's the right way of doing thing here. > I also had similar doubts, because if we make frequency requests independently for each CPU, why not having N cooling devs, which will set independently QoS max freq for them... What convinced me: EAS and FIE would know the 'real' frequency of the cluster, IPA can use it also and have only one cooling device per cluster. We would like to keep this old style 'one cooling device per cpuset'. I don't have strong opinion and if it would appear that there are some errors in freq estimation for cluster, then maybe it does make more sense to have cdev per CPU... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel