| Message ID | 20240117110443.2060704-1-quic_sibis@quicinc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | cpufreq: scmi: Add boost frequency support | expand |
On 17-01-24, 16:34, Sibi Sankar wrote: > This series adds provision to mark dynamic opps as boost capable and adds > boost frequency support to the scmi cpufreq driver. > > Depends on: > HW pressure v4: https://patchwork.kernel.org/project/linux-arm-msm/cover/20240109164655.626085-1-vincent.guittot@linaro.org/ > scmi notification v2: https://patchwork.kernel.org/project/linux-arm-msm/cover/20240117104116.2055349-1-quic_sibis@quicinc.com/ > > Sibi Sankar (3): > OPP: Extend dev_pm_opp_data with turbo support > firmware: arm_scmi: Add support for marking certain frequencies as > boost > cpufreq: scmi: Enable boost support Sudeep, please lemme know if you are okay with the changes. Will apply them.
On Tue, Jan 23, 2024 at 11:38:27AM +0530, Viresh Kumar wrote: > On 17-01-24, 16:34, Sibi Sankar wrote: > > This series adds provision to mark dynamic opps as boost capable and adds > > boost frequency support to the scmi cpufreq driver. > > > > Depends on: > > HW pressure v4: https://patchwork.kernel.org/project/linux-arm-msm/cover/20240109164655.626085-1-vincent.guittot@linaro.org/ > > scmi notification v2: https://patchwork.kernel.org/project/linux-arm-msm/cover/20240117104116.2055349-1-quic_sibis@quicinc.com/ @Sudeep, I am going to start review on this series and the related one these next few days. Thanks, Cristian
On Tue, Jan 23, 2024 at 11:38:27AM +0530, Viresh Kumar wrote: > On 17-01-24, 16:34, Sibi Sankar wrote: > > This series adds provision to mark dynamic opps as boost capable and adds > > boost frequency support to the scmi cpufreq driver. > > > > Depends on: > > HW pressure v4: https://patchwork.kernel.org/project/linux-arm-msm/cover/20240109164655.626085-1-vincent.guittot@linaro.org/ > > scmi notification v2: https://patchwork.kernel.org/project/linux-arm-msm/cover/20240117104116.2055349-1-quic_sibis@quicinc.com/ > > > > Sibi Sankar (3): > > OPP: Extend dev_pm_opp_data with turbo support > > firmware: arm_scmi: Add support for marking certain frequencies as > > boost > > cpufreq: scmi: Enable boost support > > Sudeep, please lemme know if you are okay with the changes. Will apply > them. I was planning to look at it once Lukasz/Dietmar confirm that this concept doesn't change anything fundamental in the way EAS related changes work today. I know I suggested the change as that seem to be right way to do but I haven't analysed if this has any negative impact on the existing features as this change will impact all the existing platform with OPPs above sustained performance/frequency advertised from the SCMI platform firmware.
On 23/01/2024 11:15, Sudeep Holla wrote: > On Tue, Jan 23, 2024 at 11:38:27AM +0530, Viresh Kumar wrote: >> On 17-01-24, 16:34, Sibi Sankar wrote: >>> This series adds provision to mark dynamic opps as boost capable and adds >>> boost frequency support to the scmi cpufreq driver. >>> >>> Depends on: >>> HW pressure v4: https://patchwork.kernel.org/project/linux-arm-msm/cover/20240109164655.626085-1-vincent.guittot@linaro.org/ >>> scmi notification v2: https://patchwork.kernel.org/project/linux-arm-msm/cover/20240117104116.2055349-1-quic_sibis@quicinc.com/ >>> >>> Sibi Sankar (3): >>> OPP: Extend dev_pm_opp_data with turbo support >>> firmware: arm_scmi: Add support for marking certain frequencies as >>> boost >>> cpufreq: scmi: Enable boost support >> >> Sudeep, please lemme know if you are okay with the changes. Will apply >> them. > > I was planning to look at it once Lukasz/Dietmar confirm that this concept > doesn't change anything fundamental in the way EAS related changes work > today. I know I suggested the change as that seem to be right way to do > but I haven't analysed if this has any negative impact on the existing > features as this change will impact all the existing platform with OPPs > above sustained performance/frequency advertised from the SCMI platform > firmware. I was mostly concerned about the settings for the CPU frequency invariance implementation in [drivers/base/arch_topology.c]: #define arch_scale_freq_capacity topology_get_freq_scale But per_cpu(capacity_freq_ref, cpu) is still set to 'policy->cpuinfo.max_freq' in init_cpu_capacity_callback() which stays the same. With some extra debugging I get the following on Juno-r0 [L b b L L L]: root@juno:~# dmesg -w | grep -i "freq\|boost\|noti\|OPP\|cap" [ 1.768414] arm-scmi firmware:scmi: SCMI Notifications - Core Enabled. [ 1.793084] [1][LITTLE_CPU]:: Registered OPP[0] 450000000 [ 1.798624] [1][LITTLE_CPU]:: Registered OPP[1] 575000000 [ 1.804131] [1][LITTLE_CPU]:: Registered OPP[2] 700000000 [ 1.809552] scmi_dvfs_device_opps_add() sustained_freq=700000000 freq=775000000 [ 1.816971] [1][LITTLE_CPU]:: Registered OPP[3] 775000000 [ 1.822392] scmi_dvfs_device_opps_add() sustained_freq=700000000 freq=850000000 [ 1.829800] [1][LITTLE_CPU]:: Registered OPP[4] 850000000 [ 1.835268] enabled boost: 0 [ 1.838173] init_cpu_capacity_callback() cpu=0 max_freq=850000 [ 1.844032] init_cpu_capacity_callback() cpu=3 max_freq=850000 [ 1.849886] init_cpu_capacity_callback() cpu=4 max_freq=850000 [ 1.855743] init_cpu_capacity_callback() cpu=5 max_freq=850000 [ 1.866324] cpufreq_update_pressure() cpu=0 cpufreq_pressure=0 [ 1.872178] cpufreq_update_pressure() cpu=3 cpufreq_pressure=0 [ 1.878026] cpufreq_update_pressure() cpu=4 cpufreq_pressure=0 [ 1.883874] cpufreq_update_pressure() cpu=5 cpufreq_pressure=0 [ 1.890633] [0][BIG_CPU]:: Registered OPP[0] 450000000 [ 1.895892] [0][BIG_CPU]:: Registered OPP[1] 625000000 [ 1.901129] [0][BIG_CPU]:: Registered OPP[2] 800000000 [ 1.906286] scmi_dvfs_device_opps_add() sustained_freq=800000000 freq=950000000 [ 1.906381] [0][BIG_CPU]:: Registered OPP[3] 950000000 [ 1.917377] scmi_dvfs_device_opps_add() sustained_freq=800000000 freq=1100000000 [ 1.917468] [0][BIG_CPU]:: Registered OPP[4] 1100000000 [ 1.939237] enabled boost: 0 [ 1.942134] init_cpu_capacity_callback() cpu=1 max_freq=1100000 [ 1.948078] init_cpu_capacity_callback() cpu=2 max_freq=1100000 [ 1.959003] cpufreq_update_pressure() cpu=1 cpufreq_pressure=0 [ 1.964853] cpufreq_update_pressure() cpu=2 cpufreq_pressure=0 root@juno:/sys/devices/system/cpu/cpufreq# cat boost policy*/boost 1 0 0 root@juno:/sys/devices/system/cpu/cpufreq# cat policy*/scaling_available_frequencies policy*/scaling_boost_frequencies 450000 575000 700000 450000 625000 800000 775000 850000 950000 1100000 If I disable system-wide boost I see the correct influence on 'cpufreq_pressure': root@juno:/sys/devices/system/cpu/cpufreq# echo 0 > boost [ 439.466682] cpufreq_update_pressure() cpu=1 cpufreq_pressure=280 [ 439.472797] cpufreq_update_pressure() cpu=2 cpufreq_pressure=280 [ 439.478889] cpufreq_update_pressure() cpu=0 cpufreq_pressure=79 [ 439.484852] cpufreq_update_pressure() cpu=3 cpufreq_pressure=79 [ 439.490843] cpufreq_update_pressure() cpu=4 cpufreq_pressure=79 [ 439.499621] cpufreq_update_pressure() cpu=5 cpufreq_pressure=79 reflecting the max frequency change from '1100000 to 800000' on CPU1,2 and from '850000 to 700000' on CPU0,3-5. root@juno:/sys/devices/system/cpu/cpufreq# echo 1 > boost [ 2722.693113] cpufreq_update_pressure() cpu=1 cpufreq_pressure=0 [ 2722.699041] cpufreq_update_pressure() cpu=2 cpufreq_pressure=0 [ 2722.704962] cpufreq_update_pressure() cpu=0 cpufreq_pressure=0 [ 2722.710842] cpufreq_update_pressure() cpu=3 cpufreq_pressure=0 [ 2722.719644] cpufreq_update_pressure() cpu=4 cpufreq_pressure=0 [ 2722.728224] cpufreq_update_pressure() cpu=5 cpufreq_pressure=0 What doesn't work for me is to disable boost per policy: root@juno:/sys/devices/system/cpu/cpufreq# echo 1 > boost root@juno:/sys/devices/system/cpu/cpufreq# echo 0 > policy0/boost root@juno:/sys/devices/system/cpu/cpufreq# echo 0 > policy1/boost Here I don't see 'cpufreq_pressure' changes. BTW, what's the use case you have in mind for this feature? Is it to cap high OPPs for CPUs in a certain CPUfreq policy?
On Wed, Jan 31, 2024 at 04:07:48PM +0100, Dietmar Eggemann wrote: [...] > > root@juno:/sys/devices/system/cpu/cpufreq# cat boost policy*/boost > 1 > 0 > 0 OK I admit, I wasn't aware of this per policy boost flag. It must be enabled by default if it has any effect. Otherwise it breaks the existing behaviour on all the SCMI based platforms.
On 1/31/24 20:37, Dietmar Eggemann wrote: > On 23/01/2024 11:15, Sudeep Holla wrote: >> On Tue, Jan 23, 2024 at 11:38:27AM +0530, Viresh Kumar wrote: >>> On 17-01-24, 16:34, Sibi Sankar wrote: >>>> This series adds provision to mark dynamic opps as boost capable and adds >>>> boost frequency support to the scmi cpufreq driver. >>>> >>>> Depends on: >>>> HW pressure v4: https://patchwork.kernel.org/project/linux-arm-msm/cover/20240109164655.626085-1-vincent.guittot@linaro.org/ >>>> scmi notification v2: https://patchwork.kernel.org/project/linux-arm-msm/cover/20240117104116.2055349-1-quic_sibis@quicinc.com/ >>>> >>>> Sibi Sankar (3): >>>> OPP: Extend dev_pm_opp_data with turbo support >>>> firmware: arm_scmi: Add support for marking certain frequencies as >>>> boost >>>> cpufreq: scmi: Enable boost support >>> >>> Sudeep, please lemme know if you are okay with the changes. Will apply >>> them. >> >> I was planning to look at it once Lukasz/Dietmar confirm that this concept >> doesn't change anything fundamental in the way EAS related changes work >> today. I know I suggested the change as that seem to be right way to do >> but I haven't analysed if this has any negative impact on the existing >> features as this change will impact all the existing platform with OPPs >> above sustained performance/frequency advertised from the SCMI platform >> firmware. > > I was mostly concerned about the settings for the CPU frequency > invariance implementation in [drivers/base/arch_topology.c]: > > #define arch_scale_freq_capacity topology_get_freq_scale > > But per_cpu(capacity_freq_ref, cpu) is still set to > 'policy->cpuinfo.max_freq' in init_cpu_capacity_callback() > which stays the same. > > With some extra debugging I get the following on Juno-r0 [L b b L L L]: > > root@juno:~# dmesg -w | grep -i "freq\|boost\|noti\|OPP\|cap" > > [ 1.768414] arm-scmi firmware:scmi: SCMI Notifications - Core Enabled. > [ 1.793084] [1][LITTLE_CPU]:: Registered OPP[0] 450000000 > [ 1.798624] [1][LITTLE_CPU]:: Registered OPP[1] 575000000 > [ 1.804131] [1][LITTLE_CPU]:: Registered OPP[2] 700000000 > [ 1.809552] scmi_dvfs_device_opps_add() sustained_freq=700000000 freq=775000000 > [ 1.816971] [1][LITTLE_CPU]:: Registered OPP[3] 775000000 > [ 1.822392] scmi_dvfs_device_opps_add() sustained_freq=700000000 freq=850000000 > [ 1.829800] [1][LITTLE_CPU]:: Registered OPP[4] 850000000 > [ 1.835268] enabled boost: 0 > [ 1.838173] init_cpu_capacity_callback() cpu=0 max_freq=850000 > [ 1.844032] init_cpu_capacity_callback() cpu=3 max_freq=850000 > [ 1.849886] init_cpu_capacity_callback() cpu=4 max_freq=850000 > [ 1.855743] init_cpu_capacity_callback() cpu=5 max_freq=850000 > [ 1.866324] cpufreq_update_pressure() cpu=0 cpufreq_pressure=0 > [ 1.872178] cpufreq_update_pressure() cpu=3 cpufreq_pressure=0 > [ 1.878026] cpufreq_update_pressure() cpu=4 cpufreq_pressure=0 > [ 1.883874] cpufreq_update_pressure() cpu=5 cpufreq_pressure=0 > [ 1.890633] [0][BIG_CPU]:: Registered OPP[0] 450000000 > [ 1.895892] [0][BIG_CPU]:: Registered OPP[1] 625000000 > [ 1.901129] [0][BIG_CPU]:: Registered OPP[2] 800000000 > [ 1.906286] scmi_dvfs_device_opps_add() sustained_freq=800000000 freq=950000000 > [ 1.906381] [0][BIG_CPU]:: Registered OPP[3] 950000000 > [ 1.917377] scmi_dvfs_device_opps_add() sustained_freq=800000000 freq=1100000000 > [ 1.917468] [0][BIG_CPU]:: Registered OPP[4] 1100000000 > [ 1.939237] enabled boost: 0 > [ 1.942134] init_cpu_capacity_callback() cpu=1 max_freq=1100000 > [ 1.948078] init_cpu_capacity_callback() cpu=2 max_freq=1100000 > [ 1.959003] cpufreq_update_pressure() cpu=1 cpufreq_pressure=0 > [ 1.964853] cpufreq_update_pressure() cpu=2 cpufreq_pressure=0 > > root@juno:/sys/devices/system/cpu/cpufreq# cat boost policy*/boost > 1 > 0 > 0 > > root@juno:/sys/devices/system/cpu/cpufreq# cat policy*/scaling_available_frequencies policy*/scaling_boost_frequencies > 450000 575000 700000 > 450000 625000 800000 > 775000 850000 > 950000 1100000 > > If I disable system-wide boost I see the correct influence on > 'cpufreq_pressure': > > root@juno:/sys/devices/system/cpu/cpufreq# echo 0 > boost > > [ 439.466682] cpufreq_update_pressure() cpu=1 cpufreq_pressure=280 > [ 439.472797] cpufreq_update_pressure() cpu=2 cpufreq_pressure=280 > [ 439.478889] cpufreq_update_pressure() cpu=0 cpufreq_pressure=79 > [ 439.484852] cpufreq_update_pressure() cpu=3 cpufreq_pressure=79 > [ 439.490843] cpufreq_update_pressure() cpu=4 cpufreq_pressure=79 > [ 439.499621] cpufreq_update_pressure() cpu=5 cpufreq_pressure=79 > > reflecting the max frequency change from '1100000 to 800000' on CPU1,2 > and from '850000 to 700000' on CPU0,3-5. > > root@juno:/sys/devices/system/cpu/cpufreq# echo 1 > boost > > [ 2722.693113] cpufreq_update_pressure() cpu=1 cpufreq_pressure=0 > [ 2722.699041] cpufreq_update_pressure() cpu=2 cpufreq_pressure=0 > [ 2722.704962] cpufreq_update_pressure() cpu=0 cpufreq_pressure=0 > [ 2722.710842] cpufreq_update_pressure() cpu=3 cpufreq_pressure=0 > [ 2722.719644] cpufreq_update_pressure() cpu=4 cpufreq_pressure=0 > [ 2722.728224] cpufreq_update_pressure() cpu=5 cpufreq_pressure=0 > > What doesn't work for me is to disable boost per policy: > > root@juno:/sys/devices/system/cpu/cpufreq# echo 1 > boost > root@juno:/sys/devices/system/cpu/cpufreq# echo 0 > policy0/boost > root@juno:/sys/devices/system/cpu/cpufreq# echo 0 > policy1/boost > > Here I don't see 'cpufreq_pressure' changes. > > BTW, what's the use case you have in mind for this feature? Is it to cap > high OPPs for CPUs in a certain CPUfreq policy? Yeah, that's exactly the use case for X1E. Boost frequencies defined in the SoC are achievable by only one CPU in a cluster i.e. either the other CPUs in the same cluster should be in low power mode or offline. So it's mostly for book keeping i.e. we wouldn't to intimate incorrectly that the CPUs are running at max possible frequency when it's actually running at a lower frequency. -Sibi > >
On 13/02/2024 08:35, Sibi Sankar wrote: > > > On 1/31/24 20:37, Dietmar Eggemann wrote: >> On 23/01/2024 11:15, Sudeep Holla wrote: >>> On Tue, Jan 23, 2024 at 11:38:27AM +0530, Viresh Kumar wrote: >>>> On 17-01-24, 16:34, Sibi Sankar wrote: [...] >> root@juno:/sys/devices/system/cpu/cpufreq# cat boost policy*/boost >> 1 >> 0 >> 0 >> >> root@juno:/sys/devices/system/cpu/cpufreq# cat >> policy*/scaling_available_frequencies policy*/scaling_boost_frequencies >> 450000 575000 700000 >> 450000 625000 800000 >> 775000 850000 >> 950000 1100000 >> >> If I disable system-wide boost I see the correct influence on >> 'cpufreq_pressure': >> >> root@juno:/sys/devices/system/cpu/cpufreq# echo 0 > boost >> >> [ 439.466682] cpufreq_update_pressure() cpu=1 cpufreq_pressure=280 >> [ 439.472797] cpufreq_update_pressure() cpu=2 cpufreq_pressure=280 >> [ 439.478889] cpufreq_update_pressure() cpu=0 cpufreq_pressure=79 >> [ 439.484852] cpufreq_update_pressure() cpu=3 cpufreq_pressure=79 >> [ 439.490843] cpufreq_update_pressure() cpu=4 cpufreq_pressure=79 >> [ 439.499621] cpufreq_update_pressure() cpu=5 cpufreq_pressure=79 >> >> reflecting the max frequency change from '1100000 to 800000' on CPU1,2 >> and from '850000 to 700000' on CPU0,3-5. >> >> root@juno:/sys/devices/system/cpu/cpufreq# echo 1 > boost >> >> [ 2722.693113] cpufreq_update_pressure() cpu=1 cpufreq_pressure=0 >> [ 2722.699041] cpufreq_update_pressure() cpu=2 cpufreq_pressure=0 >> [ 2722.704962] cpufreq_update_pressure() cpu=0 cpufreq_pressure=0 >> [ 2722.710842] cpufreq_update_pressure() cpu=3 cpufreq_pressure=0 >> [ 2722.719644] cpufreq_update_pressure() cpu=4 cpufreq_pressure=0 >> [ 2722.728224] cpufreq_update_pressure() cpu=5 cpufreq_pressure=0 >> >> What doesn't work for me is to disable boost per policy: >> >> root@juno:/sys/devices/system/cpu/cpufreq# echo 1 > boost >> root@juno:/sys/devices/system/cpu/cpufreq# echo 0 > policy0/boost >> root@juno:/sys/devices/system/cpu/cpufreq# echo 0 > policy1/boost >> >> Here I don't see 'cpufreq_pressure' changes. >> >> BTW, what's the use case you have in mind for this feature? Is it to cap >> high OPPs for CPUs in a certain CPUfreq policy? > > Yeah, that's exactly the use case for X1E. Boost frequencies defined in > the SoC are achievable by only one CPU in a cluster i.e. either the > other CPUs in the same cluster should be in low power mode or offline. > So it's mostly for book keeping i.e. we wouldn't to intimate incorrectly > that the CPUs are running at max possible frequency when it's actually > running at a lower frequency. I see. What about the issue with the settings of the global and the per-policy 'boost' file? On my Juno-r0 the initial boost values are: (1) Initial setting: root@juno:/sys/devices/system/cpu/cpufreq# cat boost policy*/boost 1 0 0 Should they not all be 1 ? (2) Disabling system-wide boost root@juno:/sys/devices/system/cpu/cpufreq# echo 0 > boost Here I see 'cpufreq_pressure > 0' for all CPUs. (3) Enabling system-wide boost root@juno:/sys/devices/system/cpu/cpufreq# echo 1 > boost And here 'cpufreq_pressure == 0' for all CPUs. (4) Disabling boost for policy0. root@juno:/sys/devices/system/cpu/cpufreq# echo 0 > policy0/boost root@juno:/sys/devices/system/cpu/cpufreq# cat boost policy*/boost 1 0 1 Here nothing happened. But I was expecting to see 'cpufreq_pressure > 0' for CPUs of policy0: root@juno:/sys/devices/system/cpu/cpufreq# cat policy0/affected_cpus 0 3 4 5
On 2/15/24 20:27, Dietmar Eggemann wrote: > On 13/02/2024 08:35, Sibi Sankar wrote: >> >> >> On 1/31/24 20:37, Dietmar Eggemann wrote: >>> On 23/01/2024 11:15, Sudeep Holla wrote: >>>> On Tue, Jan 23, 2024 at 11:38:27AM +0530, Viresh Kumar wrote: >>>>> On 17-01-24, 16:34, Sibi Sankar wrote: > > [...] > [...] >>> BTW, what's the use case you have in mind for this feature? Is it to cap >>> high OPPs for CPUs in a certain CPUfreq policy? >> >> Yeah, that's exactly the use case for X1E. Boost frequencies defined in >> the SoC are achievable by only one CPU in a cluster i.e. either the >> other CPUs in the same cluster should be in low power mode or offline. >> So it's mostly for book keeping i.e. we wouldn't to intimate incorrectly >> that the CPUs are running at max possible frequency when it's actually >> running at a lower frequency. > > I see. > > What about the issue with the settings of the global and the per-policy > 'boost' file? > > On my Juno-r0 the initial boost values are: > > (1) Initial setting: > > root@juno:/sys/devices/system/cpu/cpufreq# cat boost policy*/boost > 1 > 0 > 0 > > Should they not all be 1 ? > > > (2) Disabling system-wide boost > > root@juno:/sys/devices/system/cpu/cpufreq# echo 0 > boost > > Here I see 'cpufreq_pressure > 0' for all CPUs. > > > (3) Enabling system-wide boost > > root@juno:/sys/devices/system/cpu/cpufreq# echo 1 > boost > > And here 'cpufreq_pressure == 0' for all CPUs. > > > (4) Disabling boost for policy0. > > root@juno:/sys/devices/system/cpu/cpufreq# echo 0 > policy0/boost > > root@juno:/sys/devices/system/cpu/cpufreq# cat boost policy*/boost > 1 > 0 > 1 > > Here nothing happened. But I was expecting to see 'cpufreq_pressure > 0' > for CPUs of policy0: > https://patchwork.kernel.org/project/linux-arm-msm/cover/20240227165309.620422-1-quic_sibis@quicinc.com/ Finally got some time to fix this, I've posted out the fix and re-spun the series as well. This should fix the default values of per-policy boost flags as well. -Sibi > root@juno:/sys/devices/system/cpu/cpufreq# cat policy0/affected_cpus > 0 3 4 5
This series adds provision to mark dynamic opps as boost capable and adds boost frequency support to the scmi cpufreq driver. Depends on: HW pressure v4: https://patchwork.kernel.org/project/linux-arm-msm/cover/20240109164655.626085-1-vincent.guittot@linaro.org/ scmi notification v2: https://patchwork.kernel.org/project/linux-arm-msm/cover/20240117104116.2055349-1-quic_sibis@quicinc.com/ Sibi Sankar (3): OPP: Extend dev_pm_opp_data with turbo support firmware: arm_scmi: Add support for marking certain frequencies as boost cpufreq: scmi: Enable boost support drivers/cpufreq/scmi-cpufreq.c | 20 +++++++++++++++++++- drivers/firmware/arm_scmi/perf.c | 11 ++++++++++- drivers/opp/core.c | 1 + include/linux/pm_opp.h | 1 + 4 files changed, 31 insertions(+), 2 deletions(-)