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 1CC44C433DF for ; Tue, 13 Oct 2020 12:40: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 A245422460 for ; Tue, 13 Oct 2020 12:40: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="cW1K8x9t" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A245422460 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=uaxm7oXipsbq2VznSubw2KfVFisz5duJWuxpg0170FA=; b=cW1K8x9tTZ3gO8fp6MWe7k74H xP6wTuRVNjyaFoQkYftwSEyQERQ6BTNszorCsA4lNRajfahKh45mHWoDBMNbd3nM6SzDlccN4Z+J6 UzzVdpVGMWWObgYQeKJu6qVlpDM85O52ZYw10AfWSo026bT3dxYy5Bgz8GVKkw45ay3gG79aJTXHx pYwpd0vKaeAZFfkDUvf9R0LVJitiCNFJ1QiIBs7Ep3Cy9mP5bR4cLT4P6J/IbuJ1IXLCQtF0NxHKq ykIMNHhAr206ktXQ5jZ9EQkKjc/wavaCWC3R0Igs1Y4dJWWRqGiFtfa6ztNQTG46Yk+6dne6Cw3+d 8eBEdpifA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSJa8-0006Z9-Vx; Tue, 13 Oct 2020 12:39:09 +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 1kSJa6-0006XY-5o for linux-arm-kernel@lists.infradead.org; Tue, 13 Oct 2020 12:39:07 +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 EB6311FB; Tue, 13 Oct 2020 05:39:02 -0700 (PDT) Received: from localhost (unknown [10.1.199.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8CA9F3F719; Tue, 13 Oct 2020 05:39:02 -0700 (PDT) Date: Tue, 13 Oct 2020 13:39:01 +0100 From: Ionela Voinescu To: "Rafael J. Wysocki" Subject: Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies Message-ID: <20201013123901.GA4945@arm.com> 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> 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-20201013_083906_322326_C45FF329 X-CRM114-Status: GOOD ( 38.99 ) 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 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). > > 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. > Given that multiple drivers could use hardware coordination, and drivers already have a way to pass information about the type of coordination to the core through policy->shared_type, could there be a case for supporting this in the core, rather than the drivers? In my head I'm finding this option better compared to having a select set of drivers that would instruct the core to build the policies per-cpu, while holding in the driver information about what CPUs actually belong to clock domains. Additionally, the cpufreq core will have to be able to present to other frameworks (scheduler, thermal) this mask when requested, through a cpufreq interface function. So in the end we'll still potentially end up passing on this information from the driver to the core and then to the user. > 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. IMO, even if this hardware coordination support is entirely managed by the driver, one requirement is that other subsystems would be able to acquire information about dependent cpus. The scheduler FIE should just be another one of those users, with the decision on how that information is handled residing in architecture code (arch_set_freq_scale()). Architecture code might decide to have a default way of handling these cases or not to support them at all. Thank you, Ionela. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel