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,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 C73F1C07E95 for ; Fri, 2 Jul 2021 19:17:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AFCD36141D for ; Fri, 2 Jul 2021 19:17:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230427AbhGBTTk (ORCPT ); Fri, 2 Jul 2021 15:19:40 -0400 Received: from foss.arm.com ([217.140.110.172]:53196 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229996AbhGBTTi (ORCPT ); Fri, 2 Jul 2021 15:19:38 -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 40E561FB; Fri, 2 Jul 2021 12:17:06 -0700 (PDT) Received: from e120877-lin.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E1EF33F718; Fri, 2 Jul 2021 12:17:04 -0700 (PDT) Date: Fri, 2 Jul 2021 20:17:00 +0100 From: Vincent Donnefort To: "Rafael J. Wysocki" Cc: Lukasz Luba , "Rafael J. Wysocki" , Viresh Kumar , Peter Zijlstra , Vincent Guittot , Quentin Perret , Linux PM , Ionela Voinescu , Dietmar Eggemann Subject: Re: [PATCH v3 3/6] cpufreq: Add an interface to mark inefficient frequencies Message-ID: <20210702191658.GA30379@e120877-lin.cambridge.arm.com> References: <20210616093127.lfpi4rje56b3dhwx@vireshk-i7> <20210616105327.wnppsau4gg5ihrlv@vireshk-i7> <4d975236-943c-ea82-547b-04f2bead9f48@arm.com> <0a930559-a648-c20d-f3f6-09e4974a031d@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org [...] > > > > > > I'm guessing that the problem is that cpufreq_cooling works by using > > > freq_qos_update_request() to update the max frequency limit and if > > > that is in effect you'd rather use the inefficient frequencies, > > > whereas when the governor selects an inefficient frequency below the > > > policy limit, you'd rather use a higher-but-efficient frequency > > > instead (within the policy limit). > > > > > > Am I guessing correctly? > > > > > > > Yes, correct. Thermal would use all (efficient + inefficient), but > > we in cpufreq governor would like to pick if possible the efficient > > one (below the thermal limit). > > To address that, you need to pass more information from schedutil to > __cpufreq_driver_target() that down the road can be used by > cpufreq_frequency_table_target() to decide whether or not to skip the > inefficient frequencies. > > For example, you can define CPUFREQ_RELATION_EFFICIENT and pass it > from schedutil to __cpufreq_driver_target() in the "relation" > argument, and clear it if the target frequency is above the max policy > limit, or if ->target() is to be called. What about a cpufreq_policy option that if sets would make cpufreq_frequency_table_target() skip inefficient OPPs while staying within the limit of max policy? Each governor could decide to set it or not, but it would hide the efficiency resolution to the governor and allow drivers that implements ->target() to also implements support for inefficient OPPs. That flag could be set according to a new cpufreq_governor flag CPUFREQ_GOV_SKIP_INEFFICIENCIES? That could though modify behaviors like powersave_bias from ondemand. But if a frequency is inefficient, there's probably no power saving anyway. -- Vincent