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,NICE_REPLY_A,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 CB494C636C9 for ; Mon, 19 Jul 2021 09:01:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 015316100C for ; Mon, 19 Jul 2021 09:01:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235379AbhGSIUW (ORCPT ); Mon, 19 Jul 2021 04:20:22 -0400 Received: from foss.arm.com ([217.140.110.172]:53032 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235728AbhGSIUO (ORCPT ); Mon, 19 Jul 2021 04:20:14 -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 2D8B06D; Mon, 19 Jul 2021 01:52:10 -0700 (PDT) Received: from [10.57.3.138] (unknown [10.57.3.138]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1E93D3F73D; Mon, 19 Jul 2021 01:52:07 -0700 (PDT) Subject: Re: [RFC PATCH v2 0/6] Introduce Active Stats framework with CPU performance statistics To: "Rafael J. Wysocki" Cc: Linux Kernel Mailing List , Daniel Lezcano , Linux PM , Amit Kucheria , "Zhang, Rui" , Dietmar Eggemann , Chris Redpath , Beata.Michalska@arm.com, Viresh Kumar , "Rafael J. Wysocki" , Amit Kachhap References: <20210706131828.22309-1-lukasz.luba@arm.com> <1de9d474-fdeb-8db6-0b01-53a90f7c20c8@arm.com> <4d4801c3-1d84-9754-815c-71a6412cf4f3@arm.com> From: Lukasz Luba Message-ID: Date: Mon, 19 Jul 2021 09:52:06 +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: 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 7/14/21 7:30 PM, Rafael J. Wysocki wrote: > Sorry for the delay. Thank you for coming back with comments. No worries, I've been on holidays last week :) [snip] >>>> >>>> I understand your concerns. If you have another idea than this framework >>>> I'm happy to hear it. Maybe better stats in cpuidle, which would be >>>> are of the cpufreq? >>> >>> One idea that I have is outlined above and I'm not seeing a reason to >>> put cpufreq statistics into cpuidle. >>> >> >> I'm happy to prepare such RFC if you like. > > Well, it should be quite clear that I would prefer this to the > original approach, if viable at all. :-) Sure, let me check if this approach is viable. I'll come back to you in next days... > >> I would just need a bit more information. > > OK For now I have only high level questions: 1. The stats data structures and related manageable code should live in the cpuidle and cpufreq just calls some API to notify about freq transition? (no split of data, code between these two frameworks) 2. The registration/allocation of these structures inside the cpuidle could be done using cpufreq_register_notifier() with notification mechanism? 3. CPU hotplug notification (which is needed for these stats) can be used inside the cpuidle (cpuhp_setup_state(CPUHP_AP_ONLINE_DYN,...))?