linux-kernel - Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4962aa3c-2b56-5232-c5d7-286ca1363446@gmail.com>
Date:   Wed, 5 Aug 2020 10:33:02 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Sudeep Holla <sudeep.holla@....com>,
        Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Lukasz Luba <lukasz.luba@....com>, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-pm@...r.kernel.org,
        cristian.marussi@....com, rjw@...ysocki.net
Subject: Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers



On 8/5/2020 9:03 AM, Sudeep Holla wrote:
> On Wed, Aug 05, 2020 at 06:34:36PM +0530, Viresh Kumar wrote:
>> On 05-08-20, 12:04, Lukasz Luba wrote:
>>> I know that Viresh is going to develop patches and improve these
>>> cpufreq stats framework. Maybe he also had this 'aggregation' in mind.
>>> I will leave it him.
>>
>> I am only going to look at cpufreq's view of stats independently from
>> the firmware.
>>
> 
> +1, I agree with that. Kernel must avoid any logic to aggregate or
> interpret the data in a generic way. The userspace tools can manage that
> especially if this tend to be platform specific.

We can probably standardize on how to expose the firmware maintained
statistics such that these tools do not have to widely vary from
platform to platform, right?
-- 
Florian