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, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,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 8D45CC4727E for ; Wed, 7 Oct 2020 12:56:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 433B62080A for ; Wed, 7 Oct 2020 12:56:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728345AbgJGM45 (ORCPT ); Wed, 7 Oct 2020 08:56:57 -0400 Received: from foss.arm.com ([217.140.110.172]:43404 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727253AbgJGM44 (ORCPT ); Wed, 7 Oct 2020 08:56:56 -0400 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 0C7121042; Wed, 7 Oct 2020 05:56:56 -0700 (PDT) Received: from [10.57.14.1] (unknown [10.57.14.1]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 33CD43F66B; Wed, 7 Oct 2020 05:56:54 -0700 (PDT) Subject: Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies To: Viresh Kumar Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pm@vger.kernel.org, sudeep.holla@arm.com, rjw@rjwysocki.net, vireshk@kernel.org, robh+dt@kernel.org, daniel.lezcano@linaro.org, morten.rasmussen@arm.com, chris.redpath@arm.com References: <20200924095347.32148-1-nicola.mazzucato@arm.com> <20200924095347.32148-3-nicola.mazzucato@arm.com> <20201006071909.3cgz7i5v35dgnuzn@vireshk-i7> From: Nicola Mazzucato Message-ID: <2417d7b5-bc58-fa30-192c-e5991ec22ce0@arm.com> Date: Wed, 7 Oct 2020 13:58:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20201006071909.3cgz7i5v35dgnuzn@vireshk-i7> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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). This performance dependency information is essential for some components that take information from the cpufreq policy. To restore functionality we can use the optional node 'cpu-performance-dependencies' in dt which will provide such dependency information and we can add a new cpumask 'dependency_cpus' in policy. Hope it gives some clarity. Nicola On 10/6/20 8:19 AM, Viresh Kumar wrote: > On 24-09-20, 10:53, Nicola Mazzucato wrote: >> I am seeking some feedback/comments on the following approach. >> >> Intro: >> Info of performance depency for cpus will be beneficial for systems >> where f/w description of the CPU performance control domain is different >> from the clock domain, e.g. per-CPU control with multiple CPUs sharing >> clock, and kernel OSPM s/w components need to take CPU performance >> dependency into account. >> Essentially these s/w components will have to be provided with >> this information from dt and this RFC is presenting a possible way >> to do so. > > I am not sure I understand what performance control mean here. Can you please > elaborate a bit more on that ? For example, with current code and understanding, > a cpufreq policy belongs to a group of CPUs which change their frequency > together, which also mean that they change their performance level together and > so I am not able to understand what's going on here. Sorry about that. > > What kind of hardware configuration doesn't work with this ? > 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.0 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 4F22CC4363D for ; Wed, 7 Oct 2020 12:58:41 +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 C61D120789 for ; Wed, 7 Oct 2020 12:58:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ieGak353" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C61D120789 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: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=R9yD+IQOPRWVi7iLqBneGw7/szosk44I9ouHqHQaIrs=; b=ieGak353dRbIHOWByVghx2F5v MKNfnEb3koggyq0mrC5dsVcdZYBFM1rKHfuPgJBSCWI3Kbbi5bGz5/++XrLc4tDUIUVM/PNabfhiK x19ZXb0oSYReUzCio3Q9KSI0lCXdoHekeXtOT1jHPqg+UJVyuwShJ63qEGcpeIEyVHf+EfLSWGkiS HFAB98BfStvoGECS5opaigqttnN2rbdSBgPd7ReWXzcFpmu5aWfkYrQ8VKlpJ5ZqdTmuujyOPErQ5 JIHnXsznZCOfGH6CmVPOL2YUGxunRCRUH/Dn8wiwgbp+tWi68hGom44Uqxe/bkhx/w054FcJ2g6+z BGEFEmwEQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQ908-0005hn-6f; Wed, 07 Oct 2020 12:57:00 +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 1kQ906-0005g3-2R for linux-arm-kernel@lists.infradead.org; Wed, 07 Oct 2020 12:56:59 +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 0C7121042; Wed, 7 Oct 2020 05:56:56 -0700 (PDT) Received: from [10.57.14.1] (unknown [10.57.14.1]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 33CD43F66B; Wed, 7 Oct 2020 05:56:54 -0700 (PDT) Subject: Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies To: Viresh Kumar References: <20200924095347.32148-1-nicola.mazzucato@arm.com> <20200924095347.32148-3-nicola.mazzucato@arm.com> <20201006071909.3cgz7i5v35dgnuzn@vireshk-i7> From: Nicola Mazzucato Message-ID: <2417d7b5-bc58-fa30-192c-e5991ec22ce0@arm.com> Date: Wed, 7 Oct 2020 13:58:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20201006071909.3cgz7i5v35dgnuzn@vireshk-i7> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201007_085658_263074_0AB84C77 X-CRM114-Status: GOOD ( 21.35 ) 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, linux-pm@vger.kernel.org, vireshk@kernel.org, daniel.lezcano@linaro.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, robh+dt@kernel.org, sudeep.holla@arm.com, chris.redpath@arm.com, morten.rasmussen@arm.com, linux-arm-kernel@lists.infradead.org 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 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). This performance dependency information is essential for some components that take information from the cpufreq policy. To restore functionality we can use the optional node 'cpu-performance-dependencies' in dt which will provide such dependency information and we can add a new cpumask 'dependency_cpus' in policy. Hope it gives some clarity. Nicola On 10/6/20 8:19 AM, Viresh Kumar wrote: > On 24-09-20, 10:53, Nicola Mazzucato wrote: >> I am seeking some feedback/comments on the following approach. >> >> Intro: >> Info of performance depency for cpus will be beneficial for systems >> where f/w description of the CPU performance control domain is different >> from the clock domain, e.g. per-CPU control with multiple CPUs sharing >> clock, and kernel OSPM s/w components need to take CPU performance >> dependency into account. >> Essentially these s/w components will have to be provided with >> this information from dt and this RFC is presenting a possible way >> to do so. > > I am not sure I understand what performance control mean here. Can you please > elaborate a bit more on that ? For example, with current code and understanding, > a cpufreq policy belongs to a group of CPUs which change their frequency > together, which also mean that they change their performance level together and > so I am not able to understand what's going on here. Sorry about that. > > What kind of hardware configuration doesn't work with this ? > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel