arch/arm/include/asm/topology.h | 6 +--
arch/arm64/include/asm/topology.h | 6 +--
drivers/base/arch_topology.c | 26 ++++-----
drivers/cpufreq/cpufreq.c | 48 +++++++++++++++++
drivers/cpufreq/qcom-cpufreq-hw.c | 4 +-
drivers/thermal/cpufreq_cooling.c | 3 --
include/linux/arch_topology.h | 8 +--
include/linux/cpufreq.h | 10 ++++
include/linux/sched/topology.h | 8 +--
.../{thermal_pressure.h => hw_pressure.h} | 14 ++---
include/trace/events/sched.h | 2 +-
init/Kconfig | 12 ++---
kernel/sched/core.c | 8 +--
kernel/sched/fair.c | 53 ++++++++++---------
kernel/sched/pelt.c | 18 +++----
kernel/sched/pelt.h | 16 +++---
kernel/sched/sched.h | 4 +-
17 files changed, 152 insertions(+), 94 deletions(-)
rename include/trace/events/{thermal_pressure.h => hw_pressure.h} (55%)
Following the consolidation and cleanup of CPU capacity in [1], this serie
reworks how the scheduler gets the pressures on CPUs. We need to take into
account all pressures applied by cpufreq on the compute capacity of a CPU
for dozens of ms or more and not only cpufreq cooling device or HW
mitigiations. we split the pressure applied on CPU's capacity in 2 parts:
- one from cpufreq and freq_qos
- one from HW high freq mitigiation.
The next step will be to add a dedicated interface for long standing
capping of the CPU capacity (i.e. for seconds or more) like the
scaling_max_freq of cpufreq sysfs. The latter is already taken into
account by this serie but as a temporary pressure which is not always the
best choice when we know that it will happen for seconds or more.
[1] https://lore.kernel.org/lkml/20231211104855.558096-1-vincent.guittot@linaro.org/
Vincent Guittot (4):
cpufreq: Add a cpufreq pressure feedback for the scheduler
sched: Take cpufreq feedback into account
thermal/cpufreq: Remove arch_update_thermal_pressure()
sched: Rename arch_update_thermal_pressure into
arch_update_hw_pressure
arch/arm/include/asm/topology.h | 6 +--
arch/arm64/include/asm/topology.h | 6 +--
drivers/base/arch_topology.c | 26 ++++-----
drivers/cpufreq/cpufreq.c | 48 +++++++++++++++++
drivers/cpufreq/qcom-cpufreq-hw.c | 4 +-
drivers/thermal/cpufreq_cooling.c | 3 --
include/linux/arch_topology.h | 8 +--
include/linux/cpufreq.h | 10 ++++
include/linux/sched/topology.h | 8 +--
.../{thermal_pressure.h => hw_pressure.h} | 14 ++---
include/trace/events/sched.h | 2 +-
init/Kconfig | 12 ++---
kernel/sched/core.c | 8 +--
kernel/sched/fair.c | 53 ++++++++++---------
kernel/sched/pelt.c | 18 +++----
kernel/sched/pelt.h | 16 +++---
kernel/sched/sched.h | 4 +-
17 files changed, 152 insertions(+), 94 deletions(-)
rename include/trace/events/{thermal_pressure.h => hw_pressure.h} (55%)
--
2.34.1
Hi Vincent,
I've been waiting for this feature, thanks!
On 12/12/23 14:27, Vincent Guittot wrote:
> Following the consolidation and cleanup of CPU capacity in [1], this serie
> reworks how the scheduler gets the pressures on CPUs. We need to take into
> account all pressures applied by cpufreq on the compute capacity of a CPU
> for dozens of ms or more and not only cpufreq cooling device or HW
> mitigiations. we split the pressure applied on CPU's capacity in 2 parts:
> - one from cpufreq and freq_qos
> - one from HW high freq mitigiation.
>
> The next step will be to add a dedicated interface for long standing
> capping of the CPU capacity (i.e. for seconds or more) like the
> scaling_max_freq of cpufreq sysfs. The latter is already taken into
> account by this serie but as a temporary pressure which is not always the
> best choice when we know that it will happen for seconds or more.
>
> [1] https://lore.kernel.org/lkml/20231211104855.558096-1-vincent.guittot@linaro.org/
>
> Vincent Guittot (4):
> cpufreq: Add a cpufreq pressure feedback for the scheduler
> sched: Take cpufreq feedback into account
> thermal/cpufreq: Remove arch_update_thermal_pressure()
> sched: Rename arch_update_thermal_pressure into
> arch_update_hw_pressure
>
> arch/arm/include/asm/topology.h | 6 +--
> arch/arm64/include/asm/topology.h | 6 +--
> drivers/base/arch_topology.c | 26 ++++-----
> drivers/cpufreq/cpufreq.c | 48 +++++++++++++++++
> drivers/cpufreq/qcom-cpufreq-hw.c | 4 +-
> drivers/thermal/cpufreq_cooling.c | 3 --
> include/linux/arch_topology.h | 8 +--
> include/linux/cpufreq.h | 10 ++++
> include/linux/sched/topology.h | 8 +--
> .../{thermal_pressure.h => hw_pressure.h} | 14 ++---
> include/trace/events/sched.h | 2 +-
> init/Kconfig | 12 ++---
> kernel/sched/core.c | 8 +--
> kernel/sched/fair.c | 53 ++++++++++---------
> kernel/sched/pelt.c | 18 +++----
> kernel/sched/pelt.h | 16 +++---
> kernel/sched/sched.h | 4 +-
> 17 files changed, 152 insertions(+), 94 deletions(-)
> rename include/trace/events/{thermal_pressure.h => hw_pressure.h} (55%)
>
I would like to test it, but something worries me. Why there is 0/5 in
this subject and only 4 patches?
Could you tell me your base branch that I can apply this, please?
Regards,
Lukasz
On Thu, 14 Dec 2023 at 09:21, Lukasz Luba <lukasz.luba@arm.com> wrote:
>
> Hi Vincent,
>
> I've been waiting for this feature, thanks!
>
>
> On 12/12/23 14:27, Vincent Guittot wrote:
> > Following the consolidation and cleanup of CPU capacity in [1], this serie
> > reworks how the scheduler gets the pressures on CPUs. We need to take into
> > account all pressures applied by cpufreq on the compute capacity of a CPU
> > for dozens of ms or more and not only cpufreq cooling device or HW
> > mitigiations. we split the pressure applied on CPU's capacity in 2 parts:
> > - one from cpufreq and freq_qos
> > - one from HW high freq mitigiation.
> >
> > The next step will be to add a dedicated interface for long standing
> > capping of the CPU capacity (i.e. for seconds or more) like the
> > scaling_max_freq of cpufreq sysfs. The latter is already taken into
> > account by this serie but as a temporary pressure which is not always the
> > best choice when we know that it will happen for seconds or more.
> >
> > [1] https://lore.kernel.org/lkml/20231211104855.558096-1-vincent.guittot@linaro.org/
> >
> > Vincent Guittot (4):
> > cpufreq: Add a cpufreq pressure feedback for the scheduler
> > sched: Take cpufreq feedback into account
> > thermal/cpufreq: Remove arch_update_thermal_pressure()
> > sched: Rename arch_update_thermal_pressure into
> > arch_update_hw_pressure
> >
> > arch/arm/include/asm/topology.h | 6 +--
> > arch/arm64/include/asm/topology.h | 6 +--
> > drivers/base/arch_topology.c | 26 ++++-----
> > drivers/cpufreq/cpufreq.c | 48 +++++++++++++++++
> > drivers/cpufreq/qcom-cpufreq-hw.c | 4 +-
> > drivers/thermal/cpufreq_cooling.c | 3 --
> > include/linux/arch_topology.h | 8 +--
> > include/linux/cpufreq.h | 10 ++++
> > include/linux/sched/topology.h | 8 +--
> > .../{thermal_pressure.h => hw_pressure.h} | 14 ++---
> > include/trace/events/sched.h | 2 +-
> > init/Kconfig | 12 ++---
> > kernel/sched/core.c | 8 +--
> > kernel/sched/fair.c | 53 ++++++++++---------
> > kernel/sched/pelt.c | 18 +++----
> > kernel/sched/pelt.h | 16 +++---
> > kernel/sched/sched.h | 4 +-
> > 17 files changed, 152 insertions(+), 94 deletions(-)
> > rename include/trace/events/{thermal_pressure.h => hw_pressure.h} (55%)
> >
>
> I would like to test it, but something worries me. Why there is 0/5 in
> this subject and only 4 patches?
I removed a patch from the series but copied/pasted the cover letter
subject without noticing the /5 instead of /4
>
> Could you tell me your base branch that I can apply this, please?
It applies on top of tip/sched/core + [1]
and you can find it here:
https://git.linaro.org/people/vincent.guittot/kernel.git/log/?h=sched/system-pressure
>
> Regards,
> Lukasz
On 12/14/23 08:29, Vincent Guittot wrote:
> On Thu, 14 Dec 2023 at 09:21, Lukasz Luba <lukasz.luba@arm.com> wrote:
>>
>> Hi Vincent,
>>
>> I've been waiting for this feature, thanks!
>>
>>
>> On 12/12/23 14:27, Vincent Guittot wrote:
>>> Following the consolidation and cleanup of CPU capacity in [1], this serie
>>> reworks how the scheduler gets the pressures on CPUs. We need to take into
>>> account all pressures applied by cpufreq on the compute capacity of a CPU
>>> for dozens of ms or more and not only cpufreq cooling device or HW
>>> mitigiations. we split the pressure applied on CPU's capacity in 2 parts:
>>> - one from cpufreq and freq_qos
>>> - one from HW high freq mitigiation.
>>>
>>> The next step will be to add a dedicated interface for long standing
>>> capping of the CPU capacity (i.e. for seconds or more) like the
>>> scaling_max_freq of cpufreq sysfs. The latter is already taken into
>>> account by this serie but as a temporary pressure which is not always the
>>> best choice when we know that it will happen for seconds or more.
>>>
>>> [1] https://lore.kernel.org/lkml/20231211104855.558096-1-vincent.guittot@linaro.org/
>>>
>>> Vincent Guittot (4):
>>> cpufreq: Add a cpufreq pressure feedback for the scheduler
>>> sched: Take cpufreq feedback into account
>>> thermal/cpufreq: Remove arch_update_thermal_pressure()
>>> sched: Rename arch_update_thermal_pressure into
>>> arch_update_hw_pressure
>>>
>>> arch/arm/include/asm/topology.h | 6 +--
>>> arch/arm64/include/asm/topology.h | 6 +--
>>> drivers/base/arch_topology.c | 26 ++++-----
>>> drivers/cpufreq/cpufreq.c | 48 +++++++++++++++++
>>> drivers/cpufreq/qcom-cpufreq-hw.c | 4 +-
>>> drivers/thermal/cpufreq_cooling.c | 3 --
>>> include/linux/arch_topology.h | 8 +--
>>> include/linux/cpufreq.h | 10 ++++
>>> include/linux/sched/topology.h | 8 +--
>>> .../{thermal_pressure.h => hw_pressure.h} | 14 ++---
>>> include/trace/events/sched.h | 2 +-
>>> init/Kconfig | 12 ++---
>>> kernel/sched/core.c | 8 +--
>>> kernel/sched/fair.c | 53 ++++++++++---------
>>> kernel/sched/pelt.c | 18 +++----
>>> kernel/sched/pelt.h | 16 +++---
>>> kernel/sched/sched.h | 4 +-
>>> 17 files changed, 152 insertions(+), 94 deletions(-)
>>> rename include/trace/events/{thermal_pressure.h => hw_pressure.h} (55%)
>>>
>>
>> I would like to test it, but something worries me. Why there is 0/5 in
>> this subject and only 4 patches?
>
> I removed a patch from the series but copied/pasted the cover letter
> subject without noticing the /5 instead of /4
OK
>
>>
>> Could you tell me your base branch that I can apply this, please?
>
> It applies on top of tip/sched/core + [1]
> and you can find it here:
> https://git.linaro.org/people/vincent.guittot/kernel.git/log/?h=sched/system-pressure
Thanks for the info and handy link.
On 12/14/23 08:32, Lukasz Luba wrote:
>
>
> On 12/14/23 08:29, Vincent Guittot wrote:
>> On Thu, 14 Dec 2023 at 09:21, Lukasz Luba <lukasz.luba@arm.com> wrote:
>>>
>>> Hi Vincent,
>>>
>>> I've been waiting for this feature, thanks!
>>>
>>>
>>> On 12/12/23 14:27, Vincent Guittot wrote:
>>>> Following the consolidation and cleanup of CPU capacity in [1], this
>>>> serie
>>>> reworks how the scheduler gets the pressures on CPUs. We need to
>>>> take into
>>>> account all pressures applied by cpufreq on the compute capacity of
>>>> a CPU
>>>> for dozens of ms or more and not only cpufreq cooling device or HW
>>>> mitigiations. we split the pressure applied on CPU's capacity in 2
>>>> parts:
>>>> - one from cpufreq and freq_qos
>>>> - one from HW high freq mitigiation.
>>>>
>>>> The next step will be to add a dedicated interface for long standing
>>>> capping of the CPU capacity (i.e. for seconds or more) like the
>>>> scaling_max_freq of cpufreq sysfs. The latter is already taken into
>>>> account by this serie but as a temporary pressure which is not
>>>> always the
>>>> best choice when we know that it will happen for seconds or more.
>>>>
>>>> [1]
>>>> https://lore.kernel.org/lkml/20231211104855.558096-1-vincent.guittot@linaro.org/
>>>>
>>>> Vincent Guittot (4):
>>>> cpufreq: Add a cpufreq pressure feedback for the scheduler
>>>> sched: Take cpufreq feedback into account
>>>> thermal/cpufreq: Remove arch_update_thermal_pressure()
>>>> sched: Rename arch_update_thermal_pressure into
>>>> arch_update_hw_pressure
>>>>
>>>> arch/arm/include/asm/topology.h | 6 +--
>>>> arch/arm64/include/asm/topology.h | 6 +--
>>>> drivers/base/arch_topology.c | 26 ++++-----
>>>> drivers/cpufreq/cpufreq.c | 48 +++++++++++++++++
>>>> drivers/cpufreq/qcom-cpufreq-hw.c | 4 +-
>>>> drivers/thermal/cpufreq_cooling.c | 3 --
>>>> include/linux/arch_topology.h | 8 +--
>>>> include/linux/cpufreq.h | 10 ++++
>>>> include/linux/sched/topology.h | 8 +--
>>>> .../{thermal_pressure.h => hw_pressure.h} | 14 ++---
>>>> include/trace/events/sched.h | 2 +-
>>>> init/Kconfig | 12 ++---
>>>> kernel/sched/core.c | 8 +--
>>>> kernel/sched/fair.c | 53
>>>> ++++++++++---------
>>>> kernel/sched/pelt.c | 18 +++----
>>>> kernel/sched/pelt.h | 16 +++---
>>>> kernel/sched/sched.h | 4 +-
>>>> 17 files changed, 152 insertions(+), 94 deletions(-)
>>>> rename include/trace/events/{thermal_pressure.h => hw_pressure.h}
>>>> (55%)
>>>>
>>>
>>> I would like to test it, but something worries me. Why there is 0/5 in
>>> this subject and only 4 patches?
>>
>> I removed a patch from the series but copied/pasted the cover letter
>> subject without noticing the /5 instead of /4
>
> OK
>
>>
>>>
>>> Could you tell me your base branch that I can apply this, please?
>>
>> It applies on top of tip/sched/core + [1]
>> and you can find it here:
>> https://git.linaro.org/people/vincent.guittot/kernel.git/log/?h=sched/system-pressure
>
> Thanks for the info and handy link.
>
I've tested your patches with: DTPM/PowerCap + thermal gov + cpufreq
sysfs scaling_max_freq. It works fine all my cases (couldn't cause
any issues). If you like to test DTPM you will need 2 fixed pending
in Rafael's tree.
So, I'm looking for a your v2 to continue reviewing it.
© 2016 - 2025 Red Hat, Inc.