Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp4845723rdb; Tue, 12 Dec 2023 10:49:48 -0800 (PST) X-Google-Smtp-Source: AGHT+IHMsW11netoXOGyLcSUa9IUd8r+SYFj53VXrAR/K/NMNEgu9WNhKE9Y0wirT3hfzmeQD5ia X-Received: by 2002:a17:902:da89:b0:1d0:6ffe:1e63 with SMTP id j9-20020a170902da8900b001d06ffe1e63mr4796601plx.70.1702406988132; Tue, 12 Dec 2023 10:49:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702406988; cv=none; d=google.com; s=arc-20160816; b=tEsjOyMU41QdDQDz/1A5j3MqXNgYw/urY2swyT8ZCypUeBl+Il986JxMF8lK0LWN1C R71utOj6IK5HNzRgDKfujtgfPHNCAOEi4FKQ+pPosQpbGe6inY9dkZOi2qyEWGbgTv5H hCYvvu7TQG5PYqLn3KBeEzLeSU3HxEfXMcMv3seAMR5KbpVo9ysmYharNzPZQtfiqPuo mdq7bwu5WJ28ZC9wE1VOFW/oeepRzs/bW070TtT7v3Tqbs7pSUF3xKZETX0TJhfC2k6I AaE00ociOzFnuva5tARLablVumCQz5u5qSXspuq/nKRDGfMnbMRqUoGiUluJHxl7AAMF XNXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=zGQh+gTJwsatugA1Vxett+ndRNDQizQn2DazmgAZFKQ=; fh=b6jz0bdxnlnt0RSJHliaH022TdeHcNL6OWCvUlnI6JM=; b=Ky7XwPHoEd7x20wDAfXJddAMilOUJHAhdiCBHXiAaK/MVLxtAAmoiio5Nbw7aaGiHy o9E8ZckpzBjW6m6xe83924aokn2hG1ispUA+gzYIZRyg/fMsRUdl9k9mp4+HCvJaAkIW hz4yF9pzvDFru7FBMW1Fgi8wFT85t7teLVrjWGZBgOKMHJW2tN75arRzOwmc5PfRNuyU 4U+zkxOihJxE4wGWoVK95YTrreFCvYmDDP5/Qi3wlDhMIGHTbwY675CQwpuoqt7bSN5M objGlms4pxSB9fGsP3RD5g1yl99u9cDUfOKL29U3vVoM9QIKOcE+6cHFzd4uiuqNxGd0 mgRQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id f1-20020a17090274c100b001cf5d073fa7si8240791plt.119.2023.12.12.10.49.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Dec 2023 10:49:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id C1C7080A8BA8; Tue, 12 Dec 2023 10:49:44 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376701AbjLLSt1 (ORCPT + 99 others); Tue, 12 Dec 2023 13:49:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39810 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376685AbjLLStZ (ORCPT ); Tue, 12 Dec 2023 13:49:25 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 1749CF4; Tue, 12 Dec 2023 10:49:31 -0800 (PST) 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 2F5451FB; Tue, 12 Dec 2023 10:50:17 -0800 (PST) Received: from [192.168.178.6] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7D4D43F762; Tue, 12 Dec 2023 10:49:28 -0800 (PST) Message-ID: <985618de-73cf-4b54-aef4-6e7bbfe86b17@arm.com> Date: Tue, 12 Dec 2023 19:49:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 04/23] PM: EM: Refactor em_pd_get_efficient_state() to be more flexible Content-Language: en-US To: Lukasz Luba , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, rafael@kernel.org Cc: rui.zhang@intel.com, amit.kucheria@verdurent.com, amit.kachhap@gmail.com, daniel.lezcano@linaro.org, viresh.kumar@linaro.org, len.brown@intel.com, pavel@ucw.cz, mhiramat@kernel.org, qyousef@layalina.io, wvw@google.com References: <20231129110853.94344-1-lukasz.luba@arm.com> <20231129110853.94344-5-lukasz.luba@arm.com> From: Dietmar Eggemann In-Reply-To: <20231129110853.94344-5-lukasz.luba@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Tue, 12 Dec 2023 10:49:45 -0800 (PST) On 29/11/2023 12:08, Lukasz Luba wrote: > The Energy Model (EM) is going to support runtime modification. There > are going to be 2 EM tables which store information. This patch aims > to prepare the code to be generic and use one of the tables. The function > will no longer get a pointer to 'struct em_perf_domain' (the EM) but > instead a pointer to 'struct em_perf_state' (which is one of the EM's > tables). I thought the 2 EM tables design is gone? IMHO it would be less code changes and hence a more enjoyable review experience if you would add the 'modifiable' feature to the existing EM (1) and not add (2) and then remove (1) in [21/23]. struct em_perf_domain { - struct em_perf_state *table; <-- (1) struct em_perf_table __rcu *runtime_table; <-- (2) > Prepare em_pd_get_efficient_state() for the upcoming changes and > make it possible to re-use. Return an index for the best performance s/make it possible to re-use/make it possible to be re-used ? > state for a given EM table. The function arguments that are introduced > should allow to work on different performance state arrays. The caller of > em_pd_get_efficient_state() should be able to use the index either > on the default or the modifiable EM table. > > Signed-off-by: Lukasz Luba > Reviewed-by: Daniel Lezcano > --- > include/linux/energy_model.h | 30 +++++++++++++++++------------- > 1 file changed, 17 insertions(+), 13 deletions(-) > > diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h > index b9caa01dfac4..8069f526c9d8 100644 > --- a/include/linux/energy_model.h > +++ b/include/linux/energy_model.h > @@ -175,33 +175,35 @@ void em_dev_unregister_perf_domain(struct device *dev); > > /** > * em_pd_get_efficient_state() - Get an efficient performance state from the EM > - * @pd : Performance domain for which we want an efficient frequency > - * @freq : Frequency to map with the EM > + * @state: List of performance states, in ascending order (3) > + * @nr_perf_states: Number of performance states > + * @freq: Frequency to map with the EM > + * @pd_flags: Performance Domain flags > * > * It is called from the scheduler code quite frequently and as a consequence > * doesn't implement any check. > * > - * Return: An efficient performance state, high enough to meet @freq > + * Return: An efficient performance state id, high enough to meet @freq > * requirement. > */ > -static inline > -struct em_perf_state *em_pd_get_efficient_state(struct em_perf_domain *pd, > - unsigned long freq) > +static inline int > +em_pd_get_efficient_state(struct em_perf_state *table, int nr_perf_states, > + unsigned long freq, unsigned long pd_flags) (3) but em_pd_get_efficient_state(struct em_perf_state *table ^^^^^ [...]