Is your feature request related to a problem? Please describe.

Since the introduction of CPUFreq #93461 (comment) the concept of a 'metric' was defined and a new CPU Load metric was introduced to support the on-demand policy.

There is an overlap in functionality here since there already exists functionality to measure CPU load in the debug subsystem. The APIs differ slightly between the two implementations, but they aim to achieve the same thing. We should eliminate this redundancy and consolidate the two subsystem features. The implementation seems to be superior to the debug/cpu_load implementation since it supports all CPU arch and is SMP compatible.

Background info:

• cpu_freq: Add CPU frequency scaling subsystem #93461 (review)
• [RFC] CPU Frequency Scaling Subsystem #92123 (comment)

Describe the solution you'd like

Since we now have a subsystem that relies on measuring runtime CPULoad, this cannot be a 'debug' feature, since that implies it is not something for production. So the CPULoad implementation in debug should be removed and its usages be refactored. However, I agree with #93461 (review) that having a dedicated subsystem per 'metric' is not scalable.

I propose that we create a metrics directory that lives either under subsys or kernel which can hold this one true definition of CPULoad (consolidate the APIs if they differ meaningfully), and potentially other metrics in the future. Some other metrics that would live in this directory could be:

• Interrupt load
• Thread scheduling stats such as slack/lateness (this will be useful for the just-in-time DVFS policy to be added later).
• Timer/Clock metrics (drift, etc.)

I don't suggest we add all these metrics immediately, if they don't have use, but just gives an idea of how I think we may want to organize it in the repo.

Describe alternatives you've considered

Open to suggestions, but this seems natural to me.