Re: [PATCH v5 3/3] arch_topology: Add topology_update_cpu_capacity() for runtime updates

[Xueqin Luo]

Hi Christian,

Thanks for the review.

> Does this actually work if highest_perf would now be the equivalent
> for >1024?

Yes, it works correctly. I verified this on an arm64 8-core big.LITTLE
system (kernel 7.2.0-rc7-next-20260810). The runtime highest_perf change
was simulated by writing to a debugfs hook that invokes
cpufreq_update_limits() on the CPU, exercising the exact same code
path as ACPI Notify(0x85):

  LITTLE cores (cpu0-2,4-6): highest_perf=1900, cpu_capacity=670
  big cores    (cpu3,7):      highest_perf=2900, cpu_capacity=1024

The normalization is purely relative:
  capacity_scale = max(raw_capacity[all CPUs])
  cpu_capacity = (raw_capacity[cpu] << SCHED_CAPACITY_SHIFT) / capacity_scale

Test results with runtime highest_perf changes via debugfs:

Test                        cpu0   cpu1   cpu2   cpu3   cpu4   cpu5   cpu6   cpu7
---------------------------------------------------------------------------------
baseline                     670    670    670   1024    670    670    670   1024
cpu0 highest_perf=800        282    670    670   1024    670    670    670   1024
cpu0 highest_perf=2048       723    670    670   1024    670    670    670   1024
cpu0 highest_perf=4096      1024    475    475    725    475    475    475    725
cpu3 highest_perf=3000      1024    475    475    750    475    475    475    725
restored to hw values        670    670    670   1024    670    670    670   1024

Key observations:

1. highest_perf=2048 (>1024, but < capacity_scale=2900):
   cpu0 capacity = (2048 << 10) / 2900 = 723. Matches exactly.
   capacity_scale stays 2900 (cpu3/cpu7 still max), so other CPUs
   are unaffected.

2. highest_perf=4096 (> capacity_scale=2900):
   capacity_scale shifts to 4096. cpu0 becomes the new max at 1024.
   All other CPUs are re-normalized downward proportionally:
   LITTLE: (1900 << 10) / 4096 = 475
   big:    (2900 << 10) / 4096 = 725

3. Restore: writing back hw values fully restores original capacities.
   No state leakage.

In summary: the normalization is ratio-based and architecture-agnostic.
Whether highest_perf is 100, 1024, or 4096, the relative capacity
model remains consistent. 

Best regards,
Xueqin