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=-6.8 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_GIT 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 75BBAC55178 for ; Mon, 2 Nov 2020 12:04:31 +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 0181122226 for ; Mon, 2 Nov 2020 12:04:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="CPV6dtQM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0181122226 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:MIME-Version:References:In-Reply-To:Message-Id:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=9QrfEluCUPjVyBl42RpV2qluswUHcUo+fGvhG2aHgOs=; b=CPV6dtQMgj3PKrVdLQUCBNA+/ VkaoXyv6iacEPYRBMvG8asoBOf0oxpYAs90QsL+XAEE9Rdi5YUwv+TCIAoLxjL0ZyQu+tozltglv4 YTazD6Zio4Yths68mBpMt+QcZ8y7iZ7O+36IiZfftZWbVU+5lo76fMWd//Z54q8fgOkSL7t7aBgnk TFM2ShHU3YZ03lCBMpPhqRvd3ZIQoW4Jwq/SvrR1OKyFGkF3RGp56o9u05otRmcbETGwY36dkStRI D3dborO8Ot2VY7TyfatMSBrnmkROWgRXY5lqjRkul5mtb6DF6vnYq1VCdGEGBAg2Wn9136VivcJEi NkXHyG+Nw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kZYXP-00017G-Gj; Mon, 02 Nov 2020 12:02:15 +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 1kZYXG-00014l-Um for linux-arm-kernel@lists.infradead.org; Mon, 02 Nov 2020 12:02:08 +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 9E33631B; Mon, 2 Nov 2020 04:02:05 -0800 (PST) Received: from ubuntu.arm.com (unknown [10.57.53.184]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 4F1303F66E; Mon, 2 Nov 2020 04:02:03 -0800 (PST) From: Nicola Mazzucato To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, sudeep.holla@arm.com, rjw@rjwysocki.net, vireshk@kernel.org, robh+dt@kernel.org, sboyd@kernel.org, nm@ti.com, daniel.lezcano@linaro.org Subject: [PATCH v3 3/3] [RFC] CPUFreq: Add support for cpu-perf-dependencies Date: Mon, 2 Nov 2020 12:01:15 +0000 Message-Id: <20201102120115.29993-4-nicola.mazzucato@arm.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20201102120115.29993-1-nicola.mazzucato@arm.com> References: <20201102120115.29993-1-nicola.mazzucato@arm.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201102_070207_164211_75EBD508 X-CRM114-Status: GOOD ( 18.65 ) 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: chris.redpath@arm.com, morten.rasmussen@arm.com, nicola.mazzucato@arm.com 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 All, This is a continuation of the previous v2, where we focused mostly on the dt binding. I am seeking some feedback/comments on the following two approaches. Intro: We have seen that in a system where performance control and hardware description do not match (i.e. per-cpu), we still need the information of how the v/f lines are shared among the cpus. We call this information "performance dependencies". We got this info through the opp-shared (the previous 2 patches aim for that). Problem: How do we share such info (retrieved from a cpufreq driver) to other consumers that rely on it? I have two proposals. First proposal: Having a new cpumask 'dependent_cpus' to represent the CPU performance dependencies seems a viable and scalable way. The main reason for a new cpumaks is that although 'related_cpus' could be (or could have been) used for such purpose, its meaning has changed over time [1]. Provided that the cpufreq driver will populate dependent_cpus and set shared_type accordingly, the s/w components that rely on such description (we focus on energy-model and cpufreq_cooling for now) will always be provided with the correct information, when picking the new cpumask. Proposed changes (at high level)(3): 1) cpufreq: Add new dependent_cpus cpumaks in cpufreq_policy * New cpumask addition struct cpufreq_policy { cpumask_var_t related_cpus; /* Online + Offline CPUs */ cpumask_var_t real_cpus; /* Related and present */ + /* + * CPUs with hardware clk/perf dependencies + * + * For sw components that rely on h/w info of clk dependencies when hw + * coordinates. This cpumask should always reflect the hw dependencies. + */ + cpumask_var_t dependent_cpus; /* all clk-dependent cpus */ + unsigned int shared_type; /* ACPI: ANY or ALL affected CPUs * Fallback mechanism for dependent_cpus. With this, s/w components can always pick dependent_cpus regardless the coordination type. static int cpufreq_online(unsigned int cpu) /* related_cpus should at least include policy->cpus. */ cpumask_copy(policy->related_cpus, policy->cpus); + + /* dependent_cpus should differ only when hw coordination is in place */ + if (policy->shared_type != CPUFREQ_SHARED_TYPE_HW) + cpumask_copy(policy->dependent_cpus, policy->cpus); } * Add sysfs attribute for dependent_cpus 2) drivers/thermal/cpufreq_cooling: Replace related_cpus with dependent_cpus 3) drivers/cpufreq/scmi-cpufreq: Get perf-dependencies from dev_pm_opp_of_get_sharing_cpus() * Call dev_pm_opp_of_get_sharing_cpus() * Populate policy->dependent_cpus if possible * Set policy->shared_type accordingly * Provide to EM the correct performance dependencies information - em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, policy->cpus); + /* + * EM needs accurate information about perf boundaries, thus provide the + * correct cpumask. + */ + if (policy->shared_type == CPUFREQ_SHARED_TYPE_HW) + em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, + policy->dependent_cpus); + else + em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, + policy->cpus); Second proposal: Another option could be for each driver to store internally the performance dependencies and let the driver directly provide the correct cpumask for any consumer. Whilst this works fine for energy model (see above), it is not the case (currently) for cpufreq_cooling, thus we would need to add a new interface for it. That way the driver can call directly the registration function. This seems to be possible since the CPUFreq core can skip to register cpufreq_cooling (flag CPUFREQ_IS_COOLING_DEV). In comparison with the first proposal this one is less scalable since each driver will have to call the registration functions, while in some cases the CPUFreq core could do it. Any comments/preferences? Many Thanks Nicola [1] https://lkml.org/lkml/2020/9/24/399 -- 2.27.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel