lisa._assets.kmodules.lisa: Don't rely on rq->cpu_capacity_orig anymore

[deggeman]

The kernel commit 7bc263840bc3 ("sched/topology: Consolidate and clean up access to a CPU's max compute") removed rq->cpu_capacity_orig so we can't use it anymore to retrieve the original CPU capacity nor for setting the FREQ_INVARIANCE kernel feature in LISA.

Replace rq->cpu_capacity_orig with arch_scale_cpu_capacity(cpu) in Lisa trace module's rq_cpu_orig_capacity() and remove the HAS_MEMBER(struct, rq, cpu_capacity_orig) check from the FREQ_INVARIANCE test.

Since arch_scale_cpu_capacity(cpu) exists in the kernel for a long time we don't have to take care of activating this only for newer Linux kernel versions.

[deggeman]

Related to PWRSOFT-5115

[deggeman]

The kernel commit 7bc263840bc3 ("sched/topology: Consolidate and clean
up access to a CPU's max compute") removed rq->cpu_capacity_orig so we
can't use it anymore to retrieve the original CPU capacity nor for
setting the FREQ_INVARIANCE kernel feature in LISA.

Replace rq->cpu_capacity_orig with arch_scale_cpu_capacity(cpu) in Lisa
trace module's rq_cpu_orig_capacity() and remove the HAS_MEMBER(struct,
rq, cpu_capacity_orig) check from the FREQ_INVARIANCE test.

Pull request: #2145

[credp]

We probably need to figure out how to make this work for pre and post-patch kernels in order to complete this.

[deggeman]

Fortunately not in this case:

I use arch_scale_cpu_capacity(cpu) now instead as accessing rq->cpu_capacity_orig directly.

Since arch_scale_cpu_capacity(cpu) exists in the kernel for a long time we don't have to take care of activating this only for newer Linux kernel versions.

[douglas-raillard-arm]

Using arch_scale_cpu_capacity() is problematic, as this is not an exported function (or at least not always). Instead it's a macro that can point at anything, which means that instead of being able to check for the availability of a single exported function, we need to check for the availability of all its dependencies. That would be bad enough but on top of that, the implementation depends on the architecture.

So AFAIK we only have two choices:

1. We implement getters for this sort of info in the scheduler code as non-inline functions, ideally exported
2. We copy-paste the inner implementation for arm64 like we have for rq_cpu_current_capacity() (sched_helpers.h) and guard with appropriate checks for the dependencies of that implementations, while crossing fingers that a) no-one will try to use it on an arch that does it differently and b) that the upstream kernel will not suddenly change the meaning of the variables/functions it depends on.

Since arch_scale_cpu_capacity(cpu) exists in the kernel for a long time we don't have to take care of activating this only for newer Linux kernel versions.

Yes but the macro being there for internal use is sadly not enough, we also need all the symbols it relies on to be available, which will break with Android kernels.

Also unfortunately since we need to be able to change the CPU capacities at runtime, we cannot just read the value from e.g. sysfs or debugfs and store it locally inside the module, it needs to be read every time the event is emitted and reading sysfs like that is not something we want to do on a hot path.

[deggeman]

I updated the fix by implementing choice 1.