On Fri, Oct 25, 2024 at 11:12:58AM +0800, Jiajie Chen wrote: > The x1e80100 CPU can have up to two cores running at 4.0 GHz, with one > core in the second cluster (cores 4-7) and the other in the third > cluster (cores 8-11). However, the scheduler is currently unaware of > this, leading to scenarios where a single core benchmark might run at > 3.4 GHz when scheduled to the first cluster. > > This patch introduces capacity-dmips-mhz nodes to each CPU node in the > DTS. For cores numbered 4 and 8, the capacities are set to 1200, while > others are set to 1024. This ensures that the two cores can be > prioritized for scheduling. The value 1200 is derived from approximately > `1024/3.4*4.0`. > > Note that capacity-dmips-mhz is not ideally suited for this purpose, as > it was designed to differentiate between performance and efficient > cores, not for core boosting. According to its definition, DMIPS/MHz > actually decreases with higher frequencies. However, since the CPU does > not support AMU, and no elegant solution was found, this approach is > used as a workaround. > > With this patch, we observe two cores running at full 4.0 GHz without > core binding. The single core score of Geekbench 6 increases from 2452 > to 2892, both without core binding. Tested on Surface Laptop 7. I think this is a nice hack, but I'd prefer to see scheduler being improved instead. From my (ignorant) point of view this should be close to SMT-based scheduling. We should split the jobs between the clusters, if that provides better power utilisation. > > Signed-off-by: Jiajie Chen <c@xxxxxx> > --- > arch/arm64/boot/dts/qcom/x1e80100.dtsi | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > -- With best wishes Dmitry
