Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | [RFC][PATCH v1 0/3] x86 / intel_pstate: Set asymmetric CPU capacity on hybrid systems | Date | Thu, 25 Apr 2024 21:03:03 +0200 |
| |
Hi Everyone,
The purpose of this series is to provide the scheduler with asymmetric CPU capacity information on x86 hybrid systems based on Intel hardware.
The asymmetric CPU capacity information is important on hybrid systems as it allows utilization to be computed for tasks in a consistent way across all CPUs in the system, regardless of their capacity. This, in turn, allows the schedutil cpufreq governor to set CPU performance levels consistently in the cases when tasks migrate between CPUs of different capacities. It should also help to improve task placement and load balancing decisions on hybrid systems and it is key for anything along the lines of EAS.
The information in question comes from the MSR_HWP_CAPABILITIES register and is provided to the scheduler by the intel_pstate driver, as per the changelog of patch [3/3]. Patch [2/3] introduces the arch infrastructure needed for that (in the form of a per-CPU capacity variable) and patch [1/3] is a preliminary code adjustment.
The changes made by patch [2/3] are very simple, which is why this series is being sent as an RFC. Namely, it increases overhead on non-hybrid as well as on hybrid systems which may be regarded as objectionable, even though the overhead increase is arguably not significant. The memory overhead is an unsigned long variable per CPU which is not a lot IMV and there is also additional memory access overhead at each arch_scale_cpu_capacity() call site which I'm not expecting to be noticeable, however. In any case, the extra overhead can be avoided at the cost of making the code a bit more complex (for example, the additional per-CPU memory can be allocated dynamically on hybrid systems only and a static branch can be used for enabling access to it when necessary). I'm just not sure if the extra complexity is really worth it, so I'd like to know the x86 maintainers' take on this. If you'd prefer the overhead to be avoided, please let me know.
Of course, any other feedback on the patches is welcome as well.
Thank you!
| |