Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4603707pxj; Tue, 22 Jun 2021 04:09:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJznG6SfnJJThwuST1gSFR/CRt1vNW94OvUALXu9IajvgA50kGxIm2X423SYI6H0s9O9AmuC X-Received: by 2002:a05:6402:1914:: with SMTP id e20mr4157656edz.310.1624360155463; Tue, 22 Jun 2021 04:09:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624360155; cv=none; d=google.com; s=arc-20160816; b=r3QGkypxxx7Rt3QOJSEb4rhigPb3RYijkjuQrRmYo3mKgqoaGnOrjC8BA5ktqzKRQ5 kspMk+bZY//thcfrJH8BiT//AqCbk3xBfYGUJ80IBXVY+QQkgEENm9rJLZL/tU/bzq/x 5x9Gr/zQA7ULaTys6QNNq0FUiXjT1dbon16//Wqs4hH8K9IP6VghMyf58jTHttI1CqWK c/zmJRR3yutyAHcWsNK+JMNg7PF2RNw4pxclVjcrdORtW4IE5FzBPOpE9OsGe3ZpZkev dySmeBYIlNhN5w0IvTr9rrg3QR/mqlbQBAdvRMnrzoskOdzrbustXiBaruf8OIMtaAJM rUiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=VDFRbtI3RJLRfnkJacDrRPyoLf04doUzBuExijbjMTA=; b=fvg1+iuqj2u7j4Nj0bBK0lUeo0vaG31xjvU7G4PePvzfO2uTMyHaYon2FawD2Xxh7j 4jkuwebUihX3dvmQh9uamLiOWzvTkzwBh7aw3MJY41nOnKZohw9c8bgL+j09nGEG0xh4 MMplokIuWYSGnEFDRL+wpcGFx+OHtsLzJ+dGDu52asak3842TeHUbdT8EhmexHcGSOgH 3RRL5ZPEaNMQ1LdLj4qIFIJm6gjQEUs+l9RnB2jdgxbCHuBILHcthiSaPcZ/qC5TBxaZ GsY4vrdKjGVtfm0tsYIrgbqcQaRDsru29+oQRUt/Y6+S3yN7qTKU9MVJ9QbS6lscInNx CYFg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m19si15215398edd.117.2021.06.22.04.08.53; Tue, 22 Jun 2021 04:09:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230103AbhFVLJe (ORCPT + 99 others); Tue, 22 Jun 2021 07:09:34 -0400 Received: from foss.arm.com ([217.140.110.172]:47136 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229769AbhFVLJe (ORCPT ); Tue, 22 Jun 2021 07:09:34 -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 47D6B31B; Tue, 22 Jun 2021 04:07:18 -0700 (PDT) Received: from [10.57.7.129] (unknown [10.57.7.129]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5F2503F694; Tue, 22 Jun 2021 04:07:16 -0700 (PDT) Subject: Re: [RFC PATCH 3/4] cpufreq: Add Active Stats calls tracking frequency changes To: Viresh Kumar Cc: linux-kernel@vger.kernel.org, daniel.lezcano@linaro.org, linux-pm@vger.kernel.org, amitk@kernel.org, rui.zhang@intel.com, dietmar.eggemann@arm.com, Chris.Redpath@arm.com, Beata.Michalska@arm.com, rjw@rjwysocki.net, amit.kachhap@gmail.com References: <20210622075925.16189-1-lukasz.luba@arm.com> <20210622075925.16189-4-lukasz.luba@arm.com> <20210622093258.lddlznwsndpw5mju@vireshk-i7> From: Lukasz Luba Message-ID: Date: Tue, 22 Jun 2021 12:07:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20210622093258.lddlznwsndpw5mju@vireshk-i7> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/22/21 10:32 AM, Viresh Kumar wrote: > Not commenting on the idea itself but just the code changes here. > > On 22-06-21, 08:59, Lukasz Luba wrote: >> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c >> index 802abc925b2a..d79cb9310572 100644 >> --- a/drivers/cpufreq/cpufreq.c >> +++ b/drivers/cpufreq/cpufreq.c >> @@ -14,6 +14,7 @@ >> >> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt >> >> +#include >> #include >> #include >> #include >> @@ -387,6 +388,8 @@ static void cpufreq_notify_transition(struct cpufreq_policy *policy, >> >> cpufreq_stats_record_transition(policy, freqs->new); >> policy->cur = freqs->new; >> + >> + active_stats_cpu_freq_change(policy->cpu, freqs->new); >> } >> } >> >> @@ -2085,6 +2088,8 @@ unsigned int cpufreq_driver_fast_switch(struct cpufreq_policy *policy, >> policy->cpuinfo.max_freq); >> cpufreq_stats_record_transition(policy, freq); >> >> + active_stats_cpu_freq_fast_change(policy->cpu, freq); >> + > > It would have been better if you would have modified > cpufreq_stats_record_transition() instead, since that is there for > similar kind of stats. That cpufreq_stats_record_transition() is present only if CONFIG_CPU_FREQ_STAT is set. I didn't wanted to be dependent on this config. > > Plus don't you need to record this for all policy->cpus instead of > just policy->cpu ? > It will be accounted for all cpus in that freq domain. The active_stats_cpu_freq_fast_change() implementation uses a shared structure (single for whole domain) 'shared_ast': _active_stats_cpu_freq_change(ast->shared_ast, freq, ts) (from patch 1/4)