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 CE634C433DF for ; Thu, 15 Oct 2020 15:58:40 +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 4FE2F20878 for ; Thu, 15 Oct 2020 15: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="iZxxmoM0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4FE2F20878 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=LDExAUjp4v+BCJWfDV2x7F+/zpRcyFhtakArRO6dWYk=; b=iZxxmoM0WXhUpEDAW0uhet2b2 AQU8OLjESL2Sy6L+c15mHE+Ng3kwZwIdXB5UB9M36OEPxyt4p/R/6z08vqCxKDbPsTavaVaXjAxYh lGOV3xKEo51FpXqP0HvORKFQUbKbq+NdBzYJaIlWXnYxXQ5Rst8C6MX/dzwHKY8BZtkfZkqCJigUv fnFK0HWFv3LxEHHhw1/EdNZ92Ybw9jyfMnnOjKg0KmdXjosPVAryH+OJwD85udiHA/Dig3RhM4PwG BDDnfOkSmRKrUFG2uARgGKqlsln3imcj/xlW9FFWefY84N1SnhO09/YvimVNydZg70mD9foDHlAfx m5sHalYWg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kT5cv-0005yZ-Cj; Thu, 15 Oct 2020 15:57:13 +0000 Received: from mail-ot1-f65.google.com ([209.85.210.65]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kT5ct-0005xr-0K for linux-arm-kernel@lists.infradead.org; Thu, 15 Oct 2020 15:57:11 +0000 Received: by mail-ot1-f65.google.com with SMTP id l4so3352900ota.7 for ; Thu, 15 Oct 2020 08:57:08 -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=/4GgpJhvEPw5RrmkaieTPcF/Ng6iwVy7UMFgWDDaTjU=; b=A1ZJ3v9Vq2FjfRauaqyDnk0Gh+VzvEV8FobLiWmNs24kZNPSZ+5tpP0MCMxJhAfN3C +gagrgZkdfETMUaoL4YoTY3mUTXIf+H+AViJjx6J1lkTytc7MniWRZgfmm7IF4NTF5fk VCqi2WciiTcV2IF7R83k0ITEjTl6nQGUcEuP/ZFQRz92EYvAlAX1f8yPp18hkFdTDMqb 5KgDZaHLScVI+vn0QIN+RGxrVN7miMaHqDdj5dokgAEc9JiqSlt3wK/dN88FbO1RhDvA Fhag4S3+fnf65hboUJLgKTJ0B0qNKD+A7rxYyGOOuCASp1lcwzN94cfBlW3zK7gQjkbC oTyg== X-Gm-Message-State: AOAM531E0ZNf61bT1X6jvWJEwepNqzxNqLtltN8IvU0FCPJhmHgSQ7ug eoYq5kkDhE2XWZML6trhRnnDbKJR1mGDHbIDevw= X-Google-Smtp-Source: ABdhPJyoltGbkt59n4Bo3l3lomRSlxR74vdWZMPehbXbYcmhXPVPGK9lsyyM/iMmR5AAB2q/h2XA+bsJcjxkwerJJsY= X-Received: by 2002:a9d:ac9:: with SMTP id 67mr3254584otq.321.1602777428385; Thu, 15 Oct 2020 08:57:08 -0700 (PDT) MIME-Version: 1.0 References: <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> <20201013123901.GA4945@arm.com> In-Reply-To: <20201013123901.GA4945@arm.com> From: "Rafael J. Wysocki" Date: Thu, 15 Oct 2020 17:56:56 +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-20201015_115711_050977_2D0AA5F8 X-CRM114-Status: GOOD ( 38.96 ) 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" , "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 2:39 PM Ionela Voinescu wrote: > > Hi Rafael, > > On Tuesday 13 Oct 2020 at 13:53:37 (+0200), Rafael J. Wysocki wrote: > > 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. > > Yes, policies are built based on information populated from the drivers > at .init(): what CPUs will belong to a policy, what methods to use for > setting and getting frequency, etc. > > So they do pass this information to the cpufreq core to be stored at the > level of the policy, but later drivers (in the majority of cases) will > not need to store on their own information on what CPUs belong to a > frequency domain, they rely on having passed that information to the > core, and the core mechanisms hold this information on the clock domains > (currently through policy->cpus and policy->related_cpus). Strictly speaking, not quite. In fact policy->related_cpus is a set of CPUs that share a common perf control HW/FW interface which may or may not match the boundaries of clock domains etc. That's what the entire cpufreq needs to know and cares about. AFAICS your scale invariance rework patches were based on the assumption that CPUs sharing an interface like that should also belong to the same frequency domain, which is reasonable and that's why I didn't have a problem with it, but if you were really assuming that policy->related_cpus must always reflect a frequency domain, then I'm afraid that you were not going in the right direction (the one-CPU-per-policy with HW coordination example should be sufficient to illustrate that). It is correct that drivers generally don't need to know about the HW clock (or voltage for that matter) coordination dependencies, but the rest of cpufreq doesn't need to know about them either. If that information is needed for something else, I don't see a reason to put it into cpufreq. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel