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.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, 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 48B21C433E7 for ; Thu, 8 Oct 2020 17:09:50 +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 DAAD6221F1 for ; Thu, 8 Oct 2020 17:09:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Smfrxi42" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DAAD6221F1 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-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=6Modg1q/5h3x3vtu7A82TrbUhBBqPL6IHrQ6K+0oySw=; b=Smfrxi42LUmr7lQBFNh5uuWY7 Q4U3xU00Elp9vELHlTAT3Bj2diamS0CUSFiP9dKTp2Jm2DthqVRtQWId+cnzwwoHPIrNpxsM5lo/v r4R+gFIXNmi665ySTgwQbHq0xwpswmHei5/TYGKzzxTMoslM9KcGtycBEn3vxGYyT+Ar3rysFCiqn VpG4GqSF1xH2v9PHX7+IeaWSEBrMNPJgcwSF7aiqkp4cIC3sfOEo0n2Yc91cm82hRI87hmQSgzHM2 7x7wTamyxsrIaSB+q9Nyx1PS07I6P46cW37FMVBSGhJpjWa7I7yI0jazWso4IU0qVomAdTScxKEYL kZV2I69Iw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQZOu-0007ey-DF; Thu, 08 Oct 2020 17:08:20 +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 1kQZOs-0007eH-Kn for linux-arm-kernel@lists.infradead.org; Thu, 08 Oct 2020 17:08:19 +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 26CD2D6E; Thu, 8 Oct 2020 10:08:17 -0700 (PDT) Received: from localhost (unknown [10.1.199.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BBC693F802; Thu, 8 Oct 2020 10:08:16 -0700 (PDT) Date: Thu, 8 Oct 2020 18:08:15 +0100 From: Ionela Voinescu To: "Rafael J. Wysocki" Subject: Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies Message-ID: <20201008170815.GB29728@arm.com> References: <20200924095347.32148-1-nicola.mazzucato@arm.com> <20200924095347.32148-3-nicola.mazzucato@arm.com> <20201006071909.3cgz7i5v35dgnuzn@vireshk-i7> <2417d7b5-bc58-fa30-192c-e5991ec22ce0@arm.com> <20201008110241.dcyxdtqqj7slwmnc@vireshk-i7> <20201008150317.GB20268@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201008_130818_770293_0EF28F63 X-CRM114-Status: GOOD ( 34.73 ) 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: "devicetree@vger.kernel.org" , Sudeep Holla , Linux PM , Viresh Kumar , Daniel Lezcano , "Rafael J. Wysocki" , Linux Kernel Mailing List , Rob Herring , Nicola Mazzucato , Viresh Kumar , Chris Redpath , Morten Rasmussen , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Rafael, On Thursday 08 Oct 2020 at 17:57:23 (+0200), Rafael J. Wysocki wrote: > On Thu, Oct 8, 2020 at 5:03 PM Ionela Voinescu wrote: > > > > Hi Viresh, > > > > On Thursday 08 Oct 2020 at 16:32:41 (+0530), Viresh Kumar wrote: > > > On 07-10-20, 13:58, Nicola Mazzucato wrote: > > > > Hi Viresh, > > > > > > > > performance controls is what is exposed by the firmware through a protocol that > > > > is not capable of describing hardware (say SCMI). For example, the firmware can > > > > tell that the platform has N controls, but it can't say to which hardware they > > > > are "wired" to. This is done in dt, where, for example, we map these controls > > > > to cpus, gpus, etc. > > > > > > > > Let's focus on cpus. > > > > > > > > Normally we would have N of performance controls (what comes from f/w) > > > > that that correspond to hardware clock/dvfs domains. > > > > > > > > However, some firmware implementations might benefit from having finer > > > > grained information about the performance requirements (e.g. > > > > per-CPU) and therefore choose to present M performance controls to the > > > > OS. DT would be adjusted accordingly to "wire" these controls to cpus > > > > or set of cpus. > > > > In this scenario, the f/w will make aggregation decisions based on the > > > > requests it receives on these M controls. > > > > > > > > Here we would have M cpufreq policies which do not necessarily reflect the > > > > underlying clock domains, thus some s/w components will underperform > > > > (EAS and thermal, for example). > > > > > > > > A real example would be a platform in which the firmware describes the system > > > > having M per-cpu control, and the cpufreq subsystem will have M policies while > > > > in fact these cpus are "performance-dependent" each other (e.g. are in the same > > > > clock domain). > > > > > > If the CPUs are in the same clock domain, they must be part of the > > > same cpufreq policy. > > > > But cpufreq does not currently support HW_ALL (I'm using the ACPI > > coordination type to describe the generic scenario of using hardware > > aggregation and coordination when establishing the clock rate of CPUs). > > > > Adding support for HW_ALL* will involve either bypassing some > > assumptions around cpufreq policies or making core cpufreq changes. > > > > In the way I see it, support for HW_ALL involves either: > > > > - (a) Creating per-cpu policies in order to allow each of the CPUs to > > send their own frequency request to the hardware which will do > > aggregation and clock rate decision at the level of the clock > > domain. > > This has been done for years on many platforms. Exactly! > > > The PSD domains (ACPI) and the new DT binding will tell > > which CPUs are actually in the same clock domain for whomever is > > interested, despite those CPUs not being in the same policy. > > And this information hasn't been used so far in those cases. > > > This requires the extra mask that Nicola introduced. > > What would you use it for, specifically? This would be useful for: - Energy Aware Scheduling: for this you need to know how other CPUs in a clock domain would be impacted by a task placement. For example, if the utilization of a CPU would increase as a result of a certain task placement choice and as a result (for schedutil) its clock rate need would increase as well, this increase in the clock rate, and therefore energy, of the entire domain is considered before making that task placement choice. - Thermal: the usefulness is dependent on the distribution of thermal zones and their attached cooling devices. But with knowledge about what CPUs use the same clock, the thermal governors could cap all dependent CPUs in one go, while for some governor (IPA) knowing about dependent CPUs help with more accurate power allocation, similar to EAS. - Frequency invariance: ideally one would have counters for this, but when lacking counters, even knowing that some CPUs have the same frequency and after using some software aggregation (likely maximum) to establish what that frequency might be, I believe it would still be more useful than no frequency invariance at all. Even if in these cases you don't have accurate information about the frequency that hardware will grant, knowing that some CPUs will change frequency together is useful. Given that some of the above users (EAS, IPA) are proactive and are trying to predict the future state of a system, they did not have completely accurate information to begin with. But not taking into account CPUs sharing a clock will result in too much inaccuracy (that even control loops and can't compensate for). This together with the assumption* that predicted frequencies won't be very far off from granted frequencies will result in maintaining these features in a more useful state. *my assumption, until proven otherwise :) > > > - (b) Making deep changes to cpufreq (core/governors/drivers) to allow: > > Not an option really. Agreed! Thanks, Ionela. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel