linux-kernel - Re: [RFC PATCH v2 0/6] Introduce Active Stats framework with CPU performance statistics

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 19 Jul 2021 09:52:06 +0100
From:   Lukasz Luba <lukasz.luba@....com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Amit Kucheria <amitk@...nel.org>,
        "Zhang, Rui" <rui.zhang@...el.com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Chris Redpath <Chris.Redpath@....com>, Beata.Michalska@....com,
        Viresh Kumar <viresh.kumar@...aro.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Amit Kachhap <amit.kachhap@...il.com>
Subject: Re: [RFC PATCH v2 0/6] Introduce Active Stats framework with CPU
 performance statistics

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,...))?