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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 AEA39C43457 for ; Tue, 13 Oct 2020 11:53:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 56DCC2080A for ; Tue, 13 Oct 2020 11:53:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602590032; bh=KKcxVZXcGjKnM/UI9lTzx4pQlxixhKKz1kfyIC+NkEo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=z+JuMBDI3PClR0GvEfp+MJM6IFTol4s1ue/cYYID4gKEdgcdv+Kw2yNuPS5Ae+WQt BNqsP5+DECOoQjh9NiV7A8uKgwzSI6ALInoAa++tWjeOcceiTM/ZDdE/7rDsFkWOtL mxZDLLL5p8D3hCXohvOT4d19dWfcrdnvLGvu8Kis= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727293AbgJMLxv (ORCPT ); Tue, 13 Oct 2020 07:53:51 -0400 Received: from mail-ot1-f68.google.com ([209.85.210.68]:37939 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727146AbgJMLxu (ORCPT ); Tue, 13 Oct 2020 07:53:50 -0400 Received: by mail-ot1-f68.google.com with SMTP id i12so18773820ota.5; Tue, 13 Oct 2020 04:53:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KKcxVZXcGjKnM/UI9lTzx4pQlxixhKKz1kfyIC+NkEo=; b=K9hU8vc2OhKUyACN/O+KlBJ9tve2NTGJjDtF3L27RQk7MxhIUiOsx7xJbqyctC7Bnh trM0meU/01ZCp5eQy1LkD5rrNWf89clgg+cbuPwXyyqaOr/i4yUXTNbJPT3NKbnEOj4U zgwIDQiYppettb3EUuaqen4TizxO1ha98Cz9zVI9Vu8jSUA4F+zrG0UG5d+hSrtgEk3d m2AYzSGC9iy31LNQE2if7Tqrt/8X3szgJQlALwvkjQjxbrfRdOe4/Bfi3RdRD834BbGb ZIl7lSjQvCdnvbbUtzO3p4HP5R7D0VJwi2Q5AnozHCHwp3xFIFJznJUGnGsVnsx/RW8v JFyQ== X-Gm-Message-State: AOAM5313ImJ9AfJeyA1/QprqsTV2sXhwXkk1n7kbruPpaS3MjBjDHPhD S+p8q9fLmLuHxVbPxeP3hM5a8R4rI7uF5znI9qQ= X-Google-Smtp-Source: ABdhPJy0vR6s0N4OFATlsxlScbQJBRduTTaV8DeSQXHIEZSmyqHSck8Ni3Ty1HeIUoEYjx+VYLYl1RYVYdDWV6slfyw= X-Received: by 2002:a9d:734f:: with SMTP id l15mr22997616otk.260.1602590029397; Tue, 13 Oct 2020 04:53:49 -0700 (PDT) MIME-Version: 1.0 References: <20201008150317.GB20268@arm.com> <56846759-e3a6-9471-827d-27af0c3d410d@arm.com> <20201009053921.pkq4pcyrv4r7ylzu@vireshk-i7> <42e3c8e9-cadc-d013-1e1f-fa06af4a45ff@arm.com> <20201009140141.GA4048593@bogus> <2b7b6486-2898-1279-ce9f-9e7bd3512152@arm.com> <20201012105945.GA9219@arm.com> <500510b9-58f3-90b3-8c95-0ac481d468b5@arm.com> <20201012163032.GA30838@arm.com> <9fe56600-ba7d-d3b6-eea3-885475d94d7a@arm.com> <20201012220132.GA1715@arm.com> In-Reply-To: <20201012220132.GA1715@arm.com> From: "Rafael J. Wysocki" Date: Tue, 13 Oct 2020 13:53:37 +0200 Message-ID: Subject: Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies To: Ionela Voinescu Cc: Lukasz Luba , Rob Herring , Nicola Mazzucato , Viresh Kumar , "devicetree@vger.kernel.org" , Linux PM , Viresh Kumar , Daniel Lezcano , "Rafael J. Wysocki" , Linux Kernel Mailing List , Sudeep Holla , Chris Redpath , Morten Rasmussen , Linux ARM Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 13, 2020 at 12:01 AM Ionela Voinescu wrote: > > Hey Lukasz, > > I think after all this discussion (in our own way of describing things) > we agree on how the current cpufreq based FIE implementation is affected > in systems that use hardware coordination. > > What we don't agree on is the location where that implementation (that > uses the new mask and aggregation) should be. > > On Monday 12 Oct 2020 at 19:19:29 (+0100), Lukasz Luba wrote: > [..] > > The previous FIE implementation where arch_set_freq_scale() > > was called from the drivers, was better suited for this issue. > > Driver could just use internal dependency cpumask or even > > do the aggregation to figure out the max freq for cluster > > if there is a need, before calling arch_set_freq_scale(). > > > > It is not perfect solution for software FIE, but one of possible > > when there is no hw counters. > > > [..] > > > Difference between new FIE and old FIE (from v5.8) is that the new one > > purely relies on schedutil max freq value (which will now be missing), > > while the old FIE was called by the driver and thus it was an option to > > fix only the affected cpufreq driver [1][2]. > > > > My final argument is that now you have 2 drivers that would need this > support, next you'll have 3 (the new mediatek driver), and in the future > there will be more. So why limit and duplicate this functionality in the > drivers? Why not make it generic for all drivers to use if the system > is using hardware coordination? > > Additionally, I don't think drivers should not even need to know about > these dependency/clock domains. They should act at the level of the > policy, which in this case will be at the level of each CPU. The policies come from the driver, though. The driver decides how many CPUs will be there in a policy and how to handle them at the initialization time. The core has no idea whether or not there is HW coordination in the system, the driver is expected to know that and take that into account. Accordingly, it looks like there should be an option for drivers to arrange things in the most convenient way (from their perspective) and that option has gone away now. 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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 4CE04C43467 for ; Tue, 13 Oct 2020 11:55:22 +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 E4978214DB for ; Tue, 13 Oct 2020 11:55:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="zL2poANd" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E4978214DB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=UfJHgbQ6ebx12dd3vAH/dc8LhJ0jhpwjlxURHhSkyU0=; b=zL2poANdDmjEVTo9DDJLKKtrO 88D0SAdoNcH9hkpYrlyLh4uE7UGH/RvSFeGJRfQYqykL3i8T0sCUfIyS7lVJmSlizyE0RjOeN3zp8 8QHInJOS437Nb5gExSQc4rFQ9+L/bxB1ppkViO2pkW9gFRmII4DyL5/1SM3LWRBO3Vl5BtukOr/La Q2P7yCsK7vqkgfWwsgLuTaBjFOV2Ll0g+a7pv2QlP1uzSWTsWWQVCvHpzrBh5ZFWtCp7aDcWnptEC rUk0N1d+VkXHZgJVI4/2f8Ay25GSrk24SKQbZQkLb7wh67CPus1cIn1lPMLrFJAPrloJWyX2pt8V0 NHEYqsAtw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSIsP-0006z5-KU; Tue, 13 Oct 2020 11:53:57 +0000 Received: from mail-ot1-f66.google.com ([209.85.210.66]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSIsN-0006xS-W0 for linux-arm-kernel@lists.infradead.org; Tue, 13 Oct 2020 11:53:56 +0000 Received: by mail-ot1-f66.google.com with SMTP id q21so18726104ota.8 for ; Tue, 13 Oct 2020 04:53:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KKcxVZXcGjKnM/UI9lTzx4pQlxixhKKz1kfyIC+NkEo=; b=WZYSRYROyyOzSkK5TxeFhtaRX1MkvwECrY/3Ro0tbs4/NumFF+mbLbrny+oFPYUBjw itFPQa9RGfKkziPlUfpQtn7LL18crBcp58XV+da1spD6TPL1pIzuiBRzgGljUe0NWtyX fy1QA6vgbI3iNHe8Nyn7/BjezJw/8vy4ehaVTC4Ve96Ztma/uOJ7naeagjVQ0Bh3e5ln wpzDSqXMRTp/gjSiC2zKQzAArkwzsYFzFoeLLGWaK1dwJ4ve4PiKNW8wAWTKvZcAd3Ol z0Ocu6Xjcop+oICtV0sCkhtyvUWuAEQfzAt9Unx9fTV55K7SxdLp2g0DG3rJm1Rp81TS kL4g== X-Gm-Message-State: AOAM533wKM6UBEVZSpB1Ka5m326e3KzjR+p9HIpFdvfojdmeJH/8JLzK soL/jR+2sz68mDnLTlWNTG/PxtEr2V0EJnVT5hU= X-Google-Smtp-Source: ABdhPJy0vR6s0N4OFATlsxlScbQJBRduTTaV8DeSQXHIEZSmyqHSck8Ni3Ty1HeIUoEYjx+VYLYl1RYVYdDWV6slfyw= X-Received: by 2002:a9d:734f:: with SMTP id l15mr22997616otk.260.1602590029397; Tue, 13 Oct 2020 04:53:49 -0700 (PDT) MIME-Version: 1.0 References: <20201008150317.GB20268@arm.com> <56846759-e3a6-9471-827d-27af0c3d410d@arm.com> <20201009053921.pkq4pcyrv4r7ylzu@vireshk-i7> <42e3c8e9-cadc-d013-1e1f-fa06af4a45ff@arm.com> <20201009140141.GA4048593@bogus> <2b7b6486-2898-1279-ce9f-9e7bd3512152@arm.com> <20201012105945.GA9219@arm.com> <500510b9-58f3-90b3-8c95-0ac481d468b5@arm.com> <20201012163032.GA30838@arm.com> <9fe56600-ba7d-d3b6-eea3-885475d94d7a@arm.com> <20201012220132.GA1715@arm.com> In-Reply-To: <20201012220132.GA1715@arm.com> From: "Rafael J. Wysocki" Date: Tue, 13 Oct 2020 13:53:37 +0200 Message-ID: Subject: Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies To: Ionela Voinescu X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201013_075356_035931_F9B3223F X-CRM114-Status: GOOD ( 29.50 ) 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: Linux ARM , Rob Herring , Daniel Lezcano , "devicetree@vger.kernel.org" , Viresh Kumar , Linux PM , "Rafael J. Wysocki" , Linux Kernel Mailing List , Sudeep Holla , Nicola Mazzucato , Viresh Kumar , Chris Redpath , Morten Rasmussen , Lukasz Luba 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 On Tue, Oct 13, 2020 at 12:01 AM Ionela Voinescu wrote: > > Hey Lukasz, > > I think after all this discussion (in our own way of describing things) > we agree on how the current cpufreq based FIE implementation is affected > in systems that use hardware coordination. > > What we don't agree on is the location where that implementation (that > uses the new mask and aggregation) should be. > > On Monday 12 Oct 2020 at 19:19:29 (+0100), Lukasz Luba wrote: > [..] > > The previous FIE implementation where arch_set_freq_scale() > > was called from the drivers, was better suited for this issue. > > Driver could just use internal dependency cpumask or even > > do the aggregation to figure out the max freq for cluster > > if there is a need, before calling arch_set_freq_scale(). > > > > It is not perfect solution for software FIE, but one of possible > > when there is no hw counters. > > > [..] > > > Difference between new FIE and old FIE (from v5.8) is that the new one > > purely relies on schedutil max freq value (which will now be missing), > > while the old FIE was called by the driver and thus it was an option to > > fix only the affected cpufreq driver [1][2]. > > > > My final argument is that now you have 2 drivers that would need this > support, next you'll have 3 (the new mediatek driver), and in the future > there will be more. So why limit and duplicate this functionality in the > drivers? Why not make it generic for all drivers to use if the system > is using hardware coordination? > > Additionally, I don't think drivers should not even need to know about > these dependency/clock domains. They should act at the level of the > policy, which in this case will be at the level of each CPU. The policies come from the driver, though. The driver decides how many CPUs will be there in a policy and how to handle them at the initialization time. The core has no idea whether or not there is HW coordination in the system, the driver is expected to know that and take that into account. Accordingly, it looks like there should be an option for drivers to arrange things in the most convenient way (from their perspective) and that option has gone away now. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel