linux-kernel - Re: [PATCH v3 2/3] arch_topology: obtain cpu capacity using information from CPPC

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: <YijJzekA1nFEs3nz@arm.com>
Date:   Wed, 9 Mar 2022 15:37:49 +0000
From:   Ionela Voinescu <ionela.voinescu@....com>
To:     Yicong Yang <yangyicong@...wei.com>
Cc:     Sudeep Holla <sudeep.holla@....com>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Giovanni Gherdovich <ggherdovich@...e.cz>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Valentin Schneider <valentin.schneider@....com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Sean Kelley <skelley@...dia.com>, yangyicong@...ilicon.com,
        Pierre Gondois <pierre.gondois@....com>,
        linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 2/3] arch_topology: obtain cpu capacity using
 information from CPPC

Hi Yicong,

On Wednesday 09 Mar 2022 at 18:21:30 (+0800), Yicong Yang wrote:
> Hi Ionela,
> 
> On 2022/3/3 2:09, Ionela Voinescu wrote:
> > Define topology_init_cpu_capacity_cppc() to use highest performance
> > values from _CPC objects to obtain and set maximum capacity information
> > for each CPU. acpi_cppc_processor_probe() is a good point at which to
> > trigger the initialization of CPU (u-arch) capacity values, as at this
> > point the highest performance values can be obtained from each CPU's
> > _CPC objects. Architectures can therefore use this functionality
> > through arch_init_invariance_cppc().
> > 
> > The performance scale used by CPPC is a unified scale for all CPUs in
> > the system. Therefore, by obtaining the raw highest performance values
> > from the _CPC objects, and normalizing them on the [0, 1024] capacity
> > scale, used by the task scheduler, we obtain the CPU capacity of each
> > CPU.
> > 
> 
> So we're going to use highest performance rather than nominal performance,
> and I checked the discussion in v2 [1]. Maybe we should also document this
> in sched-capacity.rst that where scheduler get the capacity from on ACPI
> based system? Currently we only have DT part but after this patch it's
> also supported on ACPI based system.
> 

It's a very good point. I'll send a separate patch for this with added
information in "3.1 CPU capacity" in sched-capacity.rst. I'll send this
separate and not with the rebase that Rafael requested to avoid
confusing things.

> Out of curiosity, since we have raw capacity now on ACPI system, seems we
> are able to scale the capacity with freq_factor now? looked into
> register_cpufreq_notifier().
> 

The freq_factor is only used for DT systems where one provides
"capacity-dmips-mhz" in DT. This entry actually represents DMIPS/MHz.

So the freq_factor, set to:

per_cpu(freq_factor, cpu) = policy->cpuinfo.max_freq / 1000;

is used to obtain the performance at the maximum frequency, basically
DMIPS = (Dhrystone) million instructions per second, by multiplying this
raw value from DT with the freq_factor. After this, all these value for
each CPU type are normalized on a scale [0, 1024], resulting in what we
call CPU capacity.

For ACPI systems freq_factor will have the default value of 1 when we
call topology_normalize_cpu_scale(), as the performance value obtained
from _CPC is already representative for the highest frequency of the CPU
and not performance/Hz as we get from DT. Therefore, we are not and
should not use a freq_factor here.

Hopefully I understood your question correctly.

Thanks,
Ionela.

> [1] https://lore.kernel.org/lkml/Yh5OAsYVBWWko+CH@arm.com/
> 
> Thanks,
> Yicong