Re: [PATCH v3] ACPI: processor: Move arch_init_invariance_cppc() call later

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 4, 2024 at 10:38 PM Ivan Shapovalov <intelfx@xxxxxxxxxxxx> wrote:
>
> On 2024-11-04 at 15:14 -0600, Mario Limonciello wrote:
> > On 11/4/2024 15:10, Rafael J. Wysocki wrote:
> > > On Mon, Nov 4, 2024 at 9:54 PM Mario Limonciello <superm1@xxxxxxxxxx> wrote:
> > > >
> > > > From: Mario Limonciello <mario.limonciello@xxxxxxx>
> > > >
> > > > arch_init_invariance_cppc() is called at the end of
> > > > acpi_cppc_processor_probe() in order to configure frequency invariance
> > > > based upon the values from _CPC.
> > > >
> > > > This however doesn't work on AMD CPPC shared memory designs that have
> > > > AMD preferred cores enabled because _CPC needs to be analyzed from all
> > > > cores to judge if preferred cores are enabled.
> > > >
> > > > This issue manifests to users as a warning since commit 21fb59ab4b97
> > > > ("ACPI: CPPC: Adjust debug messages in amd_set_max_freq_ratio() to warn"):
> > > > ```
> > > > Could not retrieve highest performance (-19)
> > > > ```
> > > >
> > > > However the warning isn't the cause of this, it was actually
> > > > commit 279f838a61f9 ("x86/amd: Detect preferred cores in
> > > > amd_get_boost_ratio_numerator()") which exposed the issue.
> > > >
> > > > To fix this problem, change arch_init_invariance_cppc() into a new weak
> > > > symbol that is called at the end of acpi_processor_driver_init().
> > > > Each architecture that supports it can declare the symbol to override
> > > > the weak one.
> > > >
> > > > Fixes: 279f838a61f9 ("x86/amd: Detect preferred cores in amd_get_boost_ratio_numerator()")
> > > > Reported-by: Ivan Shapovalov <intelfx@xxxxxxxxxxxx>
> > > > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219431
> > > > Tested-by: Oleksandr Natalenko <oleksandr@xxxxxxxxxxxxxx>
> > > > Signed-off-by: Mario Limonciello <mario.limonciello@xxxxxxx>
> > > > ---
> > > > v3:
> > > >   * Weak symbol instead of macro to help riscv build failure
> > > >   * Update commit message
> > > >   * Add comment
> > > > ---
> > > >   arch/arm64/include/asm/topology.h | 2 +-
> > > >   arch/x86/include/asm/topology.h   | 2 +-
> > > >   drivers/acpi/cppc_acpi.c          | 6 ------
> > > >   drivers/acpi/processor_driver.c   | 9 +++++++++
> > > >   include/acpi/processor.h          | 2 ++
> > > >   5 files changed, 13 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
> > > > index 5fc3af9f8f29b..8a1860877967e 100644
> > > > --- a/arch/arm64/include/asm/topology.h
> > > > +++ b/arch/arm64/include/asm/topology.h
> > > > @@ -27,7 +27,7 @@ void update_freq_counters_refs(void);
> > > >   #define arch_scale_freq_ref topology_get_freq_ref
> > > >
> > > >   #ifdef CONFIG_ACPI_CPPC_LIB
> > > > -#define arch_init_invariance_cppc topology_init_cpu_capacity_cppc
> > > > +#define acpi_processor_init_invariance_cppc topology_init_cpu_capacity_cppc
> > > >   #endif
> > > >
> > > >   /* Replace task scheduler's default cpu-invariant accounting */
> > > > diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
> > > > index aef70336d6247..0fb705524aeaa 100644
> > > > --- a/arch/x86/include/asm/topology.h
> > > > +++ b/arch/x86/include/asm/topology.h
> > > > @@ -307,7 +307,7 @@ extern void arch_scale_freq_tick(void);
> > > >
> > > >   #ifdef CONFIG_ACPI_CPPC_LIB
> > > >   void init_freq_invariance_cppc(void);
> > > > -#define arch_init_invariance_cppc init_freq_invariance_cppc
> > > > +#define acpi_processor_init_invariance_cppc init_freq_invariance_cppc
> > > >   #endif
> > > >
> > > >   #endif /* _ASM_X86_TOPOLOGY_H */
> > > > diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
> > > > index 1a40f0514eaa3..5c0cc7aae8726 100644
> > > > --- a/drivers/acpi/cppc_acpi.c
> > > > +++ b/drivers/acpi/cppc_acpi.c
> > > > @@ -671,10 +671,6 @@ static int pcc_data_alloc(int pcc_ss_id)
> > > >    *  )
> > > >    */
> > > >
> > > > -#ifndef arch_init_invariance_cppc
> > > > -static inline void arch_init_invariance_cppc(void) { }
> > > > -#endif
> > > > -
> > > >   /**
> > > >    * acpi_cppc_processor_probe - Search for per CPU _CPC objects.
> > > >    * @pr: Ptr to acpi_processor containing this CPU's logical ID.
> > > > @@ -905,8 +901,6 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr)
> > > >                  goto out_free;
> > > >          }
> > > >
> > > > -       arch_init_invariance_cppc();
> > > > -
> > > >          kfree(output.pointer);
> > > >          return 0;
> > > >
> > > > diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> > > > index cb52dd000b958..3b281bc1e73c3 100644
> > > > --- a/drivers/acpi/processor_driver.c
> > > > +++ b/drivers/acpi/processor_driver.c
> > > > @@ -237,6 +237,9 @@ static struct notifier_block acpi_processor_notifier_block = {
> > > >          .notifier_call = acpi_processor_notifier,
> > > >   };
> > > >
> > > > +void __weak acpi_processor_init_invariance_cppc(void)
> > > > +{ }
> > >
> > > Does this actually work if acpi_processor_init_invariance_cppc is a
> > > macro?  How does the compiler know that it needs to use
> > > init_freq_invariance_cppc() instead of this?
> > >
> > > It would work if a __weak definition of init_freq_invariance_cppc() was present.
> >
> > I also wasn't sure, so I explicitly added some tracing in
> > init_freq_invariance_cppc() to make sure it got called and checked it
> > (GCC 13.2.0).
>
> Aren't C macros substituted strictly lexically, i.e. if the #define is
> present by the time the function definition is parsed, it's just
>
> void __weak acpi_processor_init_invariance_cppc(void) {}
> -> void __weak init_freq_invariance_cppc(void) {}
>
> ? So it _is_ a weak definition of init_freq_invariance_cppc().

Yes, you're right.

> >
> > But I'll admit it's a confusing behavior.  If you think it's too
> > confusing I'll swap it around to just axe the macros.
>
> ...That said, it does look kinda confusing. Seems to be norm for that
> arch/ header file though.

So let's not make it even more confusing than it already is.





[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]
  Powered by Linux